camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Gilday" <>
Subject Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?
Date Tue, 31 Mar 2009 09:50:34 GMT
Based on the routes I have configured we are either doing a custom
configuration or turning it off.

So +1 for disabled by default.

----- Original message -----
From: "Claus Ibsen" <>
Date: Tue, 31 Mar 2009 07:51:11 +0200
Subject: [DISCUSS] - Default error handler in Camel 2.0, what should we


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

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

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!!!

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
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

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,

Any thoughts?

Claus Ibsen
Apache Camel Committer

Open Source Integration:

View raw message