Itgentmm007 Kan geen vrij slot krijgen op throttle ‘ThrottlingBasedOnLicense’ voor cap-groep ‘lic:...’ na 1,920 seconden te hebben gewacht

drx · April 5, 2025, 10:19am

Power BI geeft sinds een week foutmeldingen op verschillende datasources.
Waardoor de data niet wordt geladen en momenteel een deel van het facturatie proces stil ligt.

Foutmelding Power BI Datasource:

Fout in de gegevensbron:
DataSource.Error:
OData: Request failed:
The underlying connection was closed:
An unexpected error occurred on a receive… Microsoft.Data.Mashup.ErrorCode = 10122.
DataSourceKind = OData. DataSourcePath = https://bridge-online.cloud/acme-exact-online/odata4/ExactOnlineREST.Incremental.AccountsIncremental@eol. .
The exception was raised by the IDbCommand interface.
Table: AccountsIncremental.
URI cluster: WABI-WEST-EUROPE-E-PRIMARY-redirect.analysis.windows.net
Activiteits-id: df686ac5-b5b8-4bd2-b511-5a6bc875beb4
Aanvraag-id: 8f755625-b204-47eb-acee-8cd95492f10d
Tijd: 2025-04-05 08:23:23Z

Foutmelding in monitoring Invantive Cloud:

itgentmm007:
Kan geen vrij slot krijgen op throttle ‘ThrottlingBasedOnLicense’ voor cap-groep ‘lic:L771149607’ na 1,920 seconden te hebben gewacht sinds 04/05/2025 08:23:26.
Maximum aantal actieve verzoeken: 4, vrije slots: 0.

Hoe los ik dit op?

Bij voorbaat dank

forums · April 8, 2025, 9:21am

De foutmelding itgentmm007 behelst dat de verwerking van een download niet kan beginnen omdat er geen vrij slot beschikbaar komt binnen 32 minuten na de ontvangst van het downloadverzoek.

Deze foutmelding treedt sinds 2 april structureel vele malen vaker op. Dit hangt naar verwachting samen met de verhuizing qua datacentrum van de Ierse locatie van het Amerikaanse AWS naar de Franse locatie van het Franse Scaleway.

Deze itgentmm007-foutmelding treedt gedurende de gehele dag op, maar is beperkt tot enkele tientallen gebruikers, waarvan circa 50% zich concentreert bij enkele organisaties met relatief veel databases en relatief grote aantallen gebruikers.

Een analyse is gestart om de oorzaak/oorzaken te achterhalen en zo goed mogelijk weg te nemen.

Analyse

Een voorbeeld is request 0HNBLLER08EQI:00000001 voor https://bridge-online.cloud/acme-exact-online/odata4/ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol?$filter=Division%20eq%201483520%20and%20Item%20ne%20null

Deze kon niet gestart worden van 05:17:02 tot 05:49:56 omdat er maximaal 4 actieve requests op deze abonnementsvorm zijn en gaf daardoor fout itgentmm007. De op dat moment vier actieve requests waren:

ID	Gestart	URL
0HNBLLER08E5J	05:02:16	`.../odata4/ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol?$filter=Division%20eq%201483520%20and%20Item%20ne%20null&$select=...`
0HNBLLER08EB4	05:07:01	`.../odata4/ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol?$filter=Division%20eq%201483520%20and%20Item%20ne%20null&$select=...`
0HNBLLER08ED5	05:07:34	`...//odata4/ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol?$filter=Division%20eq%201483520%20and%20Item%20ne%20null&$select=...`
0HNBLLER08EJ4	05:12:19	`.../odata4/ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol?$filter=Division%20eq%201483520%20and%20Item%20ne%20null&$select=...`

Voor geen van de verzoeken konden sessie I/O’s achterhaald worden.

Op de divisiecode 1483520 konden wel drie time-outs van de Exact Online API-server gevonden worden (zie Itgenclr227 en itgenoda316 bij ophalen ExactOnlineREST.Cashflow.Payments). Twee van de drie time-outs betroffen sync/SalesInvoice/SalesInvoices wat ligt onder SalesInvoiceLinesIncremental maar deze time-outs traden op later in de ochtend en naar verwachting is deze aanhoudende Exact-storing niet gerelateerd.

De tabel SalesInvoiceLinesIncremental is vaak opgehaald. Deze werd succesvol opgehaald om 05:01:49 met request 0HNBLLER08E2E:00000003, enkele seconden voor de request die langer dan een half uur duurde.

Het request 0HNBLLER08E2E:00000003 startte om 04:57:32 en duurde tot 05:02:26. Hij eindigde echter in een foutmelding itgenpmr004 / itgenboe161 na 88,844 rijen uitvoer en 94,000 rijen verwerkt. Dit is gelijkend op Foutcode itgenboe147 na 5 minuten.

