Met de hulp van een gebruiker is het probleem inmiddels opwekbaar en analyseerbaar gemaakt.
Voor systeemgebruiker (alleen binnen Invantive zelf) is het hangen blijven te constateren via de volgende query op Bridge Online via de Invantive Bridge Online driver:
select *
from DataDictionary.Invantive.[SYSTEMLOCKS@DataDictionary]
where context like 'Named.ExactOnline.Incremental./api/v1%sync%'
--
-- Acquiring lock on Incremental API timed out more than 50 times consecutively.
--
and timeout_count > 50
--
-- Timed out in last 10 minutes.
--
and date_last_timeout >= sysdateutc - 600/86400
Binnen Power BI en dergelijke is het op vergelijkbare wijze op te vragen via de tabel SystemLocks. Merk echter op dat reguliere gebruikers momenteel geen rijen zullen aantreffen. Dit wordt mogelijk in release 25.0 nog verbeterd.
De onderliggende oorzaak lijkt te zijn dat een eerder downloadverzoek van de incrementele tabel met een fout is beeindigd. Echter, de bijbehorende vergrendeling (een zogenaamde “lock” op basis van zogenaamde “semaforen”) is daarbij niet vrijgegeven.
Een latere download van dezelfde dataset, waarbij dezelfde gedefinieerd is als de combinatie van tabelnaam en divisiecode, zal dan eeuwig blijven hangen omdat de vergrendeling niet verkregen kan worden.
Als tijdelijke maatregel wordt de Bridge Online server op dit moment elke twee uur herstart.
Het probleem treedt uitsluitend op in combinatie met Exact Online en de incrementele tabellen (wat vaak de grootste zijn, met soms 10 miljoen rijen per administratie op Invantive Cloud).
Advies: stel cache levensduur in op 14400 seconden
Advies aan gebruikers is om de cache levensduur op tenminste 14400 seconden in te stellen (vier uur). Daarmee kan in principe elke download slagen omdat tussentijds altijd Bridge Online herstart is geweest.
Het instellen staat beschreven in:
Momenteel wordt verder gewerkt aan het beter kunnen opwekken van het probleem en daarna het wegnemen van de oorzaak. Dit kan naar verwachting 1 tot 2 weken duren.