You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@camel.apache.org by "Purcell, Chris (London)" <cp...@maninvestments.com> on 2009/10/02 18:47:39 UTC

Combining custom error handling with a transactional rollback

Hi all,

I'm writing a Camel pipeline and I'd like to do both of the following
when an exception is thrown:

(1) Roll back the current transaction, if one has been started (it
starts mid-pipeline)
(2) Do some further handling of the current message, ultimately sending
a warning email about the problem

I can find a way to do either of the above, but I cannot seem to do
both. Adding a custom error handler appears to silently disable the
rollback.

I cannot process the error in the object initially sending the message
to the queue, as I'm actually splitting the message and handling the
components separately, one transaction each, and need to know exactly
which one(s) failed -- and let the remainder succeed.

Cheers,
Chris

**********************************************************************
Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees only. It contains information which may be confidential and privileged. If you are not the intended recipient, please notify the sender immediately, destroy this email and any attachments and do not otherwise disclose or use them. Email transmission is not a secure method of communication and Man Investments cannot accept responsibility for the completeness or accuracy of this email or any attachments. Whilst Man Investments makes every effort to keep its network free from viruses, it does not accept responsibility for any computer virus which might be transferred by way of this email or any attachments. This email does not constitute a request, offer, recommendation or solicitation of any kind to buy, subscribe, sell or redeem any investment instruments or to perform other such transactions of any kind. Man Investments reserves the right to monitor, record and retain all electronic communications through its network to ensure the integrity of its systems, for record keeping and regulatory purposes.
Visit us at: www.maninvestments.com
TG0908
**********************************************************************

RE: Combining custom error handling with a transactional rollback

Posted by "Purcell, Chris (London)" <cp...@maninvestments.com>.

Claus Ibsen wrote:
> > I've made a set of test routes illustrating what I'm
> > trying to achieve. I just don't know how you want them
> > provided. Should I email them to this group (unfriendly to 
> > those with slow connections), or raise a bug report in JIRA 
> > so I can attach them?
> 
> Yeah using the JIRA is very good. Then we wont forget. And 
> you can attach files etc.

I've now raised this issue at:

    http://issues.apache.org/activemq/browse/CAMEL-2059 

Please let me know if this is unclear or incomplete.

I've also managed to come up with a route that solves my problems, using
doTry/doCatch. I had to first figure out that starting a transaction
mid-route was causing me problems. This is all included in the JIRA
item.

Cheers,
Chris

**********************************************************************
 Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees only.  It contains information which may be confidential and privileged.  If you are not the intended recipient, please notify the sender immediately, destroy this email and any attachments and do not otherwise disclose or use them. Email transmission is not a secure method of communication and Man Investments cannot accept responsibility for the completeness or accuracy of this email or any attachments. Whilst Man Investments makes every effort to keep its network free from viruses, it does not accept responsibility for any computer virus which might be transferred by way of this email or any attachments. This email does not constitute a request, offer, recommendation or solicitation of any kind to buy, subscribe, sell or redeem any investment instruments or to perform other such transactions of any kind. Man Investments reserves the right to monitor, record and retain all electronic communications through its network to ensure the integrity of its systems, for record keeping and regulatory purposes. 
Visit us at: www.maninvestments.com 
TG0908
**********************************************************************

Re: Combining custom error handling with a transactional rollback

Posted by Claus Ibsen <cl...@gmail.com>.

On Mon, Oct 5, 2009 at 10:53 AM, Purcell, Chris (London)
<cp...@maninvestments.com> wrote:
> On Monday, 5 October, 2009 at 05:35, Claus Ibsen wrote:
>> If you think that error handling is something that is easy
>> then you cant be more wrong. Its hard.
>
> Sorry, wasn't intending to cause offense.

None taken. Error handling is just hard.

>
>> If you are using transacted routes then leave it to the
>> underlying transaction manager to handle the error.
>
> So, as I understand it, that means if I get an error in a transacted
> route, my only option is to rollback and take no other action?
>

