JMS message redelivery

If your Message Driven Bean (MDB) is part of the JTA transaction and for some reason the transaction is rolled back, according to the specification the message redelivery semantics apply. What does that mean?


It is up to the server on how to handle the message redelivery. Some servers decide to redeliver the message straightaway and some will try a couple of times before giving up. Either way it will have an adverse effect. It would be nice if you can control this behavior, but then the following questions would come into mind.

  • What is the delay time for the next redelivery?

In some situations (e.g. service temporarily unavailable), you would prefer to try again later, i.e. not immediately. If the message is redelivered straightaway without any delay, this would do no good and only increase the load of the server.

  • How many attempts should the redelivery be carried out?

Again in some situations, you do not want to retry the operation forever. It would be nice if you can specify the maximum number of retries. This brings up the next question.

  • What happens to the message after the number of retries is exhausted?

If it reaches the retry limit, should the message be discarded or routed to another destination?


Fortunately, most of the JMS servers - both commercial and open source - provide some way to configure this behavior. Let us look at some of the popular servers to see what they offer.


Oracle/BEA Weblogic 10

The WebLogic Server provides the following configurable parameters.

  • Redelivery Delay - this parameter allows you to control the delay time for the redelivery.
  • Redelivery Limit - this allows you to put a limit on the number of times that the server will attempt to redeliver the message.
  • Error Destination - if it is specified, any expired messages will be routed to the specified destination. Otherwise they will be discarded.

For more details, please refer to this document - Managing Rolled Back, Recovered, Redelivered, or Expired Messages.


IBM WebSphere 6.1

The WebSphere Server supports the following configurable parameters.

  • Maximum Failed Deliveries - it allows you to specify the number of times a message on a destination will be delivered before it is considered as expired.
  • Exception Destination - if specified, any expired messages will be routed to the specified destination.

Unfortunately, it does not support the configuration of redelivery delay.

For more details, please refer to this document - How WebSphere Application Server V6 handles poison messages


JBoss 5.0

The JBoss Server supports the following parameters.

  • DefaultRedeliveryDelay - it lets you delay a redelivery attempt.
  • DefaultMaxDeliveryAttempts - the maximum number of times delivery will be attempted for a message before the message is removed or sent to the Expiry Queue.
  • DefaultExpiryQueue - this is the queue to hold all expired messages.

For more details, please refer to the JBoss Messaging User Guide