Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?

[Willem Jiang <wi...@gmail.com>]

+1 for 1) and 3).
We need to find a better way to handle the TX with Spring by default.

Willem

Claus Ibsen wrote:
> 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?
> 
> 
> 

Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?

[Claus Ibsen <cl...@gmail.com>]

On Wed, Apr 1, 2009 at 6:40 AM, Willem Jiang <wi...@gmail.com> wrote:
> +1 for 1) and 3).
> We need to find a better way to handle the TX with Spring by default.

For the TX part people would like the *onException* feature to be
possible as well.
We have this kind of "trick" where you can use the DLC and let the TX
be required by default, if you dont add the policy(required).
What is needed though is that the onExcpetion is also integrated with
the transactionErrorHandler.

That would allow people to eg catch validation exceptions in TX routes
and route these to another endpoint and eg dont rollback as this might
be OK.




>
> Willem
>
> Claus Ibsen wrote:
>> 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
Apache Camel Reference Card:
http://refcardz.dzone.com/refcardz/enterprise-integration