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

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.