camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Vanthienen <>
Subject Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
Date Wed, 01 Apr 2009 07:28:23 GMT

I'm in favor of disabling error handling by default as well.  People
should really configure this to suit their environment.  And with my
ServiceMix hat on, this would be a big improvement as well -- error
handling should be configured there based on the properties of the
given message flow (e.g. transaction or not, clustered or not, ...).


Gert Vanthienen
Open Source SOA:

2009/3/31 Claus Ibsen <>:
> Hi
> As we work on the Camel 2.0 I would suggest that we start a discussion
> what should be the preferred error handler defaults in Camel 2.0.
> What we currently have is the DLC is default and it does 6 retries
> with 1 sec apart and then just log an ERROR and ends the exchange.
> We have 3 different error handler types
> - no error handler (= disabled)
> - DeadLetterChannel (= default in 1.x)
> - TransactionErrorHandler (= using Spring TX)
> As people can use Camel in different runtimes and with different needs
> for error handling we cannot have a default that fits all situations.
> We could for instance do
> 1)
> Disable error handling by default.
> This would be the least surprises for end users. If there is some
> exception then it would be propagated back to the caller.
> We could even optimize the logic in Camel to avoid adding the
> interceptor that adds the noErrorHandler.
> +1 from me
> 2)
> Keep it as is
> big -1 from me. We have the luxury of being able to change defaults
> before 2.0 is released. So we should do it!!!
> 3)
> Use DeadLetterChannel but add a feature so it avoids failure handling
> it by default. So it will be able to do retries but if it fails all
> together
> it will propagate the exception back to the caller as if the have been
> no error handler at all.
> This feature could also be useable for end users in other situations,
> eg retry IOExceptions and in case of a all attempts failed then
> propgate the excpetion back to the caller.
> What should the option name be:
> - moveToDeadLetterQueue=false
> - handled=false   (like the handled we have at onException)
> +1 as well. We can even do #1 and #3
> 4)
> For TX its mostly all the Spring XML garbage that is needed to setup
> TX that can be a bit hard to get configure correct.
> So the JMS component have a transacted=true option to allow to do this
> itself or discover if there is a Spring TX manager already.
> Maybe we can default to use transactionErrorHandler if we can find a
> Spring TX manager. But this would only work for certain transports
> that support TX, and that is mostly only JMS and JDBC.
> So what should happens for routing not involving those, eg camel-cxf,
> over file to a mail etc?
> Could be confusing, if Camel uses TX for certain routes and the other
> for the other routes.
> So what we have now with the transacted=true option is good as end
> users need to explicit declare this option.
> We could maybe add this for the JDBC based components as well: JPA, JDBC, SQL.
> Any thoughts?
> --
> Claus Ibsen
> Apache Camel Committer
> Open Source Integration:
> Blog:
> Twitter:

View raw message