Thank you Claus, the trick to not use the Spring Policy works good enough for me!
Though, I still get a strange behavior. I'm using WebSphere MQ as the incoming JMS-provider and for the input queue I have set "Backout requeue queue" and the Backout threshold to 1. When sending a message to the input queue which causes a parse exception, the message is removed from the input queue and I could see on the queue depth is increased for the backout-queue; but's its never committed (i.e. I can't see the message when browsing the queue). When stopping my "Route builder"-flow/JVM the message is put back on the input queue and the backout count equals 2. Then, when I restart the flow/JVM again, the message is finally put correctly to the Backout queue (and removed from the input-queue), without any exceptions occurring in my Camel Route. Could this have anything to do with the JMS (Spring) options or could it be related to pooling in my (WMQ) connection factory? I will probably make some further investigations and probably try AMQ instead to see if I get the same behavior. Thanks, Henric On Fri, Mar 6, 2009 at 5:10 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Fri, Mar 6, 2009 at 1:51 PM, Henric Hedin <hhe...@gmail.com> wrote: > > Hi, > > > > Is it possible to in some way to use the TransactionErrorHandler and at > the > > same time catch and handle exceptions? > > > > I have read the documentation under > > http://camel.apache.org/error-handling-in-camel.html that for > transactional > > exchanges the Error Handler does not kick, so the following code in my > Route > > configure will not work: > > > > > > errorHandler(bean(TransactionErrorHandlerBuilder.class, > > "transactionErrorHandler")); > > > > onException(SAXParseException.class). > > handled(true). > > policy(notsupported). > > maximumRedeliveries(1). > > transform().constant("Sorry, parse exception..."). > > to("jms:queue:validationFailed.SAXParseException"); > > > > > > from("jms:queue:input-queue?transacted=true"). > > unmarshal(jaxbDataFormat). > > to("jms:queue:output-queue"). > > > > > > What I'm trying to accomplish is if a parsing exception occurs, I would > like > > my incoming message to be rolled back and put on the jms deadletter queue > > (configured for the queue on the JMS provider, when the JMSXDeliveryCount > > has reached it's threshold). But I would also be able to send an > information > > jms-message to the same jms-provider with information about why the > message > > has been backed out (of course outside the "incoming transaction"). > > > > Maybe a strange solution, but is it possible to handle in Camel? :) > > /Henric > > > No the DeadLetterChannel is disabled for transacted exchanges. There > is a trick though, if you dont add the Spring Policy then it will > default to REQUIRED and still use DLC. > > We are considering how we can provide options for end users in the > future so you can use DLC for somerthing combined with transacted > exchanges. > > The problem with transacted exchanges is that they are redelivered in > a totally new thread so Camel has no wait of correlating a previous > attempt, we can only rely on the few JMS options you get such as the > JMSX counter. But we dont know when we have reached exhausted, to send > the extra JMS message > > But any feedback and ideas is welcome what we can do in the future to > bring more value to error handling with TX > > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ >
