ActiveMQ (5.10.0)-Message redelivery and DLQ handling

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

Messages is redelivered to a client if any of the following occurs:

1. A transacted session is used and rollback () is called.
2. A transacted session is closed before commits is called.
3. A session is the 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 have a good reason to roll back a transacted session or call recover ()-it could not be able to Complete the processing of the message (s) because of it inability to negotiate with a third-party resource, for example. But sometimes an application could decide to not accept delivery of a message because the message was 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 so can tune to set different policies. Can configure the amount of time the ActiveMQ broker should wait before trying to resend the message, whether that Tim E should increase after every failed attempt (use of exponential back-off and Back-off multiplier), and the maximum number of Redelivery attempts before the message (s) is 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 this message was considered a poison pill. The Broker then takes the message and sends it-a Dead letter-Queue so that it can is analyzed later on.

By default, there's one dead-letter queue for all messages, called ACITVEMQ.DLQ, which expired messages or MESSAG Es that has exceeded their redelivery attempts get sent to. You can configure a dead-letter queue for a hierarchy, or an individual 288 CHAPTER one ActiveMQ broker features in action Destination in the ActiveMQ broker configuration, as in the following example, where we set an Individualdeadletterstrat Egy

 
 
<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 this it can maintain message order while a message appears as inflight on the B Roker.
This means, Redelivery is limited to a, consumer unless that consumer terminates. The-this-the broker is unaware of Redelivery.
With broker Redelivery, it's possible to has the broker Redeliver a message after a delay using a resend. This was implemented by a broker plugin that handles dead letter processing by redelivery via the scheduler. This was useful when the total message order was not important and where through put and load distribution among consumers was. With broker Redelivery, messages this 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 are 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 is enabled for the feature to work.

ActiveMQ (5.10.0)-Message redelivery and DLQ handling