Introduction
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.
Detail
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:
- 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 |
|
AQ JMS |
Max_retries |
Retry_delay |
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:
|
Jca.retry.count |
GlobalInboundJcaRetryCount |
Queue Redelivery |
Behavior after repeated Failure |
|
3 |
-1 |
5 |
Message rejected by adapter |
|
6 |
-1 |
5 |
Message Rolled back to Error Queue |
|
0 |
-1 |
0 |
Message Rolled back to Error Queue |
|
Not set |
5 |
5 |
Message Rolled back to Error Queue |
|
Not set |
0 |
2 |
Message rejected by adapter |
Summary
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.
References
- User’s Guide for Adapters: http://docs.oracle.com/cd/E28280_01/integration.1111/e10231/toc.htm
- Configuring Weblogic JMS: http://docs.oracle.com/cd/E28280_01/web.1111/e13738/toc.htm
-Shreeni
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission