MessageListener Exception Handling.

This article talks about exception handling inside a message listener's onMessage() method:

public void onMessage(Message message);

The asynchronous API does not allow an application to throw any checked exception, and the JMS API JavaDoc specification says as follows.

"It is a client programming error for a MessageListener to throw an exception."

The above statement basically tells the JMS messaging providers to handle the (runtime) exception thrown from a message listener in their own way (undefined).

Below are some of possibilities that a messaging provider can do when received an exception thrown from the onMessage() method.

• Set the message redelivery flag to true and redelivery the message to the message listener. The number of times a provider will attempt to redeliver a message is undefined.
• Send the message to the provider defined dead-message-queue and continue delivering the next message.
• Stopped message delivery to the listener.
  

While a messaging provider may define and specify the behavior, an application should avoid tying with a specific vendor whenever possible. It would be probably a better choice to resolve application's business logic precisely and not rely a messaging provider to guess an error from the application.

An application may consider to define and configure an error queue. An error queue is a destination used to store messages that an application can not process. When a message listener encounters an exception while processing a message, the application could send the "trouble message" to the error queue. The application can then acknowledge and continue processing the next message delivered from the messaging provider. This ensures that messages continue to flow with a predicted behavior.

Messages in the error queue can be replayed at a later time to help identifying the root cause of the exception.

A runtime exception thrown from a message listener could cause unpredictable behavior from a messaging provider and thus should be avoided. A good programming practice is to handle any possible exceptions that could be generated from within the message listener.