On Fri, May 23, 2014 at 6:52 PM, kraythe . <[email protected]> wrote: > 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. >
Yeah and you can do that by using a 2nd jms component that has not been configured as transacted. And use the 2nd jms component to write to the details queue. > *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 <[email protected]> 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 . <[email protected]> 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 <[email protected]> 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 . <[email protected] >> <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: [email protected] <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: [email protected] >> Twitter: davsclaus >> Blog: http://davsclaus.com >> Author of Camel in Action: http://www.manning.com/ibsen >> hawtio: http://hawt.io/ >> fabric8: http://fabric8.io/ >> -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
