axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera (JIRA)" <j...@apache.org>
Subject [jira] Closed: (AXIS2-4213) Dead Letter Queue Based Recovery
Date Sun, 18 Jan 2009 15:56:59 GMT

     [ https://issues.apache.org/jira/browse/AXIS2-4213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Asankha C. Perera closed AXIS2-4213.
------------------------------------

    Resolution: Won't Fix
      Assignee: Asankha C. Perera

Hi Karthick

The JMS transport no longer lives in the Axis2 (Kernel) codebase, but in the transports module
of WS-Commons. Please check the latest code, and consider your changes accordingly

thanks
asankha

> 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
>            Assignee: Asankha C. Perera
>             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.


Mime
View raw message