That is the best option :) But you can do some mix and match but then
be a bit more careful.
The error handlers in Camel was designed to have this distinct
separation from the start.
The mix and match is just recently added in 2.0.

>> If you mix and match with Camels onException and default
>> error handlers etc. then you have to be much more careful.
>
> I'm happy to be more careful, I just can't find *any* way to mix and
> match.
>
>> It would of course be much easier to somehow help you if you
>> share your routes and more information what you want to
>> archive and where you think there is a problem.
>
> As I said in my previous message, I've made a set of test routes
> illustrating what I'm trying to achieve. I just don't know how you want
> them provided. Should I email them to this group (unfriendly to those
> with slow connections), or raise a bug report in JIRA so I can attach
> them?
>

Yeah using the JIRA is very good. Then we wont forget. And you can
attach files etc.


> Chris
>
> **********************************************************************
>  Please consider the environment before printing this email or its attachments.
> The contents of this email are for the named addressees only.  It contains information which may be confidential and privileged.  If you are not the intended recipient, please notify the sender immediately, destroy this email and any attachments and do not otherwise disclose or use them. Email transmission is not a secure method of communication and Man Investments cannot accept responsibility for the completeness or accuracy of this email or any attachments. Whilst Man Investments makes every effort to keep its network free from viruses, it does not accept responsibility for any computer virus which might be transferred by way of this email or any attachments. This email does not constitute a request, offer, recommendation or solicitation of any kind to buy, subscribe, sell or redeem any investment instruments or to perform other such transactions of any kind. Man Investments reserves the right to monitor, record and retain all electronic communications through its network to ensure the integrity of its systems, for record keeping and regulatory purposes.
> Visit us at: www.maninvestments.com
> TG0908
> **********************************************************************
>
>



-- 
Claus Ibsen
Apache Camel Committer

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

RE: Combining custom error handling with a transactional rollback

Posted by "Purcell, Chris (London)" <cp...@maninvestments.com>.

On Monday, 5 October, 2009 at 05:35, Claus Ibsen wrote:
> If you think that error handling is something that is easy 
> then you cant be more wrong. Its hard.

Sorry, wasn't intending to cause offense.

> If you are using transacted routes then leave it to the 
> underlying transaction manager to handle the error.

So, as I understand it, that means if I get an error in a transacted
route, my only option is to rollback and take no other action?

> If you mix and match with Camels onException and default 
> error handlers etc. then you have to be much more careful.

I'm happy to be more careful, I just can't find *any* way to mix and
match.

> It would of course be much easier to somehow help you if you 
> share your routes and more information what you want to 
> archive and where you think there is a problem.

As I said in my previous message, I've made a set of test routes
illustrating what I'm trying to achieve. I just don't know how you want
them provided. Should I email them to this group (unfriendly to those
with slow connections), or raise a bug report in JIRA so I can attach
them?

Chris

**********************************************************************
 Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees only.  It contains information which may be confidential and privileged.  If you are not the intended recipient, please notify the sender immediately, destroy this email and any attachments and do not otherwise disclose or use them. Email transmission is not a secure method of communication and Man Investments cannot accept responsibility for the completeness or accuracy of this email or any attachments. Whilst Man Investments makes every effort to keep its network free from viruses, it does not accept responsibility for any computer virus which might be transferred by way of this email or any attachments. This email does not constitute a request, offer, recommendation or solicitation of any kind to buy, subscribe, sell or redeem any investment instruments or to perform other such transactions of any kind. Man Investments reserves the right to monitor, record and retain all electronic communications through its network to ensure the integrity of its systems, for record keeping and regulatory purposes. 
Visit us at: www.maninvestments.com 
TG0908
**********************************************************************

Re: Combining custom error handling with a transactional rollback

Posted by Claus Ibsen <cl...@gmail.com>.

