1. Create an MDB which listens to a durable Queue (let's say source destination). On the onMessage() of this MDB, send all the incoming messages to another Queue (target destination). 2. Enable message counters on hornetq-configuration.xml 3. Deploy this MDB, pause the source destination 4. Send 20K messages, verify the number of messages at the source destination via JMX console 5. Resume the source destination 6. Kill the server using kill -9 <pid> a few times while the messages are being processed 7. Verify the number of messages at target destination , once all the message are consumed from the source destination 8. You would notice 5-10 dropped messages 9. "Could not find new XAResource to use for recovering non-serializable XAResource" can be seen on the server log Note: Make sure to annotate this MDB to use JTA transactions. Hence, the following annotations are mandatory : @TransactionManagement(value= TransactionManagementType.CONTAINER) @TransactionAttribute(value= TransactionAttributeType.REQUIRED)

The Transactions Recovery Manager searched for XIDs in need of recovery in such a way that sometimes recoverable XIDs were missed. This happened when the recovery list changed while the Recovery Manager was reading it. This has been addressed by causing the list of XIDs in need of recovery to be cumulative, rather than just reading the current list and previous list. When using TX Resource managers, which are JDBC drivers that support XA, it is an antipattern to rely on the order of the XIDs the Resource Manager returns to you, because you risk losing XIDs and causing heuristic exceptions, in which you will need to manually commit or roll back the transaction.