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: Combining custom error handling with a transactional rollback
Date Mon, 05 Oct 2009 04:35:29 GMT
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)
<cpurcell@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

Mime
View raw message