L.S., 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, ...).
Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/3/31 Claus Ibsen <claus.ib...@gmail.com>: > 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: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus >
