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
