camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Korab <jakub.korab.li...@gmail.com>
Subject Re: Dynamic calculation of route startupOrder through dependencies?
Date Mon, 13 Jul 2015 14:08:26 GMT
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. -
> http://camel.apache.org/configuring-route-startup-ordering-and-autostartup.html
>
> 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
>


Mime
View raw message