intercept exchange after transaction retry failure

[Gabriel Chan <ga...@middleware360.com>]

Hi,
I'm somewhat new to camel. I have my camel context using the spring
TransactionErrorHandlerBuilder to handle transactions. This seems to be
working ok and I'm seeing transactions retry and fail out as expected.
What I would like to do now is intercept the exchange after all the retries
fail and before it goes to the dead letter queue but I can't seem to find a
way to do that. It seems the only time I can process the exchange is prior
to each retry. Is this correct?

Ultimately, what I'm trying to do is to add additional information to the
exchange, such as the route it was on when it failed or serializing the
exchange and putting it in the message body.for later processing. Is this
the correct approach or is there a better way?

thanks,
gabe

Re: intercept exchange after transaction retry failure

[Claus Ibsen <cl...@gmail.com>]

Hi

The TX error handler is working together with a TX manager. And thus
you cannot enrich the exchange before it rollback etc.
The idea is that the TX manager issues a rollback, and the external
system (which delivered the message in the first place) can act
accordingly. Often this external system keeps track of redelivery
attempts and have its way of moving messages to a dead letter queue if
its a poison message (eg would redeliver forever).


If you use the Camel DeadLetterChannel error handler instead, then its
not using a TX manager per see. And you can enrich the message, and
move it to your custom dead letter queue.




On Fri, Aug 17, 2012 at 9:43 AM, Gabriel Chan
<ga...@middleware360.com> wrote:
> Hi,
> I'm somewhat new to camel. I have my camel context using the spring
> TransactionErrorHandlerBuilder to handle transactions. This seems to be
> working ok and I'm seeing transactions retry and fail out as expected.
> What I would like to do now is intercept the exchange after all the retries
> fail and before it goes to the dead letter queue but I can't seem to find a
> way to do that. It seems the only time I can process the exchange is prior
> to each retry. Is this correct?
>
> Ultimately, what I'm trying to do is to add additional information to the
> exchange, such as the route it was on when it failed or serializing the
> exchange and putting it in the message body.for later processing. Is this
> the correct approach or is there a better way?
>
> thanks,
> gabe



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen