Hi The default error handler is now changed in Camel 2.0.
On Wed, Apr 1, 2009 at 11:58 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Wed, Apr 1, 2009 at 11:51 AM, Roman Kalukiewicz > <roman.kalukiew...@gmail.com> wrote: >> I would definitely support #1. >> >> #3 is not so good as a default one because it can cause some side effects >> like when you use in-out JMS endpoint. If nothing listens to the queue, then >> you will end up with 6 messages in request queue instead of one (assuming >> you don't use transactions). >> >> BTW Last time when I was looking at it there was no easy way to do #3 even >> if you want it (to have redeliveries, but send an exception in case they >> fail). > Yeah #3 should really be let TransactionErrorHandler support onException. > Allowing you to catch certain exceptions and let it be handled so > there are no rollback. > > >> >> Roman >> >> 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 >>> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > Apache Camel Reference Card: > http://refcardz.dzone.com/refcardz/enterprise-integration > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration
