camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Vanthienen <gert.vanthie...@skynet.be>
Subject Re: Deprecating old methods and changing the default error handler
Date Mon, 23 Jun 2008 10:27:00 GMT
James,

This would be a good solution for people using Camel with ActiveMQ (and 
possibly also for ServiceMix), but isn't Camel supposed to be more 
transport/technology-agnostic?  If Camel is also intended to be used as 
a mediation/routing engine for CXF, MINA, ..., I don't think there is a 
single, non-sucky default error handler configuration for all those.  
Would it be an option to have no default error handler inside Camel, but 
let the underlying system add something non-sucky (with a big WARN 
message) implicitly whenever a good default for that system exists and 
no error handler was set in the RouteBuilder itself?

Gert

James Strachan wrote:
> BTW had a thought for changing the default to something non-sucky.
>
> How about if we kept the retry-6-times (maybe with exponential backoff
> being the default) - but rather than using the log as the dead letter
> queue (which sucks - my bad! :) - we defaulted the dead letter queue
> to being something like "activemq:Camel.DeadLetter")
>
> Then if the caller doesn't have ActiveMQ configured, its gonna fail -
> hence the whole thing will fail? If folks have ActiveMQ installed then
> the default is something reasonable - use retry then a real,
> persistent dead letter queue?
>
> I like the idea of convention over configuration and doing the right
> thing out of the box; though for things like retry/dead letter its
> maybe worth users specifying that stuff; however I wonder if using a
> DLQ with ActiveMQ is a sensible default - as its either reliable &
> persistent if ActiveMQ is available -or it fails (and so acts like no
> error handler :)
>
> Thoughts?
>
> 2008/6/20 Claus Ibsen <ci@silverbullet.dk>:
>   
>> Hi Gert
>>
>> Great insight. And sorry about the problems with the API breakings. We should target
all the "fix the tangle etc." tickets to Camel 2.0, so there wont be another API breaking.
>>
>> +1 for that one
>>
>> Do you have a list at hand what the API breaking were between 1.3 and 1.4? We should
at least document this in the release note that there can be API breakings.
>>
>> +1 of course for the dead letter channel as well. We cant have them being retried
6 times within 1 sec. Interval and then just stoved away in a log ;)
>>
>> Maybe somekind of INFO/WARN level when the route context is created/started that
the DLC is NoErrorHandler so end users will notice that they might haven't thought/set a error
handling strategy fitting to their needs.
>>
>>
>> Med venlig hilsen
>>
>> Claus Ibsen
>> ......................................
>> Silverbullet
>> Skovsgårdsvænget 21
>> 8362 Hørning
>> Tlf. +45 2962 7576
>> Web: www.silverbullet.dk
>> -----Original Message-----
>> From: Gert Vanthienen [mailto:gert.vanthienen@skynet.be]
>> Sent: 19. juni 2008 08:40
>> To: camel-dev@activemq.apache.org
>> Subject: Deprecating old methods and changing the default error handler
>>
>> L.S.,
>>
>>
>> While I was doing a project with a customer last week, I ran into a few
>> problems with using Camel for them.
>>
>> First problem were changes in the API (e.g. Endpoint.getContext()
>> becomes Endpoint.getCamelContext()).  I needed to rebuild
>> servicemix-camel to get some fixes there, but along came a new version
>> of Camel and that was breaking a lot of the existing code.  We might
>> want to consider deprecating the old methods instead of removing them.
>> Not entirely sure about this though: it will probably slow us down a
>> bit, but on the other hand, when a user updates from 1.3 to 1.4 he
>> probably doesn't expect API breakage of this type.  They would expect
>> this to happen from a major release though (Camel 2.0), so I would
>> suggest cleaning up all deprecated code at that point.  Wdyt?
>>
>> A second thing that kind surprises people is our implicit use of a dead
>> letter channel in every RouteBuilder.  Let me give an example:
>> public class MyRouteBuilder extends RouteBuilder {
>>  public void configure() {
>>
>> from("jbi:endpoint:urn:ns:service:endpoint1").to("jbi:endpoint:urn:ns:service:endpoint2");
>>  }
>> }
>>
>> If you look at the code above, it appears to be routing from one JBI
>> endpoint to the next one, without doing anything else.  Now, in reality,
>> if something goes wrong at the second endpoint (e.g. FTP server goes
>> down), the default DeadLetterChannel kicks in and after 5 retries, it
>> will "log away" the message.  The first JBI component will never know
>> something went wrong, because the JBI Exchange going back will just say
>> DONE and the only trace of something going wrong is in the logs -- the
>> message itself was lost in the process.  We should at the very least
>> warn people to explicitly set an errorHandler() when using Camel inside
>> Servicemix (usually just errorHandler(noErrorHandler()), but actually I
>> don't think we should make this behavior the default.  It might be good
>> for testing/demos, but in real life you probably want to specify a more
>> advanced error handling routine or let the underlying system (e.g.
>> ServiceMix) take care of it.  In my mind, we should seriously consider
>> making no error handler the default for Camel 2.0.  Once again: wdyt?
>>
>>
>> Regards,
>>
>> Gert
>>
>>
>>     
>
>
>
>   


Mime
View raw message