Echter, het navolgende request 0HNBLLER08E5J zou desondanks bij een volgende poging moeten slagen en niet langer dan 32 minuten duren, namelijk vanaf 05:02:17 tot 07:00:09. Dit request blijft wachten op itgenire096 en itgenpmr054 om een lock te krijgen op /api/v1/1483520/sync/SalesInvoice/SalesInvoices via itgeneor748 vanaf 05:02:26.

Het request 0HNBLLER08E2E:00000003 is om 05:02:26 gestopt met data verwerken, maar heeft ondanks het verwerven van de genoemde lock via itgeneor752 aan het einde de lock niet vrijgegeven via een itgeneor750 of itgeneor751.

forums · April 11, 2025, 12:42pm

Een verbetering is in productie genomen waardoor de software automatisch kan vaststellen of er sprake is van dit probleem. Vervolgens kan indien nodig de dienst automatisch herstart worden zodat nieuwe verzoeken wel slagen.

De inregeling hiervan kan enkele werkdagen duren.

Parallel hieraan loopt een traject om de diepere oorzaak te achterhalen waarom dit probleem weer optreedt. Het sluit voor grote delen aan op PjtTimeTransactionsIncremental blijft eindeloos hangen, alhoewel dat probleem al opgelost was door een aanpassing in de logica.

Het is niet bekend waarom een aantal organisaties er specifiek veel last van lijken te hebben.

Eventuele problemen worden gedetecteerd via de volgende query:

select lck.context
,      case
       when lck.CURRENT_WAITING_COUNT != 0
       then 'Productiestoring'
       else 'Latent aanwezige oorzaak'
       end
       txt_ernst
       label 'Ernst'
,      case 
       when coalesce(rqtme.is_completed, true)
       then 'Had al '
            || to_char(round((sysdateutc - rqtlck.end_utc) * 86400))
            || ' seconden geleden vrijgegeven moeten worden'
       when coalesce(rqtlck.is_completed, true)
       then 'Wacht eindeloos op vrijgave lock die ' 
            || to_char(round((sysdateutc - rqtlck.end_utc) * 86400))
            || ' seconden geleden vrijgegeven had moeten worden'
       when lck.timeout_count >= 30
       then 'Wacht op vrijgave ander (langlopend) request'
       when lck.timeout_count >= 3
       then 'Wacht op vrijgave ander request'
       else null
       end
       txt_oorzaak
       label 'Oorzaak'
,      lck.CURRENT_WAITING_COUNT
,      lck.DATE_LAST_ACQUISITION
,      lck.POOL_IDENTITY
,      lck.REQUEST_ID
,      lck.REQUEST_ID_LAST_ACQUISITION
,      rqtme.is_completed me_is_completed
,      rqtlck.is_completed locker_is_completed
,      round((sysdateutc - rqtlck.end_utc) * 86400) locker_completed_age_sec
,      lck.POOL_IDENTITY_LAST_ACQUISITION
--
,      lck.GUI_IP_ADDRESS_EXTERNAL
,      lck.DATE_LAST_FULL_RELEASE
,      lck.DATE_FIRST_TIMEOUT
,      lck.DATE_LAST_TIMEOUT
,      lck.PARTITION_CODE
,      lck.DATA_CONTAINER_ID
,      lck.PROVIDER_NAME
from   DataDictionary.Invantive.[SYSTEMLOCKS@DataDictionary] lck
left
outer
join   BridgeOnline.Invantive.REQUESTS rqtme
on     rqtme.id = lck.REQUEST_ID_LAST_ACQUISITION
left
outer
join   BridgeOnline.Invantive.REQUESTS rqtlck
on     rqtlck.id = lck.REQUEST_ID_LAST_ACQUISITION
where  lck.context like 'Named.ExactOnline.Incremental./api/v1%sync%'
and    ( --
         -- Lock is held by a non-existing or completed request.
         --
         ( coalesce(rqtme.is_completed, true)
         )
         or
         --
         -- Locker has completed, but still maintains a lock.
         --
         ( rqtlck.is_completed
         )
         or
         (
           --
           -- Acquiring lock on Incremental API timed out more than 50 times consecutively.
           --
           lck.timeout_count >= 30
           --
           -- Timed out in last 10 minutes.
           --
           and    lck.date_last_timeout >= sysdateutc - 600/86400
         )
       )
order
by     lck.timeout_count desc
,      lck.context

Deze query is op 13 april geoptimaliseerd zodat ook dreigende problemen ontdekt worden.

forums · April 13, 2025, 7:09pm

