OK, I had missed that warning :) I'm using WebSphere MQ 6.0.2.5, Camel 1.6.0 and Spring 2.5.6. I'm not running XA or inside a J2EE Container, but the cacheLevelName=CACHE_NONE seems to have solved by problem for WebSphere MQ.
/Henric On Mon, Mar 9, 2009 at 9:11 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Mon, Mar 9, 2009 at 9:02 AM, Henric Hedin <hhe...@gmail.com> wrote: > > 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. > Great > > We have a warning about it here: > http://camel.apache.org/jms.html > > Maybe we should add WMQ to the list as well that could have problems as > well? > > BTW Which versions of Camel, Spring and WMQ are you using? > > > > > > Regards, > > Henric > > > > On Mon, Mar 9, 2009 at 8:53 AM, Henric Hedin <hhe...@gmail.com> 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 <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/ > >>> > >> > >> > > > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ >
