When you use queues and topics, messages will be removed from the message store once the message consumers acknowledge that the messages are received. You can configure message redelivery to a subscriber as explained below.
Configuring the maximum number of attempts to redeliver a message
If you want to limit the number of times the message broker attempts to redeliver the message, you can set the
maximumRedeliveryAttempts element in the
broker.xml file as follows:
Note that the above configuration specifies the total number of attempts to redeliver the message after the original delivery attempt. For example, when the first attempt to send the message fails, there will be another 10 attempts to redeliver the message. After the maximum number of attempts to redeliver the message are breached, the message is sent to the Dead Letter Channel. This is useful when the client application does not acknowledge the message because an operation on the message failed.
If the message is successfully delivered on a redelivery attempt, the JMSRedelivered field is set to 'true' in the message header, allowing the client to determine whether the message was delivered by the original attempt or on a later attempt.
Delaying message redelivery to a subscriber
With this feature, a subscriber client will be able to delay the redelivery of messages to the subscriber (when the message has already been rejected). Any message that comes to the client with the redelivery flag true will get delayed. The delay can be set using a custom system property. New messages that are received by the client does not get blocked due to the redelivered message. Therefore, redelivered messages are unordered.
When using this feature, it may be necessary to use “Per Message Acknowledgements” depending on the use case.
This system property can be set as shown below. This value is given in milliseconds. The default value is 0.