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.ib...@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 . <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/ >
