Up until now we have supposed that every message has been successfully consumed by the consumer layer. However in a real high-frequency transactional environment this is not always possible. Remember from Chapter 1, Getting Started with HornetQ, we could have a connection error due to the fact that the MongoDB server is down.
So there are two possibilities when consuming a message, if it is consumed in the correct way, you can commit the session so HornetQ will remove the message from the queue where it was stored. If something goes wrong you can roll back the session in this case the message is put on the queue some other time where it was stored.
This means that if the error persists it is possible that the message is redelivered again and again. To avoid this, HornetQ offers two main possibilities:
Delayed redelivery: You can configure some delay time to let the client return in a successfully delivered state
Dead letter address: All messages that are not delivered...