The other day I felt a compelling need to implement a JMS redelivery scenario. The exact scenario I'd been trying to handle was:
- my message is in an ActiveMQ queue or topic
- its processing fails, because of some exception - ie. database access exception due to server nonavailability
- since we get an exception, the message is not handled properly, we may want to retry processing attempt some time later
- of course, for the redelivery to happen we need the message to stay in the ActiveMQ queue - fetching messages from the queue will be stopped until the redelivery succeeds or expires
See how this can be done after the jump :)
For this to happen, I've tried implementing Apache Camel route, but as it turns out, Camel fails to deliver facilities for exact JMS redelivery. It is possible to set JMS connection in transacted
mode, but the redeliveries happen one after another and fixed times.
What I've ended up doing was implement a servicemix-jms endpoint. I've used this configuration for it:
As you can see, we lookup a couple of things in JNDI registry, so you need to have them configured on the Servicemix side - a sample config presented farther in this entry.
The bean responsible for configuring redelivery settings is activationSpec
. You can set various things with it, like:
- initial redelivery delay
- maximum number of redeliveries
- backoff multiplier
What is really important in jms:endpoint
config for this to work are:
Servicemix should have the following entries in its jndi registry:
When the redeliveries are exhausted, message is routed to global Dead Letter Queue called ActiveMQ.DLQ. Since this is a single bag for all the failed messages from all queues, you may want to configure this aspect differently. For example you can tell ActiveMQ to create a single DLQ for each queue. Use this config to achieve it - the changes should be made to Broker configuration.
More on the subject of redelivieries in ActiveMQ can be found at http://activemq.apache.org/message-redelivery-and-dlq-handling.html