camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] Commented: (CAMEL-960) DeadLetterChannel - option to mark the exchange as failure handled and that its OK
Date Fri, 10 Oct 2008 04:57:52 GMT


Claus Ibsen commented on CAMEL-960:


No/yes its possible today, but we have a catch-22 situation where you have a route path using
DLC and want it eg. to move a failued exchanges to a JMS queue.

from("jms:queue.a").to("bean:doSomething", "jms:queue.b");

If you use transacted JMS then you can not handle the exchange currently in Camel. If bean:doSomething
throws an Exception it is caught by the DLC that will try to failure handle it and move it
to *jms:failed*. This is possible, but then it *restoresTheOriginalException* and then transaction
handler in Camel will rethrow this and then the TX is marked for rollback. And this you did
not handle it, you could not mobe it to jms:failed and then its OK.

So what we want is to alter the restoreExceptionOnExchange  method in DeadLetterChannel, to
NOT set the exception. But of course it should be configurable when to do this

> DeadLetterChannel - option to mark the exchange as failure handled and that its OK
> ----------------------------------------------------------------------------------
>                 Key: CAMEL-960
>                 URL:
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Hadrian Zbarcea
>             Fix For: 1.5.0, 2.0.0
> Currently the DeadLetterChannel sets the orignal caused exception on the exchange *after*
it has been failure handled. We should support somekind of option to enable/disable this feature.
We could support:
> - option on the endpoint to set this for all exchanges
> - support a special header key that end-users can insert per exchange to be more dynamic
> - maybe methods on Exchange to set this more easily
> - maybe some refinements in isFailureHandled() to cater for this
> And we should consider use a better keyname in the DLC where it stores the original exception.

> See nabble:
> We might need to push this for Camel 2.0 but I think it is a feature that end-users would
need sooner.
> Any thoughts, please write here?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message