Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of hzbarcea@gmail.com designates
 209.85.221.115 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=YaoslEPV5wrOjc/DfcrqnJ6UEjnYcQzEuaAp0XXL5iQ/YGh/RyW42ne7/Ffom0Naf7
         rM4peu/hXnC8DxwC7qkZ4E7cfDJihyXeUwzpPY0cjPc9I7VHs8HwIEifoj8bBP7n68L+
         r4X9DKnKoo3r44ih+Lqn7FmZbBb5c0cylOwco=
Message-Id: <F49077AD-F080-41E5-AF0A-8A8B72FDC7B8@gmail.com>
From: Hadrian Zbarcea <hzbarcea@gmail.com>
To: dev@camel.apache.org
In-Reply-To: <5380c69c0903302251h552756a8sedd6bc4b29cf9c5d@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [DISCUSS] - Default error handler in Camel 2.0,
 what should we do?
Date: Tue, 31 Mar 2009 10:01:26 -0400
References: <5380c69c0903302251h552756a8sedd6bc4b29cf9c5d@mail.gmail.com>

1) +1

Hadrian

On Mar 31, 2009, at 1:51 AM, 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