Hi
Maybe send the error details to another queue, and have a way to
correlate that message to the other message that goes into the DLQ.
Though its a bit tricky as AMQ handles the DLQ, and Camel only would
know if its the last attempt, if you use the JMSRedeliveryCounter to
know it was the last redelivery attempt, so the message is going to
the DLQ when its rolled back this last time. And therefore I should
send a message about this exception to another queue (outside this
TX).
You can then maybe have another Camel route that reads from the DLQ
and then enrich that message with the other message from the queue
which has the exception details, and move to a final DQL, so you have
all details in the same JMS message.
On Fri, May 23, 2014 at 4:10 PM, kraythe . <kray...@gmail.com> wrote:
> Yeah, I know the rollback doesn't work that way. That wasn't what I was
> driving at. I am just trying to deal with a business problem of informing
> the investigator why an exchange failed though means other than spelunking
> in a verbose log file for clues. Sometimes one investigating a problem may
> not have access even to the logs. For example if a business issue such as a
> studio's game site went down causing the exchanges to fail. In this
> circumstance we would rather push the exchange to a dead letter queue and
> then later be able to determine why the problem happened and relish those
> exchanges. Again finding the "why" in a log file isn't going to work out.
>
> -- Robert
>
> On Friday, May 23, 2014, Claus Ibsen <claus.ib...@gmail.com> wrote:
>
>> 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<javascript:;>>
>> 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 <javascript:;>
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>> hawtio: http://hawt.io/
>> fabric8: http://fabric8.io/
>>
>
>
> --
> *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/
