You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Gert Vanthienen <ge...@skynet.be> on 2008/06/19 08:40:29 UTC
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
Re: Deprecating old methods and changing the default error handler
Posted by Hadrian Zbarcea <hz...@gmail.com>.
+1 +1
On Jun 19, 2008, at 2:40 AM, Gert Vanthienen wrote:
> 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
>
Re: Deprecating old methods and changing the default error handler
Posted by Gert Vanthienen <ge...@skynet.be>.
L.S.,
Added https://issues.apache.org/activemq/browse/CAMEL-629 to re-add the
old getContext/setContext methods and deprecate them instead of removing
them
Gert
James Strachan wrote:
> Sounds good on both counts!
>
> 2008/6/19 Gert Vanthienen <ge...@skynet.be>:
>
>> 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
>>
>>
>>
>
>
>
>
Re: Deprecating old methods and changing the default error handler
Posted by James Strachan <ja...@gmail.com>.
Sounds good on both counts!
2008/6/19 Gert Vanthienen <ge...@skynet.be>:
> 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
Re: Deprecating old methods and changing the default error handler
Posted by Hiram Chirino <hi...@hiramchirino.com>.
We disable by default, but ship every example with the DLQ explicitly
configured to be amq.. so that way when folks copy examples they get
the dlq behavior, but at least it's explicit and in their face.
On Mon, Jun 23, 2008 at 6:52 AM, James Strachan
<ja...@gmail.com> wrote:
> 2008/6/23 Gert Vanthienen <ge...@skynet.be>:
>> 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.
>
> I hear you - but I kinda was thinking, even if folks were using CXF or
> MINA and not ActiveMQ then at least the default would fail (and act
> kinda like no error handler?)
>
>
>> 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?
>
> I guess we could see if there is ActiveMQ available, then default the
> error handler to DLQ using that; otherwise don't add an error handler?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Deprecating old methods and changing the default error handler
Posted by James Strachan <ja...@gmail.com>.
2008/6/23 Gert Vanthienen <ge...@skynet.be>:
> 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.
I hear you - but I kinda was thinking, even if folks were using CXF or
MINA and not ActiveMQ then at least the default would fail (and act
kinda like no error handler?)
> 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?
I guess we could see if there is ActiveMQ available, then default the
error handler to DLQ using that; otherwise don't add an error handler?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Deprecating old methods and changing the default error handler
Posted by Gert Vanthienen <ge...@skynet.be>.
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
>>
>>
>>
>
>
>
>
Re: Deprecating old methods and changing the default error handler
Posted by James Strachan <ja...@gmail.com>.
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
>
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
RE: Deprecating old methods and changing the default error handler
Posted by 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