Both TIM report and alert details data taken from IDB database, following are steps for the data flow from source until it ready to check in IDB,

1. Transaction enters the IFM System sent via webservice request

2. Transaction will go through the regular detection process.

3. After detection is performed, the same transaction is passed to two databases.

  • To APP database in sync mode by using a direct insert to database
  • To IDB database in async mode by using AMQ. Since IFM has to perform detection in milliseconds, IDB insertion is being made in async mode.

4. The IDB consumer then consumes the message from the queue and inserts it into the IDB database.


What can cause a delay in the transaction to reach IDB:

  1. Slow insertion queries. Those can be improved by DBA examining execution plans and pinning those and maintaining DB with stats on table and indexes as part of regular DB maintenance activity
  2. IDB consumer was down and hence messages got piled up requiring recent messages to get delayed
  3. Persistence store full error you saw in another case, causing messages not to enter to queue itself and lost
  4. Maintaining DB performance and regular system performance so the application can work smoothly
  5. Unexpected increase in load (TPS) causing IDB messages to pile up in queue causing the delay for later messages

Please make sure no messages left in AIS Internal Queue "ActiveMQ.DLQ" to have more space, if you find any, please clear the queue by referring following link:

https://q2technologies.freshdesk.com/en/support/solutions/articles/70000582561-how-to-clear-ais-internal-queue-


Note:

ActiveMQ.DLQ stores expired messages from all queues. The messages get expired after it has exhausted its retries. As for IDB messages, those will be removed from AMQ and transferred to ActiveMQ.DLQ after max no of retries (FF_AMQNumberOfMessageHandlingRetries from FF_applicationConfig.ini file), so these messages can't be recovered. However, these messages keep occupying space in the Persistence store.There is no impact of clearing this queue as those messages are any way expired and can not be recovered.

You can reset DLQ, by running the FF_resetQueue Execution plan from the executables package, with the parameter "ActiveMQ.DLQ".


NB:

You can also check data existence using partition in FF_ALL_TRANSACTIONS table using attached query