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/
