camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james.strac...@gmail.com>
Subject Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
Date Thu, 02 Apr 2009 15:01:19 GMT
Yay!

2009/4/2 Claus Ibsen <claus.ibsen@gmail.com>:
> Hi
>
> The default error handler is now changed in Camel 2.0.
>
> On Wed, Apr 1, 2009 at 11:58 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>> 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
>>
>
>
>
> --
> 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
>



-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

Mime
View raw message