What are the conditions in which JMSXDeliveryCount is increased in WebSphere MQ. I need all the scenarios under which it can happen.
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.
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".
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With