ActiveMQ(5.10.0) - Message Redelivery and DLQ Handling

When messages expire on the ActiveMQ broker (they exceed their time-to-live, if set) or can’t be redelivered, they’re moved to a dead-letter queue, so they can be consumed or browsed by an administrator at a later point.

Messages are redelivered to a client when any of the following occurs:

1. A transacted session is used and rollback() is called.
2. A transacted session is closed before commit is called.
3. A session is using CLIENT_ACKNOWLEDGE and Session.recover() is called.
4. A client connection times out (perhaps the code being executed takes longer than the configured time-out period)

A client application usually has a good reason to roll back a transacted session or call recover() —it may not be able to complete the processing of the message(s) because of its inability to negotiate with a third-party resource, for example. But sometimes an application may decide to not accept delivery of a message because the message is poorly formatted. For such a scenario, it doesn’t make sense for the ActiveMQ broker to attempt redelivery forever.

A configurable POJO is associated with the ActiveMQ connection that you can tune to set different policies. You can configure the amount of time the ActiveMQ broker should wait before trying to resend the message, whether that time should increase after every failed attempt (use an exponential back-off and back-off multiplier), and the maximum number of redelivery attempts before the message(s) are moved to a dead-letter queue.

The broker transmits the default delivery policy that he prefers to a client connection in his BrokerInfo command packet. But the client can override the policy settings by using the ActiveMQConnection.getRedeliveryPolicy() method:

RedeliveryPolicy policy = connection.getRedeliveryPolicy();
policy.setInitialRedeliveryDelay(500);
policy.setBackOffMultiplier(2);
policy.setUseExponentialBackOff(true);
policy.setMaximumRedeliveries(2);

Once a message‘s redelivery attempts exceeds the maximumRedeliveries configured for the Redelivery Policy, a "Poison ack" is sent back to the broker letting him know that the message was considered a poison pill. The Broker then takes the message and sends it to a Dead Letter Queue so that it can be analyzed later on.

By default, there’s one dead-letter queue for all messages, called AcitveMQ.DLQ, which expired messages or messages that have exceeded their redelivery attempts get sent to. You can configure a dead-letter queue for a hierarchy, or an individual 288 CHAPTER 11 ActiveMQ broker features in action destination in the ActiveMQ broker configuration, like in the following example, where we set an IndividualDeadLetterStrategy:

<destinationPolicy>
    <policyMap>
        <policyEntries>
            <policyEntry queue=">">
                <deadLetterStrategy>
                    <individualDeadLetterStrategy
                        queuePrefix="DLQ."
                        useQueueForQueueMessages="true"
                        processExpired="false"
                        processNonPersistent="false"/>
                </deadLetterStrategy>
            </policyEntry>
        </policyEntries>
    </policyMap>
</destinationPolicy>

Broker Redelivery (v5.7)

Typically a consumer handles redelivery so that it can maintain message order while a message appears as inflight on the broker.
This means that redelivery is limited to a single consumer unless that consumer terminates. In this way the broker is unaware of redelivery.
With broker redelivery, it is possible to have the broker redeliver a message after a delay using a resend. This is implemented by a broker plugin that handles dead letter processing by redelivery via the scheduler. This is useful when total message order is not important and where through put and load distribution among consumers is. With broker redelivery, messages that fail delivery to a given consumer can get immediately re-dispatched.

The feature is enabled via xml configuration of the form:

<broker xmlns="http://activemq.apache.org/schema/core"    schedulerSupport="true" >
    ....
    <plugins>
        <redeliveryPlugin fallbackToDeadLetter="true" sendToDlqIfMaxRetriesExceeded="true">
            <redeliveryPolicyMap>
                <redeliveryPolicyMap>
                    <redeliveryPolicyEntries>
                        <!-- a destination specific policy -->
                        <redeliveryPolicy queue="SpecialQueue" maximumRedeliveries="4" redeliveryDelay="10000" />
                    </redeliveryPolicyEntries>

                    <!-- the fallback policy for all other destinations -->
                    <defaultEntry>
                        <redeliveryPolicy maximumRedeliveries="4" initialRedeliveryDelay="5000" redeliveryDelay="10000" />
                    </defaultEntry>
                </redeliveryPolicyMap>
            </redeliveryPolicyMap>
        </redeliveryPlugin>
    </plugins>
    ....
</broker>

The familiar Redelivery Policy has been extended to take a matching destination.
fallbackToDeadLetter controls the action when there is no matching redeliver policy for a destination. Defaults to true so regular DLQ processing ensues.
sendToDlqIfMaxRetriesExceeded controls the action when the retry limit is exceeded. Defaults to true so regular DLQ processing ensues. When false, the message is dropped.

Note: broker schedulerSupport must be enabled for this feature to work.