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
