Hi Preben,
I think a delay will not help much as it would mean that you have to
very carefully time the startup of your compontents.
You could also solve this by simply starting the whole container sooner
or later than the other.
I think a real solution would require that the node with higher priority
should even get the lock when the other one is already running. So the
other component should then stop itself. I am not yet sure how to
implement this though. Perhaps with hearbeat messages in addition to the
db lock.
About your second concern:
I also wonder if this solution is too fine grained. If you have many
integrations deployed as bundles or war files then you typically will
not want to configure the locking on each integration level. The
container would be a better place for this.
So I will try to implement the locking on the level of Karaf. Instead of
routes you would have the active/passive on the feature level. So the
idea could be to have failover groups.
Each group has a lock resource (like a table or a file) , a priority and
a list of features or war files.
So for example in your case you could have two nodes:
Node A:
failover-group in priority 1 features integrationAIn, integrationBIn, ...
failover-group out priority 2 features integrationAoutm,
integrationBOut, ...
Node B:
failover-group in priority 2 features integrationAIn, integrationBIn, ...
failover-group out priority 1 features integrationAoutm,
integrationBOut, ...
So Node A would primarily host the out sides and be passive for the in
sides.
Node B would be active for the in side and passive for the out sides.
In case of a failure of one node the other would host all integrations.
If the failing node comes back then the roles would be like in the
beginning.
The same could work for a servlet container on the level of war files.
What do you think? Would that make sense?
Christian
Am 13.11.2011 11:10, schrieb Preben.Asmussen:
Maybe some kind of initial delay property that should delay the lock attempt
as part of the policy.
This way you could set a higher delay on the slave than on the primary. The
delay should then be configured from the outside eg. property file.
Somehow (my stomach I guess) I'm not quite sure of the practical use of the
lock solution.
Master/slave on eg. karaf or servicemix would be a cleaner cut.
One would also have to consider situations when slaves has become master on
one node (in case of failure on one node) and you want to bring back the
master.
/Preben
--
View this message in context:
http://camel.465427.n5.nabble.com/How-to-make-your-camel-routes-highly-available-when-only-one-may-be-active-at-a-time-tp4984581p4988271.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
