camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "kraythe ." <kray...@gmail.com>
Subject Re: How to Implment Informative Transactional Error Handling?
Date Fri, 23 May 2014 16:52:21 GMT
Its an idea but I think I would run into the same problem. The rollback of
the failed transation would roll back the message to the details queue as
well. The problem is I need the write to the details or error queue to be
outside the transaction but the inbox and outbox should be in the
transaction.

*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>*


On Fri, May 23, 2014 at 9:14 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> 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 . <kraythe@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.ibsen@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 . <kraythe@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: cibsen@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: cibsen@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/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message