MDB Failure Handling
Internal
Relevance
EAP 6.4.10
Overview
This article addresses failure handling in an MDB context. It was written while experimenting with EAP 6.4 and a HornetQ-based messaging subsystem.
Failure Handling Specification
JSR 318 Enterprise JavaBeans Version 3.1 EJB Core Contract and Requirements, Section 5.4.18 "Dealing with Exceptions" mentions that MDBs should not throw RuntimeExceptions. If a RuntimeExceptions that is not an application exception, the container will transition the MDB instance that triggered the exception in the "does not exist" state. If the MDB uses bean-managed transaction demarcation, the container should not acknowledge the message. From the client perspective, the message consumer continues to exist. If the client continues to send messages to the destination associated with the container, the container can delegate the message to another MDB instance.
WildFly/HornetQ-Backed MDB Container Behavior on Failure
The behavior of the WildFly/HornetQ-Backed MDB container in presence of a message processing failure depends on the transactional context (container manager or bean managed) and whether the error materializes as an unchecked application exception or a generic unchecked exception (the MDB onMessage() method cannot throw checked exceptions).
The most common situation is an MDB configured to use container managed transactions, with the transactional attribute set to REQUIRED. The message delivery and processing is enclosed by a JTA transaction that is started by the MDB container.
If the MDB uses container managed transactions but the transactional attribute is set to NOT_SUPPORTED TODO.
If the MDB uses bean managed transactions TODO.
If the message delivery occurs in a container-managed transactional context, the HornetQ resource adapter acknowledges the message when it first receives from the HornetQ JMS provider. This behavior can be thought as "removing the message from the queue". The resource adapter attempts to deliver the message in a loop until either it is consumed by an MDB instance or the message is sent to the DLQ. Who loops and Who sends the message to DLQ?
Does this mean that if the JVM fails while the message is processed in the loop, the message is lost?
The current transaction is automatically rolled back. The MDB container's transactional interceptor catches the RuntimeException and rolls back the transaction, by invoking javax.transaction.Transaction.setRollbackOnly().
The MDB instance that triggered the failure is destroyed. The @PreDestroy callback, if exists, is invoked, and the instance is discarded from the pool. Upon re-delivery, if any, a new instance to handle the message will be created.
Message Delivery Occurs in a Non-Transactional Context
How to Handle Failure in a Transactional Context
Redelivery and Dead Letter Queue
The message redelivery count on failure is not an attribute of an individual MDB container, as the "dLQMaxResent" configuration attribute seems to suggest, but of the HornetQ destination. In EAP 6.4.10, "dLQMaxResent" is ignored. If an MDB fails to process a message in a transactional context, the transaction is rolled back and the message is "put back on the queue". The message will be redelivered by the HornetQ destination, subject to redelivery rules sent on the destination. Upon failure, the message will be redelivered to the same MDB container, if it is the only consumer for that queue, or to a different MDB container if there is more than one MDB container listening to the queue.