Message Delivery Attempts Limitation 

This is supported only for the Point-to-Point scenarios.

The JMS provider attempts to deliver a message to a consumer until the message delivery is acknowledged. If the session is recovered instead, the provider resends all messages starting after the last acknowledged one. This behaviour can be  problematic in cases such as  when a particular message reproducibly causes a session recovery, since this leads to an endless cycle.

A message-driven bean (or an asynchronous consumer) throws a RuntimeException while processing a particular message. This could happen due to an application programming error, or because a corrupt data is found inside the message. The JMS provider will attempt to deliver the message again, but the problem might to persist, so that the application is trapped in an endless loop.

You can limit the number of attempts to deliver a message. When exceeding this limit, a message is considered undeliverable (a so-called “dead message”), and it is processed in a special way.

...

       1.      You can set  the JMSXDeliveryCount property for each outgoing message. For information on administrating the JMS provider, see JMS Administration in the Administration Manual.

       2.      The message is sent automatically to an error messages queue (dead message queue) after n unsuccessful delivery attempts. This is done by the JMS provider.

       3.      The JMS provider allows you to access to the error queue for further processing.

For information on the Shell commands that you can use to manage dead messages, see JMS in the Administration Manual.