camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
Date Wed, 01 Apr 2009 09:58:52 GMT
On Wed, Apr 1, 2009 at 11:51 AM, Roman Kalukiewicz
<roman.kalukiewicz@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.ibsen@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

Mime
View raw message