Hi again, I solved my problem by setting cacheLevelName=CACHE_NONE on the MQ JMS Endpoint. Now the message is backed out out directly, without the route/JVM restart.
Regards, Henric On Mon, Mar 9, 2009 at 8:53 AM, Henric Hedin <[email protected]> wrote: > 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 <[email protected]> wrote: > >> On Fri, Mar 6, 2009 at 1:51 PM, Henric Hedin <[email protected]> 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/ >> > >
