camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Catch and handle errors when using the TransactionErrorHandler
Date Mon, 09 Mar 2009 08:31:35 GMT
On Mon, Mar 9, 2009 at 9:28 AM, Henric Hedin <hhedin@gmail.com> 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 <claus.ibsen@gmail.com> wrote:
>
>> On Mon, Mar 9, 2009 at 9:02 AM, Henric Hedin <hhedin@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 <hhedin@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.ibsen@gmail.com>
>> wrote:
>> >>
>> >>> On Fri, Mar 6, 2009 at 1:51 PM, Henric Hedin <hhedin@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/
>>
>



-- 
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/

Mime
View raw message