camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Dynamic calculation of route startupOrder through dependencies?
Date Mon, 13 Jul 2015 14:24:23 GMT

Yeah over the years many of the Camel components has become more
lenient/flexible in terms of starting order, so you can start seda
routes in any order.

The direct component now has an option to not fail if no active
consumers. And its likely a matter of just adding some logic to it
that it detects the camel context is in the process of starting, then
it shouldn't fail by default. And then when the context has been fully
started, it could defer this check if there is no active consumers and
then fail. (a good idea I need to log).

Then its more or less not so important the order.

On Mon, Jul 13, 2015 at 4:08 PM, Jakub Korab
<> wrote:
> Working out route order startup automatically is more problematic than it
> would appear. Consider the following:
> .recipientList(bean(myRoutingBean, "whereTo"))
> This is just one EIP where the route is worked out on a per-exchange basis.
> The framework itself has no insight into the possible values that the POJO
> could return, and therefore cannot make any judgements as to the startup
> ordering of the routes.
> If anything, the automatic ordering should be inversed (start the top route
> last, and stop it first) as this is the usual way that routing logic is
> written. My guess though is that this is such a substantial behavioural
> change, it would not be a candidate until Camel 3.
> Jakub
> On 09/07/15 20:10, Serge Smertin wrote:
>> Greetings!
>> Currently Apache Camel can have route dependencies hardcoded through
>> numbers, which doesn't really work well, when multiple route builders are
>> involved and they have overlapping order numbers. -
>> Given following Java DSL syntax -
>> from("seda:foo").id("sedaFoo").to("mock:result");
>> from("direct:start").id("directStart")
>> .dependsOn("sedaFoo", "minify")
>> .processRef("myOptionallyWiretappingRoute")
>> .to("seda:foo");
>> from("direct:bar").id("directPubRoute").to("seda:bar");
>> from("direct:minify").id("minify").to("dev:null");
>> ... would it be a nice idea to have routes started up in following order:
>> 1) sedaFoo
>> 2) minify
>> 3) directStart
>> 4) directPubRoute
>> Why? My optionally wiretapping route might want to publish messages to
>> minify route related endpoint. Obviously, in production it would be
>> publishing to normal broker like AMQ or like, but during automated testing
>> of routes Producer[direct://minify] would be already stopped and dynamic
>> routing would result in exceptions during graceful shutdown.
>> Of course, it might introduce architectural concept of running routes
>> registry over cluster synchronised though OSGi or any distributed
>> coordination things like ZooKeeper/Hazelcast/Infinispan/whatever is there,
>> but for initial feature release i would be really happy with dependencies
>> within single CamelContext.
>> Any thoughts on this?..
>> - Serge

Claus Ibsen
Red Hat, Inc.
Twitter: davsclaus
Author of Camel in Action:

View raw message