On Mon, Mar 9, 2009 at 9:28 AM, Henric Hedin <[email protected]> wrote: > 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. Thanks. I have added you case to the warning.
> > /Henric > > On Mon, Mar 9, 2009 at 9:11 AM, Claus Ibsen <[email protected]> wrote: > >> On Mon, Mar 9, 2009 at 9:02 AM, Henric Hedin <[email protected]> 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 <[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/ >> >>> >> >> >> >> >> > >> >> >> >> -- >> 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/
