Claus,
Thanks for looking into this on a Sunday :) Quite the dedication --
much appreciated. A couple things, in looking at CAMEL-634, I noticed you
made a comment about this not getting into the 1.4 release because it is
going to be cut shortly; however, above you said there is a possibility of
getting this into the 1.4 release... After looking at it as you have, is
this something that could get included in the release do you think, or are
you still thinking it is a 1.5 thing?
Also, one thing that I really don't understand is how the exception handling
happens on exchanges. I am guessing the original contributor could have
possibly been confused as I was, because he is simply doing the try...catch,
instead of looking at the isFailed(). Do you think it would be valuable to
have something in the documentation about the way this works? I'll give you
an example of where confusion comes in:
I had an app that was trying to send a message through direct:someEndpoint
and trying to catch any exception that would get thrown (if any). My route
would have looked something like this:
from("direct:someEndpoint").to("bean:myBean?method=someMethod") but, even
when myBean threw an exception, the original producer template would never
throw the exception back to my calling code; however, if the endpoint was
directly specified as bean:myBean?method=someMethod the exception gets
thrown back as expected... It may just be my lack of understanding, but I
wanted to see if you think this would be something worth documenting. If so
I could raise a JIRA feature request for it. Let me know what you think...
One other thing -- is there any way you could send me the changes you made
to the test app so I can see how you got it to work?
Thanks so much!
-Eric
Claus Ibsen wrote:
>
> Hi
>
> There is light at the end of the tunnel. With the patch from CAMEL-634 and
> a slightly modified version of your test application - using 1.4-SNAPSHOT
> it passes on my laptop now.
>
> The exchange is under transaction and is retried the 5 times until your
> processor success.
>
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: Claus Ibsen [mailto:[EMAIL PROTECTED]
> Sent: 29. juni 2008 18:34
> To: [email protected]
> Subject: RE: Transaction policy not correctly rolling back on exception.
>
> Hi
>
> See also CAMEL-634 that has a patch for this issue.
>
> Basically the current TransactionInterceptor doesn't work correctly as it
> doens't consider the fact that the processing of the exchange doesn't
> throw the exception but stores it on the exchange.
>
> So it need to check if there is an exception set and then do "rollback".
>
> Maybe this can be target for 1.4 if some of the other comitters agree on
> this. Would be great to include it. But no promises.
>
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: Claus Ibsen [mailto:[EMAIL PROTECTED]
> Sent: 29. juni 2008 15:21
> To: [email protected]
> Subject: RE: Transaction policy not correctly rolling back on exception.
>
> Hi Eric
>
> You are touching some grounds there that many hasn't done so often ;)
>
> The Camel transactional stuff is documented here:
> http://activemq.apache.org/camel/transactional-client.html
>
> There is a JIRA ticket to improve this documentation. We target this for
> Camel 1.5, but since its wiki documentation the docs is online.
>
> Back to your problem: I had a peek and I am also a bit puzzled why Camel's
> TransactionInterceptor isn't testing for isFailed() and doesn't set the
> rollbackonly flag on the spring tx manager.
>
> http://static.springframework.org/spring/docs/2.5.x/reference/transaction.html
>
> You could try changing the TransactionInterceptor code in Camel to test
> for the isfailed, eg:
>
> This is my code I am trying with right now:
>
> public void process(final Exchange exchange) {
> transactionTemplate.execute(new TransactionCallbackWithoutResult()
> {
> protected void doInTransactionWithoutResult(TransactionStatus
> status) {
> try {
> // begin transaction (actually its done by Spring,
> wrapping this template)
> LOG.debug("Transaction begin");
>
> processNext(exchange);
>
> // if the exchange failed then mark it as rollback
> if (exchange.isFailed()) {
> LOG.debug("Transaction rollback");
> status.setRollbackOnly();
> return;
> }
>
> // exchange success so we mark it for commit
> LOG.debug("Transaction commit");
>
> } catch (Throwable t) {
> LOG.debug("Transaction rollback");
> status.setRollbackOnly();
> // TODO: Should we rethrow the exception now that we
> marked it for rollback?
> throw new RuntimeCamelException(t);
> }
> }
> });
> }
>
>
> I guess it would be great to get the attention of the original contributor
> on this transaction support in Camel = James.
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: EJLeVin1 [mailto:[EMAIL PROTECTED]
> Sent: 28. juni 2008 20:57
> To: [email protected]
> Subject: Transaction policy not correctly rolling back on exception.
>
>
> Hi Everyone,
> So I have been working on this issue for almost the past 15 hours
> straight and can't seem to find the solution. I created a simply maven
> project to display what I am seeing. I have thus far been unable to get a
> JMS transaction manager (defined as a policy in my camel route) to force
> redelivery from AMQ on an exception occurring. I looked through the user
> forum and went through a bunch of the examples, but unfortunately, it was
> to
> no avail. All you need to do to run the test is extract the zip (renamed
> to
> .zzz for the post) and execute 'mvn test' and you should see the results I
> am seeing... :)
>
> Here is a quick breakdown:
>
> from("activemq:queue:TestQueue")
> .errorHandler(noErrorHandler()) //We don't want a local
> re-delivery
> policy
> .policy(required) //Set the transactional client before the
> error
> producing processor
> .process(errorProducingProcessor) //This processor will throw
> exceptions on messages
> .to("mock:foo");
>
> when I do not throw exceptions, the route works perfectly in my test case;
> however, when I have the errorProducingProcessor in my route, the
> transaction manager still seems to commit the message. I have noticed
> something strange in the way the exceptions are occurring, maybe it is my
> lack of understanding for the route exception handling, but when I throw
> an
> exception from my processor, it doesn't seem to be thrown down to the
> transaction manager as I would expect. I debugged the transaction
> processor
> code and the exchange.isFailed() is returning true when it reaches the
> TransactionInterceptor, but it doesn't actually throw the exception as the
> try..catch within the class is expecting (or so it seems to me). Any idea
> as to why the exceptions wouldn't be getting thrown as one would expect?
>
> Any help in this matter is greatly appreciated. Thanks so much!
>
> -Eric
> --
> View this message in context:
> http://www.nabble.com/Transaction-policy-not-correctly-rolling-back-on-exception.-tp18173845s22882p18173845.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
--
View this message in context:
http://www.nabble.com/Transaction-policy-not-correctly-rolling-back-on-exception.-tp18173845s22882p18197692.html
Sent from the Camel - Users mailing list archive at Nabble.com.
