Hi See http://camel.apache.org/message-history
You can get access to the message history yourself and do your own json output and logging or whatever you want. You should then turn off the default message history logging on the error handler. On Wed, May 28, 2014 at 6:17 PM, kraythe . <kray...@gmail.com> wrote: > So I opted for a multi phasic approach. We are changing AMQ to not do any > redeliveries but to handle DLQ for us. > > http://activemq.apache.org/message-redelivery-and-dlq-handling.html > > So we are asking activemq to not do any redelivery of the the messages and > instead handling any redelivery on a route by route basis: > > from(uri).onException(IOException.class).maximumRedeliveries(2).soOn() > > What this means is that the message history will not be in the message on > the DLQ but rather only in the log file. That makes it a bit more > problematic to read but we will set up a nagios monitor on that log to look > for those errors. > > The only problem I have now, then, is that the message history format is > not entirely useful. It truncates route ids in the message history making > things harder to trace. It would be nice if it would print out the message > history as JSON instead. I might see if there is a way I can extract that > message history and send it to the log directly myself with an error > handler or exception handler. I am, however, trying to shy away from > boilerplate exception handling in routes. What would be the ability to > control the message history output. I would rather have an exhaustive > history as a JSON compliant object like: > > "History": [ > { > "RouteId" : "com.ea.someproject.somemodule.TestRoute", > "ProcessorId" : "TestRoute", > "Processor" : "activemq://queue:inbox", > "Elapsed" : 3 > } > { > "RouteId" : "com.ea.someproject.somemodule.TestRoute", > "ProcessorId" : "transacted13", > "Processor" : > "transacted[ref:java:app/activemq/txnManager/policy/REQUIRES_NEW", > "Elapsed" : 2 > } > ], > > And so on. We can plug in an exchange formatter but not the history > formatter. I am wondering if there is a way I can suppress logging of > message history without suppressing the collection of it and then log > myself with the exchange formatter. Im sure there is some way to do it. > > *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 Sat, May 24, 2014 at 1:16 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > >> On Fri, May 23, 2014 at 6:52 PM, kraythe . <kray...@gmail.com> 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 <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/ >> >> >> >> >> >> -- >> 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/ >> -- 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/
