You cannot provide a reason why a rollback happens in the TX API.
There is no rollback(String message) api for that.
You need to record this somewhere else if you want to use that.
Or do your own kind of TX rollback.
On Thu, May 22, 2014 at 11:00 PM, kraythe . <kray...@gmail.com> wrote:
> Greetings, I have many routes that read from AMQ queues and write to other
> AMQ queues. For error handling I have been using the following paradigm:
>
> from("activemq:queue:inbox")
>
> .onException(Exception.class).useOriginalMessage().handled(handled).maximumRedeliveries(0)
> .setHeader(Exchange.FAILURE_ROUTE_ID, property(Exchange.FAILURE_ROUTE_ID))
> .setHeader(Exchange.EXCEPTION_CAUGHT, simple("${exception.stacktrace}"))
> .to(ExchangePattern.InOnly, "activemq:queue:dead").end();
> .process(new PreProcessor())
> .to("activemq:queue:outbox")
> .process(new PostProcessor());
>
> The goal being that if there was any kind of exception, that information
> would be noted in the headers on the message before it was sent off to the
> DLQ. The problem is this runs into roadblocks when transacted() is added to
> the route.
>
> With the code above when the route is transacted and a message fails in
> post processing I want the message pulled off the outbox, record
> information indicating what the exception was, and have the message sent to
> the DLQ. Unfortunately I seem to be in a quandary of how to do this.
>
> The code above simply wont work because the message being sent to the dead
> letter queue gets rolled back along with the outbox if I mark the exchange
> with rollback() in the exception handler. If I don't mark the message with
> rollback() in the handler then the outbox doesn't get rolled back if the
> post processor exceptions but the dead letter channel will contain the
> correct information. On the other hand if I just let activemq handle the
> transaction, it will retry and then eventually send the message to the DLQ
> but the message in the DLQ will contain no information about why it failed.
>
> So I want my cake and eat it too. I want to be able to record WHY an
> exchange failed but still be able to rollback the outbox at the same time.
> I have been plugging away at this a ton and I am out of ideas. What would
> not be acceptable would be to require the user to troll through log files
> trying to find a reason why an exchange failed. This would be an
> operational nightmare. So the message and the reason for the rollback need
> to be somewhere accessible and they need to be together.
>
> I would appreciate any suggestions on how I could make this happen.
>
> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
