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) <[email protected]> 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