Het probleem kan voorkomen worden door niet dezelfde dataset met andere criteria op te halen. “Dezelfde” is hierbij gedefinieerd als de combinatie van Exact Online-administratie en *Incremental-tabelnaam.

Niet dezelfde zijn:

ItemsIncremental met divisiecode 1234 en ItemsIncremental met divisiecode 9876
ItemsIncremental met divisiecode 1234 en TransactionLinesIncremental met divisiecode 1234.

Het ophalen van de volledige dataset en die telkens opnieuw uit cache halen geeft de meest stabiele resultaten. Hiervoor kan bijvoorbeeld gewerkt worden met een dataset op Power BI. Dit is sowieso de aanbevolen aanpak voor productie en verklaart ook waarom maar een deel van de gebruikers dit probleem ervaart. De rest werkt blijkbaar met datasets die men netjes 's nachts klaarzet.

forums · April 18, 2025, 8:50am

Een aantal verbeteringen om dit probleem te detecteren en mogelijk te voorkomen zijn in productie genomen via versie 24.0.663 voor alle Invantive Cloud-producten.

forums · April 19, 2025, 10:55am

Een verbetering om dit probleem te voorkomen is in productie genomen via versie 24.0.666, maar heeft nog niet tot voldoende resultaat geleid. Er wordt gewerkt aan een verdere verbetering. Tot dan wordt Invantive Bridge Online elk uur herstart om de impact te beperken.

avn2 · April 22, 2025, 10:50am

Ook vandaag doet dit probleem zich opnieuw voor. Hieronder ziet u een schermafbeelding van de Bridge Online‑monitoring. Daarop is te zien dat er meerdere requests actief zijn, maar dat er geen SQL‑statement wordt meegegeven en er geen rijen worden opgehaald.

Na ongeveer 30 tot 60 minuten resulteert elke request in een foutmelding, zoals in de onderstaande afbeelding te zien is.

forums · April 25, 2025, 5:40am

Statusupdate 25 april 2025

Afgeronde Verbetering

Op de statuspagina https://status.invantive.com toont de kleur nu ook de aanwezigheid van een of meer problematische locks:

groen: geen problematische locks,
rood: een of meer problematische locks of een andere ernstige storing.

Een problematische lock is een lock die er niet meer had mogen zijn, maar wel de voortgang van een ander verzoek hindert.

Voor zover bekend betreft het uitsluitend locks die gebruikt worden bij incrementele tabellen op Exact Online.

Volgende Wijziging

De volgende wijziging is in productie genomen: zodra er twee of meer problematische locks zijn, wordt de betrokken server automatisch herstart.

Deze wijziging zou de kans op en duur van problemen moeten verkleinen.

Geplande Wijziging 1

Eerst zal vastgesteld worden of het automatisch herstarten betrouwbaar werkt gezien de volumes en bijbehorende complexiteit van de omgevingen van het automatisch herstarten.

Geplande Wijziging 2

Daarna zal een volgende wijziging in productie genomen worden waarbij aan het einde van een verzoek eventueel aanwezige problematische locks naar verwachting automatisch opgeruimd worden.

Deze wijziging zou de duur van problemen verder moeten verkleinen.

Geplande Wijziging 3

Als alle voorgaande wijzigingen succesvol in productie genomen zijn, zal/zullen de onderliggende bug(s) naar verwachting beduidend minder of geen impact meer hebben op het gebruik.

Bug(s) die ten grondslag liggen aan de problematische locks worden nog steeds gesignaleerd zodat het ontwikkelteam hiervoor verbeteringen kan doorvoeren.

avn2 · May 1, 2025, 7:37am

Vandaag bij een klant dezelfde issue weer geconstateerd. Mogelijk hebben jullie er iets aan als ik dit blijf delen

Hieronder is een van de (gefaalde) requests na een tijdje:

forums · May 1, 2025, 10:42am

Dank voor het delen.

Op dit moment is delen alleen zinvol als er gelijktijdig geen “rode” status staat bij de dienst op https://status.invantive.com. Dan zou het gaan om een probleem dat nog niet automatisch gedetecteerd wordt. Het kan tot 5 minuten duren vooraleer de dienst rood wordt bij het optreden van een probleem.

forums · May 9, 2025, 11:11am

Terechte `itgentmm007`-meldingen

De tijden waarna een itgentmm007 optreedt is verdubbeld, aangezien gebruikers soms meerdere slots langdurig bezet houden met identieke downloads. Denk bijvoorbeeld aan:

4x SalesOrders downloaden met dezelfde of andere URL-parameters die elk circa een half uur draaien.
Meerdere langzame V2Flat-tabellen ophalen uit Teamleader in 8-voud parallel.

