Transaction policy not correctly rolling back on exception.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Transaction policy not correctly rolling back on exception.

EJLeVin1
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
Reply | Threaded
Open this post in threaded view
|

Re: Transaction policy not correctly rolling back on exception.

EJLeVin1
Here is the test file...

ActiveMQ-Camel-Test.zzz
Reply | Threaded
Open this post in threaded view
|

RE: Transaction policy not correctly rolling back on exception.

Claus Ibsen
In reply to this post by EJLeVin1
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:[hidden email]]
Sent: 28. juni 2008 20:57
To: [hidden email]
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.

Reply | Threaded
Open this post in threaded view
|

RE: Transaction policy not correctly rolling back on exception.

Claus Ibsen
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:[hidden email]]
Sent: 29. juni 2008 15:21
To: [hidden email]
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:[hidden email]]
Sent: 28. juni 2008 20:57
To: [hidden email]
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.

Reply | Threaded
Open this post in threaded view
|

RE: Transaction policy not correctly rolling back on exception.

Claus Ibsen
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:[hidden email]]
Sent: 29. juni 2008 18:34
To: [hidden email]
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:[hidden email]]
Sent: 29. juni 2008 15:21
To: [hidden email]
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:[hidden email]]
Sent: 28. juni 2008 20:57
To: [hidden email]
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.

Reply | Threaded
Open this post in threaded view
|

RE: Transaction policy not correctly rolling back on exception.

EJLeVin1
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:ci@silverbullet.dk]
Sent: 29. juni 2008 18:34
To: camel-user@activemq.apache.org
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:ci@silverbullet.dk]
Sent: 29. juni 2008 15:21
To: camel-user@activemq.apache.org
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:ejlevin1@hotmail.com]
Sent: 28. juni 2008 20:57
To: camel-user@activemq.apache.org
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.
Reply | Threaded
Open this post in threaded view
|

RE: Transaction policy not correctly rolling back on exception.

Claus Ibsen
Hi Eric

Sure drop me an email at: [hidden email] and I will be able to zip the stuff to you tonight or tomorrow morning - pending on how much wife time is needed ;)

Yes I do think Camel have a little confusion on exchange elements:
- faults
- exceptions

There is a JIRA ticket, I think, that should address this somehow (maybe removing the fault stuff - Can't remember).

Anyway Camel will by default use a DeadLetterChannel that will do the all might catch of exceptions between exchanges (from ... to) it will do up till 6 retries and then store it in a LOG. These default settings will change in the future as it's not production friendly.

So when you do from("direct:xxx").to("bean:yyy") then the DeadLetterChannel kicks in and does the try ... catch and you will only see that it has failed if you access the isFailed() property on the returned exchange.

I think you can change the DeadLetterChannel to noErrorHandler and then you will get the exceptions thrown in your "face". I am not 100% sure.

Try something like this:
errorHandler(noErrorHandler());
from("direct:xxx)...

Please let me known how this works for you. I would like to use it for a FAQ entry or some other wiki documentation explaining this issue in more details as we want this to be more precise how Camel route stuff and what it does under the covers - we don't want any unpleasant surprises with the framework.

About CAMEL-634. I would love it to get into 1.4 and I was hoping some of the other committers would agree and react to my proposals on the dev forum.
This "bug" hits both you and another end-user and clearly the transactional client in Camel 1.3 does not work correctly.




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:[hidden email]]
Sent: 30. juni 2008 17:06
To: [hidden email]
Subject: RE: Transaction policy not correctly rolling back on exception.


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:[hidden email]]
> Sent: 29. juni 2008 18:34
> To: [hidden email]
> 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:[hidden email]]
> Sent: 29. juni 2008 15:21
> To: [hidden email]
> 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:[hidden email]]
> Sent: 28. juni 2008 20:57
> To: [hidden email]
> 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.