Handling poison messages in ASF

Within the Application Server Facilities, poison message handling is handled slightly differently to elsewhere in IBM MQ classes for JMS.

For information about poison message handling in IBM MQ classes for JMS, see Handling poison messages in IBM MQ classes for JMS.

When we use Application Server Facilities (ASF), the ConnectionConsumer, rather than the MessageConsumer, processes poison messages. The ConnectionConsumer requeues messages according to the BackoutThreshold and BackoutRequeueQName properties of the queue.

When an application uses ConnectionConsumers, the circumstances in which a message is backed out depend on the session that the application server provides:

  • When the session is non-transacted, with AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE, a message is backed out only after a system error, or if the application terminates unexpectedly.
  • When the session is non-transacted with CLIENT_ACKNOWLEDGE, unacknowledged messages can be backed out by the application server calling Session.recover().

    Typically, the client implementation of MessageListener or the application server calls Message.acknowledge(). Message.acknowledge() acknowledges all messages delivered on the session so far.

  • When the session is transacted, unacknowledged messages can be backed out by the application server calling Session.rollback().
  • If the application server supplies an XASession, messages are committed or backed out depending on a distributed transaction. The application server takes responsibility for completing the transaction.

The embedded JMS provider in WebSphere Application Server, Version 5.0 and Version 5.1 handles poison messages in a different way to that just described for IBM MQ classes for JMS. For information about how the embedded JMS provider handles poison messages, see the relevant WebSphere Application Server product documentation.

Parent topic: Plan an application with ASF


Related concepts