Het is niet mogelijk om de (oude) throttle op identieke tabelnamen in te schakelen om zo de slots niet in gebruik te nemen, omdat Microsoft Excel met Power Query meerdere onderling afhankelijke downloads van dezelfde dataset in parallel start, die altijd moeten kunnen eindigen.

Verhoging Maximaal Aantal Parallelle Downloads Bridge Online

Het maximaal aantal parallelle downloads is voor nog nieuw te nemen abonnementen verhoogd zodat dit probleem minder optreedt bij onervaren gebruikers. De limieten zijn verhoogd naar 6 of meer op basis van Evaluation configuration settings for Desktop - Power BI | Microsoft Learn. Er is geen formele documentatie bekend over de maximale parallelliteit van Power BI Service.

Abonnementsvorm	Oude Waarde	Nieuwe Waarde
SUB25EA02	4	6
SUB25FA02	4	6
SUBAATR	4	6
SUBAAUNP	4	6
SUBAACSR	4	6
SUB25EA10	8	12
SUBAACON	8	12
SUBAAEDU	8	12
SUBOEMGRW	4	6
SUBBOLOEM	4	16
SUBAAPLPN18	4	16
SUBAAPPNR18	4	16
SUBAAINV	4	16
SUBFPALL	8	16
SUBFP2ALL	8	24

Voor de volgende veelgebruikte maar niet meer nieuw verkochte abonnementsvormen zijn de limieten ongewijzigd:

SUBCMEA02
SUBCMFA02
SUBCMEA10

Gebruikers die deze abonnementsvormen nog hebben kunnen eventueel overstappen als volgt:

SUBCMEA02 → SUB25EA02
SUBCMFA02 → SUB25FA02
SUBCMEA10 → SUB25EA10

De nieuwe (verhoogde) limieten zullen in de nacht van 9 op 10 mei 2025 geactiveerd worden.

forums · May 13, 2025, 9:08am

De (waarschijnlijke) oorzaak is gevonden van deze problemen. Het vrijgeven van locks gebeurt niet altijd doordat de zogenaamde “obfuscatie” de werking van de programmatuur negatief beïnvloedt. Obfuscatie is het veranderen van de logica om de intellectuele rechten van Invantive beter te beschermen. Meer informatie is te vinden in:

github.com/obfuscar/obfuscar

Method Dispose (among others) obfuscated for a finite state machine for iterators (yield) excluding finally from being executed

geopend 08:47AM - 13 May 25 UTC

monty241

bug triage priority:low

### Normal Behavior When using iterators (`yield`), the compiler generates a fi…nite state machine using a private sealed class such as shown below: ![Image](https://github.com/user-attachments/assets/3127c169-c153-4c9b-9e67-7636dd47547f) Please note that several interfaces are implemented, such as `IDisposable` with body when the compiler deems it necessary: ![Image](https://github.com/user-attachments/assets/c61745b1-352b-42e9-9640-7abb8f5ef239) In this case, the `Dispose` calls various methods `m_Finally<999>()` when deemed necessary based upon the state. In the picture above, calls to `m_Finally2()` and `m_Finally4()` are visible in the code. It is expected that the generated `Dispose` method is still being executed when present after obfuscation. ### Current Behaviour The obfuscated variant using the logic from 2.2.48 of Obfuscar or DotBlur is a private sealed class `t`: ![Image](https://github.com/user-attachments/assets/a7e566ae-2d4a-4307-ad84-2eb8fc79e8d8) However, a method with the exact name `Dispose` is no longer present in the obfuscated private sealed class. This results in the logic shown in the second image no longer being executed upon dispose, including calls to the methods implementing `finally` not being executed. In a use case, `finally` not being called resulted in named locks not being released in a SQL engine (see https://forums.invantive.com/t/itgentmm007-kan-geen-vrij-slot-krijgen-op-throttle-throttlingbasedonlicense-voor-cap-groep-lic-na-1-920-seconden-te-hebben-gewacht/5390 (Dutch)) when not all values ("rows") had been yielded. ## Patch A patch for Obfuscar is available to solve this problem, as a diff from DotBlur. We are currently testing it for completeness and will then add it as a separate reply.

Invantive gebruikt een eigen variant van Obfuscar genaamd “DotBlur” met enkele extensies.

Mogelijkerwijs leidt deze bug in de obfuscatie ook tot problemen in andere delen van Invantive Cloud bij het vroegtijdig afbreken van een download, zoals met ophalen van een preview van een table.

Momenteel vinden tests plaats met een gecorrigeerde versie. Bij succes zal een verbeterde versie in de loop van 13 mei 2025 in productie genomen worden.