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 <[EMAIL PROTECTED]>: > 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:[EMAIL PROTECTED] > Sent: 19. juni 2008 08:40 > To: [email protected] > 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 > > -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
