| <div class="wiki-content maincontent"><h3>Overview</h3><p>Messages are redelivered to a client when <strong>any</strong> of the following occurs:</p><ol><li>A transacted session is used and <strong><code>rollback()</code></strong> is called.</li><li>A transacted session is closed before <strong><code>commit()</code></strong> is called.</li><li>A session is using <strong><code>CLIENT_ACKNOWLEDGE</code></strong> and <strong><code>Session.recover()</code></strong> is called.</li><li>A client connection times out (perhaps the code being executed takes longer than the configured time-out period).</li></ol><p>The broker transmits the default delivery policy that he prefers to a client connection in his <strong><code>BrokerInfo</code></strong> command packet. But the client can override the policy settings by using the <strong><code>ActiveMQConnection.getRedeliveryPolicy()</code></strong> method:</p><structured-macro ac:macro-id="dd38acae-bc3e-4105-babf-3fcfc4a791ad" ac:name="code" ac:schema-version="1"><parameter ac:name="">java</parameter><plain-text-body>RedeliveryPolicy policy = connection.getRedeliveryPolicy(); |
| policy.setInitialRedeliveryDelay(500); |
| policy.setBackOffMultiplier(2); |
| policy.setUseExponentialBackOff(true); |
| policy.setMaximumRedeliveries(2); |
| </plain-text-body></structured-macro><p>Once a message's redelivery attempts exceeds the <strong><code>maximumRedeliveries</code></strong> configured for the <link><page ri:content-title="Redelivery Policy"></page></link>, 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.</p><p>The default Dead Letter Queue in ActiveMQ is called <strong><code>ActiveMQ.DLQ</code></strong>; all un-deliverable messages will get sent to this queue and this can be difficult to manage. So, you can set an <strong><code>individualDeadLetterStrategy</code></strong> in the destination policy map of the <strong><code>activemq.xml</code></strong> configuration file, which allows you to specify a specific dead letter queue prefix for a given queue or topic. You can apply this strategy using wild card if you like so that all queues get their own dead-letter queue, as is shown in the example below.</p><structured-macro ac:macro-id="f2c2bbc8-1e76-442a-9ef3-e5cf3e3ce3ce" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body><broker> |
| |
| <destinationPolicy> |
| <policyMap> |
| <policyEntries> |
| <!-- Set the following policy on all queues using the '>' wildcard --> |
| <policyEntry queue=">"> |
| <deadLetterStrategy> |
| <!-- |
| Use the prefix 'DLQ.' for the destination name, and make |
| the DLQ a queue rather than a topic |
| --> |
| <individualDeadLetterStrategy queuePrefix="DLQ." useQueueForQueueMessages="true"/> |
| </deadLetterStrategy> |
| </policyEntry> |
| </policyEntries> |
| </policyMap> |
| </destinationPolicy> |
| |
| </broker> |
| </plain-text-body></structured-macro><p>See the <link><page ri:content-title="Redelivery Policy"></page></link> section for some more detail on the policy options.</p><h3>Automatically Discard Expired Messages</h3><p>Some folks simply need expired messages to be discarded instead of sent to the DLQ i.e., skip the DLQ entirely. This simplifies the management of the DLQ so that you're not sifting through loads of expired messages to find messages with real problems. To tell ActiveMQ to just discard expired messages, configure the <strong><code>processExpired</code></strong> property to false on a dead letter strategy:</p><structured-macro ac:macro-id="a20b65dd-1508-4672-9196-d47d24e52f57" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body><broker> |
| |
| <destinationPolicy> |
| <policyMap> |
| <policyEntries> |
| <!-- Set the following policy on all queues using the '>' wildcard --> |
| <policyEntry queue=">"> |
| <!-- |
| Tell the dead letter strategy not to process expired messages |
| so that they will just be discarded instead of being sent to |
| the DLQ |
| --> |
| <deadLetterStrategy> |
| <sharedDeadLetterStrategy processExpired="false" /> |
| </deadLetterStrategy> |
| </policyEntry> |
| </policyEntries> |
| </policyMap> |
| </destinationPolicy> |
| |
| </broker> |
| </plain-text-body></structured-macro><h3>Place Non-Persistent Messages Onto The Dead-Letter Queue</h3><p>By default, ActiveMQ will not place undeliverable <em>non-persistent</em> messages on the dead-letter queue. The rationale for this behavior is that if the application doesn't care enough to make the message persistent, then there is little or no value in recording that the message was undeliverable. If you do want to place non-persistent messages on the dead-letter queue, then you should set <strong><code>processNonPersistent="true"</code></strong> on the dead-letter strategy.</p><structured-macro ac:macro-id="0b7a7c68-1ca5-4778-9f9f-a8580aba6632" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body><broker> |
| |
|  <destinationPolicy> |
| <policyMap> |
| <policyEntries> |
| <!-- Set the following policy on all queues using the '>' wildcard --> |
| <policyEntry queue=">"> |
| <!-- |
| Tell the dead letter strategy to also place non-persisted messages |
| onto the dead-letter queue if they can't be delivered. |
| --> |
| <deadLetterStrategy> |
| <sharedDeadLetterStrategy processNonPersistent="true" /> |
| </deadLetterStrategy> |
| </policyEntry> |
| </policyEntries> |
| </policyMap> |
| </destinationPolicy> |
| |
| </broker> |
| </plain-text-body></structured-macro><h3>Setting Expiration on Messages in the DLQ</h3><p>By default, ActiveMQ will <strong><em>never</em></strong> expire messages sent to the DLQ. However, from ActiveMQ 5.12 the <strong><code>deadLetterStrategy</code></strong> supports an <strong><code>expiration</code></strong> attribute whose value is given in milliseconds.</p><structured-macro ac:macro-id="4d8ba42f-e662-4222-97f7-f97a8ca7f4a8" ac:name="warning" ac:schema-version="1"><rich-text-body><p>Be selective in how this is applied. In particular do not apply expiration to your DLQ destinations by setting expiration on a default or inclusive wildcard policy entry.</p><p>If a DLQ entry expires and forwards to the same or another DLQ with expiry, you will introduce a loop that can be problematic if the strategy audit is disabled or it's sliding window is exceeded.</p></rich-text-body></structured-macro><structured-macro ac:macro-id="7dcdda11-0905-4f49-8dcd-62c25e68ee99" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body><broker> |
| |
|  <destinationPolicy> |
| <policyMap> |
| <policyEntries> |
| <policyEntry queue="QueueWhereItIsOkToExpireDLQEntries"> |
| <deadLetterStrategy> |
| <.... expiration="300000"/> |
| </deadLetterStrategy> |
| </policyEntry> |
| </policyEntries> |
| </policyMap> |
| </destinationPolicy> |
| |
| </broker> |
| </plain-text-body></structured-macro><h3>Message audit</h3><p>The dead letter strategy has an message audit that is enabled by default. This prevents duplicate messages from being added to the configured DLQ. From 5.15.0, the limits of the audit can configured via the</p><p><strong>maxProducersToAudit</strong> and <strong>maxAuditDepth</strong> attributes. The audit can be disabled using <strong>enableAudit</strong>="false"</p><p> </p><h3>The Discarding DLQ Plugin</h3><p> </p><structured-macro ac:macro-id="4fbc1d0d-3641-4077-ae32-8ac0950ec85a" ac:name="info" ac:schema-version="1"><rich-text-body><p>From ActiveMQ 5.9 - a destination <strong><code>policyEntry</code></strong> supports a <strong><code>deadLetterStrategy</code></strong> of discarding:</p><structured-macro ac:macro-id="c13e0c78-330b-40b9-b200-4752f496c450" ac:name="code" ac:schema-version="1"><parameter ac:name="language">xml</parameter><plain-text-body><deadLetterStrategy> |
| <discarding/> |
| </deadLetterStrategy></plain-text-body></structured-macro><p>This does the same thing as the plugin but on a per destination basis. The matching based on regular expressions of the plugin is a bit more powerful than destination matching so the plugin may still be useful in some cases.</p></rich-text-body></structured-macro><p> </p><p>A very simple yet very useful plugin to the broker. This plugin allows the configuration of queues and topics, all or matched based on <a shape="rect" href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Pattern.html">Java SE regular expressions</a>, to drop messages that have been sent to the DLQ. This is extremely useful when using <link ac:anchor="ConstantPendingMessageLimitStrategy"><page ri:content-title="Slow Consumer Handling"></page><plain-text-link-body>constant pending message limit strategy</plain-text-link-body></link> or the other eviction rules, but you don't want to incur the overhead of yet another consumer to clear the DLQ.</p><p>Below is an example of a basic configuration to drop everything:</p><structured-macro ac:macro-id="c4908a79-8cb6-43fa-912d-11362ed46321" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body><beans> |
| <broker> |
| <plugins> |
| <discardingDLQBrokerPlugin dropAll="true" dropTemporaryTopics="true" dropTemporaryQueues="true"/> |
| </plugins> |
| </broker> |
| </beans> |
| </plain-text-body></structured-macro><p>Below is a slightly more complex example:</p><structured-macro ac:macro-id="41570c5e-ab56-436f-b2a9-e37fd96c4b76" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body><beans> |
| <broker> |
| <plugins> |
| <discardingDLQBrokerPlugin dropOnly="MY.EXAMPLE.TOPIC.29 MY.EXAMPLE.QUEUE.87" reportInterval="1000"/> |
| </plugins> |
| </broker> |
| </beans> |
| </plain-text-body></structured-macro><ul><li>Notice that destination names are space delimited.</li><li>The <strong><code>reportInterval</code></strong> property is used to denote how frequently do we output how many messages we have dropped - use <strong><code>0</code></strong> to disable.</li></ul><p>Below is an even more complex example:</p><structured-macro ac:macro-id="0283648e-4110-4864-a6ad-ecde61a2bde9" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body><beans> |
| <broker> |
| <plugins> |
| <discardingDLQBrokerPlugin dropOnly="MY.EXAMPLE.TOPIC.[0-9]{3} MY.EXAMPLE.QUEUE.[0-9]{3}" reportInterval="3000"/> |
| </plugins> |
| </broker> |
| </beans> |
| </plain-text-body></structured-macro><ul><li>Notice that the destination names use regular expressions. These match the number <strong><code>000..999</code></strong> at the end of each destination name.</li></ul><p>For more information, see the source code for the <a shape="rect" href="https://svn.apache.org/repos/asf/activemq/trunk/activemq-broker/src/main/java/org/apache/activemq/plugin/DiscardingDLQBrokerPlugin.java">DiscardingDLQBrokerPlugin</a> and the <a shape="rect" href="https://svn.apache.org/repos/asf/activemq/trunk/activemq-broker/src/main/java/org/apache/activemq/plugin/DiscardingDLQBroker.java">DiscardingDLQBroker</a></p><h3>Broker Redelivery (v5.7)</h3><p>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.</p><p><br clear="none"> The feature is enabled via XML configuration as follows:</p><structured-macro ac:macro-id="e54406f7-804d-4f49-b2c6-223c722e968f" ac:name="code" ac:schema-version="1"><parameter ac:name="">xml</parameter><plain-text-body><broker schedulerSupport="true"> |
| |
| <plugins> |
| <redeliveryPlugin fallbackToDeadLetter="true" |
| sendToDlqIfMaxRetriesExceeded="true"> |
| <redeliveryPolicyMap> |
| <redeliveryPolicyMap> |
| <redeliveryPolicyEntries> |
| <!-- a destination specific policy --> |
| <redeliveryPolicy queue="SpecialQueue" |
| maximumRedeliveries="4" |
| redeliveryDelay="10000"/> |
| </redeliveryPolicyEntries> |
|   |
| <defaultEntry> |
| <!-- the fallback policy for all other destinations --> |
|   <redeliveryPolicy maximumRedeliveries="4" |
| initialRedeliveryDelay="5000" |
| redeliveryDelay="10000"/> |
| </defaultEntry> |
| </redeliveryPolicyMap> |
| </redeliveryPolicyMap> |
| </redeliveryPlugin> |
| </plugins> |
| |
| </broker> </plain-text-body></structured-macro><p>The familiar <link><page ri:content-title="Redelivery Policy"></page></link> has been extended to take a matching destination. <strong><code>fallbackToDeadLetter</code></strong>controls the action when there is no matching redeliver policy for a destination. Defaults to <strong><code>true</code></strong> so regular DLQ processing ensues. <strong><code>sendToDlqIfMaxRetriesExceeded</code></strong> controls the action when the retry limit is exceeded. Defaults to true so regular DLQ processing ensues. When <strong><code>false</code></strong>, the message is dropped.</p><structured-macro ac:macro-id="8f9318e9-8196-4788-a17e-f66a932c612f" ac:name="info" ac:schema-version="1"><rich-text-body>ActiveMQ's <strong><code>schedulerSupport</code></strong> must be enabled for this feature to work.</rich-text-body></structured-macro></div> |
| |
