camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Kalukiewicz <roman.kalukiew...@gmail.com>
Subject Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
Date Wed, 01 Apr 2009 09:51:03 GMT
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).

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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message