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