Hi

If you think that error handling is something that is easy then you
cant be more wrong. Its hard.

If you are using transacted routes then leave it to the underlying
transaction manager to handle the error.
If you mix and match with Camels onException and default error
handlers etc. then you have to be much more careful.
They where original designed two be two distinct scheme where you
could choice either one.

It would of course be much easier to somehow help you if you share
your routes and more information what you want to archive and where
you think there is a problem.



On Sun, Oct 4, 2009 at 7:08 PM, Purcell, Chris (London)
<cp...@maninvestments.com> wrote:
> On Sat, 3 Oct, 2009 at 06:57, Claus wrote:
>> If you are using Camel 2.0 you got the onCompletion...
>
> The onCompletion block seems to suffer exactly the same issue as the
> onException one: the transacted tag effectively disables it.
>
> Moving the onException block *after* the transacted tag doesn't work
> either: it gets treated like a regular block of code, and gets called
> all the time.
>
> Further, in an attempt to reproduce the issue outside of my application,
> I've discovered I was quite lucky to get onException working at all with
> transactions: it's only being hit because I have a split around my
> transacted block. No idea why that would be.
>
>> ...in Camel 2.0 you can also force a rollback...
>
> If I put a rollback tag in my onException path (in the rare case I can
> get that path to work at all), it somehow makes Camel enter an infinite
> loop.
>
> I'd be happy to raise this as a bug via JIRA, with my various attempts
> at solutions attached, if that helps. I kind of assumed error handling
> on transacted routes should "just work", especially as there is a
> passing comment to that effect in the docs.
>
> Now I will attempt some analysis, based on what I've seen trying to
> debug my code:
>
> The key to the problem seems to be that exception handling is not
> handled in a standard, Java-like way. I would expect the exception to
> propagate its way up to the outermost error handler, with intermediate
> blocks attempting mediation only if they have specific rules defined:
> for instance, the transacted error handler would only perform rollback,
> then rethrow the error. Instead, all error handlers attempt to
> completely handle the error, and all blocks without explicit error
> handlers copy the outermost one -- except for <transacted /> which
> creates a new TransactionErrorHandler. This works fine if there is only
> one error handler, but causes lots of problems when, as in my case,
> there are two. It would also cause problems for transacted blocks with
> nested blocks inside -- which hold a copy of the outermost,
> non-transactional error handler -- except the DefaultErrorHandler has
> explicit code to disable itself if there is a transaction. This would
> not be necessary under a propagation-based scheme.
>
> Cheers,
> Chris
>
> **********************************************************************
>  Please consider the environment before printing this email or its attachments.
> The contents of this email are for the named addressees only.  It contains information which may be confidential and privileged.  If you are not the intended recipient, please notify the sender immediately, destroy this email and any attachments and do not otherwise disclose or use them. Email transmission is not a secure method of communication and Man Investments cannot accept responsibility for the completeness or accuracy of this email or any attachments. Whilst Man Investments makes every effort to keep its network free from viruses, it does not accept responsibility for any computer virus which might be transferred by way of this email or any attachments. This email does not constitute a request, offer, recommendation or solicitation of any kind to buy, subscribe, sell or redeem any investment instruments or to perform other such transactions of any kind. Man Investments reserves the right to monitor, record and retain all electronic communications through its network to ensure the integrity of its systems, for record keeping and regulatory purposes.
> Visit us at: www.maninvestments.com
> TG0908
> **********************************************************************
>
>



-- 
Claus Ibsen
Apache Camel Committer

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

RE: Combining custom error handling with a transactional rollback

Posted by "Purcell, Chris (London)" <cp...@maninvestments.com>.

On Sat, 3 Oct, 2009 at 06:57, Claus wrote:
> If you are using Camel 2.0 you got the onCompletion...

The onCompletion block seems to suffer exactly the same issue as the
onException one: the transacted tag effectively disables it.

