Author: buildbot
Date: Sat Aug 18 04:24:26 2012
New Revision: 829270
Log:
Production update by buildbot for camel
Modified:
websites/production/camel/content/cache/main.pageCache
websites/production/camel/content/zookeeper.html
Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/camel/content/zookeeper.html
==============================================================================
--- websites/production/camel/content/zookeeper.html (original)
+++ websites/production/camel/content/zookeeper.html Sat Aug 18 04:24:26 2012
@@ -186,7 +186,7 @@ template.sendBodyAndHeader(<span class="
<p>ZooKeeper allows for very simple and effective leader election out of the
box; This component exploits this election capability in a <a shape="rect"
href="routepolicy.html" title="RoutePolicy">RoutePolicy</a> to control when and
how routes are enabled. This policy would typically be used in fail-over
scenarios, to control identical instances of a route across a cluster of Camel
based servers. A very common scenario is a simple 'Master-Slave' setup where
there are multiple instances of a route distributed across a cluster but only
one of them, that of the master, should be running at a time. If the master
fails, a new master should be elected from the available slaves and the route
in this new master should be started.</p>
-<p>The policy uses a common znode path across all instances of the RoutePolicy
that will be involved in the election. Each policy writes its id into this node
and zookeeper will order the writes in the order it received them. The policy
then reads the listing of the node to see what postion of its id; this postion
is used to determine if the route should be started or not. The policy is
configured at startup with the number of route instances that should be started
across the cluster and if its position in the list is less than this value then
its route will be started. For a Master-slave scenario, the route is configured
with 1 route instance and only the first entry in the listing will start its
route. All policies watch for updates to the listing and if the listing changes
they recalculate if their route should be started. For more info on Zookeeper's
Leader election capability <a shape="rect" class="external-link"
href="http://zookeeper.apache.org/doc/trunk/recipes.html#
sc_leaderElection">see</a> </p>
+<p>The policy uses a common znode path across all instances of the RoutePolicy
that will be involved in the election. Each policy writes its id into this node
and zookeeper will order the writes in the order it received them. The policy
then reads the listing of the node to see what postion of its id; this postion
is used to determine if the route should be started or not. The policy is
configured at startup with the number of route instances that should be started
across the cluster and if its position in the list is less than this value then
its route will be started. For a Master-slave scenario, the route is configured
with 1 route instance and only the first entry in the listing will start its
route. All policies watch for updates to the listing and if the listing changes
they recalculate if their route should be started. For more info on Zookeeper's
Leader election capability see <a shape="rect" class="external-link"
href="http://zookeeper.apache.org/doc/trunk/recipes.h
tml#sc_leaderElection">this page</a>. </p>
<p>The following example uses the node '/someapplication/somepolicy' for the
election and is set up to start only the top '1' entries in the node listing
i.e. elect a master</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent
panelContent">
