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

Vragen
, ,
1

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

2

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.

3

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.

4

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.

6

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.