When JMSXDeliveryCount get increased

Question

What are the conditions in which JMSXDeliveryCount is increased in WebSphere MQ. I need all the scenarios under which it can happen.

Answer 1

The JMSXDeliveryCount is incremented every time a message is re-delivered to a consumer. A message could be redelivered:

1) A consumer using the Client Acknowledge mode received the message earlier did not call acknowledge() on that message.

2) A consumer received the message in a transaction, did not call a commit or called a rollback.

EDIT:

If the JMS Client is unable to process the message due to some bad JMS headers, then such a message(known as poison message) will not be delivered to application and JMS client will internally rollback that message. In this case also JMSXDeliveryCount is incremented.

In IBM MQ, have you set Backout Queue and Backout Threshold properties for the queue from which messages are being retrieved? JMS Client will put such bad messages to the backout queue once the Backout Threshold is reached. This is to avoid same message is retrieved by JMS client again and again thus blocking other good messages from being delivered to application.

Answer 2

Thanks a lot to other i got the answer form web and pasting it here so that it will be helpful for other.

The circumstances under which a message can be redelivered to the consumer depend on the session’s acknowledgement mode:

• Non-transacted sessions that choose AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE acknowledgement mode have messages redelivered to a consumer when the application's onMessage() method throws an exception. The client runtime catches the exception, and then calls onMessage() again. Exceptions are caught and reported to the Connection's ExceptionListener. Setting a limit to redelivery attempts limits the redelivery count. See note below.

• Non-transacted sessions that choose SINGLE_MESSAGE_ACKNOWLEDGE or CLIENT_ACKNOWLEDGE acknowledgement mode, messages are redelivered when the application calls Session.recover().

• With TRANSACTED acknowledgement mode , messages are redelivered when an application rolls back the transaction.

An application could get into a loop where it repeatedly receives a message that causes the application to fail and then the same message is redelivered again and again. An infinite redelivery loop is sometimes referred to as a "poison message scenario".

• Point-to-point (queue-based) consumer clients that want to constrain redelivery attempts can limit the number of deliveries of a message to the consumer by specifying a parameter on the ConnectionFactory. . This is done with progress.message.jclient.ConnectionFactory.setMaxDeliveryCount(java.lang.Integer value) methos. A value of 0 (default) indicates no limit.

Messages that have exceeded the redelivery limit and have not been acknowledged will be processed according to properties specified in the message or will be discarded.

If the message property JMS_SonicMQ_preserveUndelivered is set to true, the message will be placed on the SonicMQ.DeadMessage queue (or an alternate destination specified by the JMS_SonicMQ_destinationUndelivered property), and the message property JMS_SonicMQ_undeliveredReasonCode will be set to the error code progress.message.jclient.Constants.UNDELIVERED_DELIVERY_LIMIT_EXCEEDED. If the 'preserveUndelivered' property is not set, the message will be discarded.

• Alternatively, JMS applications (such as Pub-Sub topic-based clients and Sonic ESB Services/Processes) can perform detection on their own by getting and acting on the value of the JMSXDeliveryCount property on each message. The JMSXDeliveryCount property uses an int to specify the number of delivery attempts for a message. Gets its value with javax.jms.Message.getIntProperty("JMSXDeliveryCount") method. The value of this property is incremented every time a message is given to a consumer. Delivery counters are maintained in the client runtime for messages waiting to be delivered to a consumer object. If a consumer is closed/terminated and recreated/restarted, the counter for each message sent to the consumer is reset to 0.