| <?xml version="1.0"?> |
| <!-- |
| |
| Licensed to the Apache Software Foundation (ASF) under one |
| or more contributor license agreements. See the NOTICE file |
| distributed with this work for additional information |
| regarding copyright ownership. The ASF licenses this file |
| to you under the Apache License, Version 2.0 (the |
| "License"); you may not use this file except in compliance |
| with the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, |
| software distributed under the License is distributed on an |
| "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| KIND, either express or implied. See the License for the |
| specific language governing permissions and limitations |
| under the License. |
| |
| --> |
| |
| <section xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="Java-Broker-Runtime-Handling-Undeliverable-Messages"> |
| <title>Handing Undeliverable Messages</title> |
| |
| <section role="h2" xml:id="Java-Broker-Runtime-Handling-Undeliverable-Messages-Introduction"> |
| <title>Introduction</title> |
| <para> Messages that cannot be delivered successfully to a consumer (for instance, because the |
| client is using a transacted session and rolls-back the transaction) can be made available on |
| the queue again and then subsequently be redelivered, depending on the precise session |
| acknowledgement mode and messaging model used by the application. This is normally desirable |
| behaviour that contributes to the ability of a system to withstand unexpected errors. However, it |
| leaves open the possibility for a message to be repeatedly redelivered (potentially indefinitely), |
| consuming system resources and preventing the delivery of other messages. Such undeliverable |
| messages are sometimes known as poison messages.</para> |
| <para>For an example, consider a stock ticker application that has been designed to consume prices |
| contained within JMS TextMessages. What if inadvertently a BytesMessage is placed onto the queue? |
| As the ticker application does not expect the BytesMessage, its processing might fail and cause it |
| to roll-back the transaction, however the default behavior of the Broker would mean that the |
| BytesMessage would be delivered over and over again, preventing the delivery of other legitimate |
| messages, until an operator intervenes and removes the erroneous message from the queue. </para> |
| <para>Qpid has maximum delivery count and dead-letter queue (DLQ) features which can be used in |
| concert to construct a system that automatically handles such a condition. These features are |
| described in the following sections.</para> |
| </section> |
| |
| <section role="h2" xml:id="Java-Broker-Runtime-Handling-Undeliverable-Messages-Maximum-Delivery-Count"> |
| <title>Maximum Delivery Count</title> |
| <para> Maximum delivery count is an attribute of a queue. If a consumer application is unable to |
| process a message more than the specified number of times, then the Broker will either route the |
| message via the queue's <emphasis>alternate binding</emphasis> (if one has been defined), or will |
| discard the message.</para> |
| <para>When using AMQP 1.0 the current delivery count of a message is available to the consuming |
| application via the<literal>message-count</literal> message header (exposed via the |
| <literal>JMSXDeliveryCount</literal> JMS message property when using JMS). When using the |
| AMQP 0-8..0-10 protocols this information is not available.</para> |
| <note> |
| <para> When using AMQP 0-8..0-10, in order for a maximum delivery count to be enforced, the consuming application |
| <emphasis>must</emphasis> call <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="${oracleJeeDocUrl}javax/jms/Session.html#rollback()">Session#rollback()</link> (or <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="${oracleJeeDocUrl}javax/jms/Session.html#recover()">Session#recover()</link> if the session is not transacted). It is during the Broker's |
| processing of Session#rollback() (or Session#recover()) that if a message has been seen |
| at least the maximum number of times then it will move the message to the DLQ or discard the |
| message. If the consuming application fails in another manner, for instance, closes the connection, the |
| message will not be re-routed and consumer application will see the same poison message again |
| once it reconnects.</para> |
| <para> If the consuming application is using Qpid JMS Client 0-x and using AMQP 0-8, 0-9, or 0-9-1 |
| protocols, it is necessary to set the client system property <varname>qpid.reject.behaviour</varname> or |
| connection or binding URL option <varname>rejectbehaviour</varname> to the value <literal>server</literal>.</para> |
| </note> |
| </section> |
| <section role="h2" xml:id="Java-Broker-Runtime-Handling-Undeliverable-Messages-Dead-Letter-Queues"> |
| <title>Alternate Binding</title> |
| <para>Once the maximum delivery count is exceeded, if the queue has an <literal>alternateBinding</literal> |
| specified, the Broker automatically routes the message via the alternate binding. The alternate binding |
| would normally specify a queue designated for that purpose of receiving the undeliverable messages. |
| By convention such queues are known as dead-letter queues or simply DLQs.</para> |
| <caution> |
| <title>Avoid excessive queue depth</title> |
| <para>Applications making use of DLQs <emphasis>should</emphasis> make provision for the frequent |
| examination of messages arriving on DLQs so that both corrective actions can be taken to resolve |
| the underlying cause and organise for their timely removal from the DLQ. Messages on DLQs |
| consume system resources in the same manner as messages on normal queues so excessive queue |
| depths should not be permitted to develop.</para> |
| </caution> |
| </section> |
| </section> |