Dead Letter Queue Based Recovery
--------------------------------
Key: AXIS2-4213
URL: https://issues.apache.org/jira/browse/AXIS2-4213
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Components: kernel
Affects Versions: 1.3
Reporter: Karthick Sankarachary
Fix For: 1.3
Attachments: dead-letter-queue.patch
Currently, when the server receives a JMS message that cannot be delivered to a
service, it simply drops it. By the same token, when the server fails to
deliver a JMS message to an external service, it is lost forever. This leaves
users guessing as to what was in that message and why the delivery failed.
Furthermore, there is no way for them to manually retry the delivery, even if
they have the know-how to correct the problem.
Typically, message brokers employ a dead letter queue, in which to store
undeliverable messages. This allows users to not only track such messages, but
also retry delivery of some of them. A few brokers even go to the extent of
customizing the dead letter queue based on who is sending or receiving the
message. This way, users can quickly identify the messages that they are
specifically interested in.
Let us try to apply these concepts to Axis2. Strictly speaking, the JMS
transport of Axis2 is not a JMS broker, but it does create JMS consumers and
producers, which have to handle delivery failures, as you might imagine. In the
event of such failures, the message should be sent to a default dead letter
queue, the scope of which is system-wide. If so desired, the user may override
the default location of the dead letter queue by specifying a message context
property or client option. For more details, please refer to the patch that is
attached here.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