Moving the onException block *after* the transacted tag doesn't work
either: it gets treated like a regular block of code, and gets called
all the time.

Further, in an attempt to reproduce the issue outside of my application,
I've discovered I was quite lucky to get onException working at all with
transactions: it's only being hit because I have a split around my
transacted block. No idea why that would be.

> ...in Camel 2.0 you can also force a rollback...

If I put a rollback tag in my onException path (in the rare case I can
get that path to work at all), it somehow makes Camel enter an infinite
loop.

I'd be happy to raise this as a bug via JIRA, with my various attempts
at solutions attached, if that helps. I kind of assumed error handling
on transacted routes should "just work", especially as there is a
passing comment to that effect in the docs.

Now I will attempt some analysis, based on what I've seen trying to
debug my code:

The key to the problem seems to be that exception handling is not
handled in a standard, Java-like way. I would expect the exception to
propagate its way up to the outermost error handler, with intermediate
blocks attempting mediation only if they have specific rules defined:
for instance, the transacted error handler would only perform rollback,
then rethrow the error. Instead, all error handlers attempt to
completely handle the error, and all blocks without explicit error
handlers copy the outermost one -- except for <transacted /> which
creates a new TransactionErrorHandler. This works fine if there is only
one error handler, but causes lots of problems when, as in my case,
there are two. It would also cause problems for transacted blocks with
nested blocks inside -- which hold a copy of the outermost,
non-transactional error handler -- except the DefaultErrorHandler has
explicit code to disable itself if there is a transaction. This would
not be necessary under a propagation-based scheme.

Cheers,
Chris

Re: Combining custom error handling with a transactional rollback

Posted by Claus Ibsen <cl...@gmail.com>.

Hi

If you are using Camel 2.0 you got the onCompletion
http://davsclaus.blogspot.com/2009/06/on-road-to-camel-20-oncompletion.html

Which allows you to do further handling after the exchange is kinda
finished. For example to send a warning email.

The rollback should happen automatically in an exception occurs which
is not handled. However in Camel 2.0 you can also force a rollback
with the .rollback() DSL.


On Fri, Oct 2, 2009 at 6:47 PM, Purcell, Chris (London)
<cp...@maninvestments.com> wrote:
> Hi all,
>
> I'm writing a Camel pipeline and I'd like to do both of the following
> when an exception is thrown:
>
> (1) Roll back the current transaction, if one has been started (it
> starts mid-pipeline)
> (2) Do some further handling of the current message, ultimately sending
> a warning email about the problem
>
> I can find a way to do either of the above, but I cannot seem to do
> both. Adding a custom error handler appears to silently disable the
> rollback.
>
> I cannot process the error in the object initially sending the message
> to the queue, as I'm actually splitting the message and handling the
> components separately, one transaction each, and need to know exactly
> which one(s) failed -- and let the remainder succeed.
>
> Cheers,
> Chris
>
> **********************************************************************
>  Please consider the environment before printing this email or its attachments.
> The contents of this email are for the named addressees only.  It contains information which may be confidential and privileged.  If you are not the intended recipient, please notify the sender immediately, destroy this email and any attachments and do not otherwise disclose or use them. Email transmission is not a secure method of communication and Man Investments cannot accept responsibility for the completeness or accuracy of this email or any attachments. Whilst Man Investments makes every effort to keep its network free from viruses, it does not accept responsibility for any computer virus which might be transferred by way of this email or any attachments. This email does not constitute a request, offer, recommendation or solicitation of any kind to buy, subscribe, sell or redeem any investment instruments or to perform other such transactions of any kind. Man Investments reserves the right to monitor, record and retain all electronic communications through its network to ensure the integrity of its systems, for record keeping and regulatory purposes.
> Visit us at: www.maninvestments.com
> TG0908
> **********************************************************************
>
>



-- 
Claus Ibsen
Apache Camel Committer

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