Best Practices from Oracle Development's A‑Team

Effect of Queue and JCA Settings on Message Retry by JMS Adapter

Shreenidhi Raghuram
Consulting Solutions Architect


This blog is intended to share some knowledge about the effects of Queue Level Redelivery Settings and Adapter level Retry Settings on message processing by JMS Adapter.  It is also intended to provide some useful insights that help in designing retry mechanisms into an integration system. Specifically, this blog illustrates the Retry behavior of JMS Adapter and how it is impacted by these settings.


Consider an Integration system that uses JMS Adapter to consume message from a queue and deliver to an End System after performing BPEL processing. The Figure below depicts such a simple system. Note that the source queue is configured with an error queue to hold the failed messages.


Adapter level Retry Settings

First, let’s look at the Adapter level Retry Settings that are available to configure on the JMS Adapter Consumer service. The settings below are typically used to configure the retry behavior of inbound JMS Adapter consumers:

  1. Jca.retry.count --> example value 3
    Jca.retry.interval --> example value 2
    Jca.retry.backoff --> example value 2

Assume that the end system is down. During such an error condition when the message cannot be successfully processed and delivered to the End System, the JMS Adapter retries the processing of the failed message, using the above retry settings. For the above example values, the adapter retries a failed message after 2 , 6  and 14 seconds from the time of first failure.

Now, assume the end system is down even after the 3 retries.  The expectation in most integration flows is that the message rolls back to the source queue and can be found in the error destination. This will help in manually recovering the failed message after the error condition is resolved.

However, under certain conditions, the JMS Adapter can reject a failed message after exhausting the configured number of retries. When this happens, the message is no longer available at the source queue for recovery. The rejected messages are handled by the Adapter Rejection Handler. Refer here for details on rejection handlers for Adapters.

Queue Level Redelivery Settings

At this point, let us look at Queue Level Redelivery Settings. When redelivery is set at the queue level, any messages that fail to process and which are rolled back to the queue will be redelivered for processing. If the number of failures for the message exceeds the redelivery count, the message is redirected to the error destination.

All messaging providers support some form of queue redelivery settings. For instance, a Weblogic JMS has the Redelivery Limit setting, and AQ JMS provides the same using the max_retries setting of a queue.

Messaging Provider

Redelivery settings

Other related settings

Weblogic JMS

Redelivery Limit

Expiration Policy=Redirect, Redelivery Delay Override




Note that Weblogic JMS can be configured to discard or log the failed messages instead of redirecting to an error destination.

Failure to Rollback

Under what conditions does JMS Adapter reject messages that are submitted to it by the queue for reprocessing?

When the queue redelivers a message to the adapter more number of times than it can retry, the adapter rejects the message

Hence, the condition below will ensure that the message properly rolls back to the source queue rather than be rejected by the Adapter.

Number of Redeliveries by the Queue <=  Retry Count of Adapter Service

Note that when Jca.retry.count is not set at the adapter service level, the GlobalInboundJcaRetryCount setting takes effect. The default value of GlobalInboundJcaRetryCount is -1, which implies an infinite number of retries.

Refer to the Adapter’s Guide section here for more information on setting the retry properties.

The table below lists some sample values of the settings and the behavior observed after repeated failures:



Queue Redelivery

Behavior after repeated Failure




Message rejected by adapter




Message Rolled back to Error Queue




Message Rolled back to Error Queue

Not set



Message Rolled back to Error Queue

Not set



Message rejected by adapter



Incorrect settings of the queues and adapters could lead to undesired behavior in recovery of messages during failure conditions. We have seen a few such situations in this blog. With proper settings, we can design integration systems to exhibit consistent error handling and recovery behaviour.



Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha