[ 
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.

Reply via email to