Chapter 19. Message Redelivery and Undelivered Messages
Message delivery can be unsuccessful, for example, if the session used to consume a message is rolled back. An undelivered message returns to the queue ready to be redelivered. However, this means multiple unsuccessful deliveries are possible, so messages can remain in the queue, clogging the system.
There are two options for these undelivered messages:
- Delayed Redelivery
- Message delivery can be delayed to allow the client time to recover from transient failures and not overload its network or CPU resources.
- Dead Letter Address
- Configure a dead letter address, to which messages are sent after being determined undeliverable.
These options can be combined for maximum flexibility.
19.1. Delayed Redelivery
Delaying redelivery can be useful for clients that regularly fail or roll back. Without delayed redelivery, the system can get into a "thrashing" state, where delivery fails and the client rolls back to attempt redelivery ad infinitum, consuming CPU and network resources.
19.1.1. Configuring Delayed Redelivery
Delayed redelivery is defined in the
address-setting configuration:
<!-- delay redelivery of messages for 5s --> <address-setting match="jms.queue.exampleQueue"> <redelivery-delay>5000</redelivery-delay> </address-setting>
If a
redelivery-delay is specified, HornetQ will wait that many milliseconds before redelivering the messages. Redelivery delay is enabled by default and set to 60000 (1 minute).
Address wildcards can be used to configure redelivery delay for a set of addresses (see Chapter 11, Understanding the HornetQ Wildcard Syntax), so redelivery delay does not have to be specified for each address individually.
