3569999 - Delay in processing/retrying messages from a JMS Queue in Cloud Integration

In Cloud Integration, one or a mix of below symptoms are observed, when messages are stored in a Java Message Service (JMS) Message Queue, which later will be processed by another (consumer) iflow(s):

• The retry of a failed message occurs later than the 'Retry Interval' configured in the JMS Sender Adapter
  Eg. The 'Retry Interval' is configured with a value of 1 minute, but the retry attempt takes place 20 minutes after the initial failed attempt 
  
  
• A period of delayed processing happens even at initial processing attempts from the JMS Queue
  Eg. A producer iFlow is sending messages to a JMS Queue but these messages are not getting processed for some time after they arrived onto the queue 
  
  
• Order of the processed messages FROM the JMS Queue is changed compared to the order the messages originally were placed INTO the JMS queue

JMS Queue processing and error handling is a complex topic and needs in-depth knowledge of the product to avoid or at least understand why the above symptoms may occur, and to understand why such delays in processing do not necessarily indicate any issue or incorrect behaviour.

This KBA aims to clarify why such delays in processing may occur.

Important - the below information is specific for non-exclusive JMS queues. The retry mechanism for exclusive queues is completely different to that of non-exclusive queues. There is no error queue, and the retry process is handled by the JMS broker.

• Cloud Integration
• SAP Integration Suite

CPI, HCI, Integration Suite, cloud integration, java message service, jms, message queue, delay, processing, slow, jms message queue, jms processing, delay retry, retry interval, JMS Queue, processing, retrying, order, retries, JMS sender, JMS adapter, reprocess, reprocessing , KBA , LOD-HCI-PI-CON-SOAP , SOAP Adapter , How To