camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henric Hedin <hhe...@gmail.com>
Subject Re: Catch and handle errors when using the TransactionErrorHandler
Date Mon, 09 Mar 2009 07:53:42 GMT
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/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message