Recipe: Barrier

[eric]

From http://zookeeper.apache.org/doc/trunk/recipes.html

Distributed systems use barriers to block processing of a set of nodes until a condition is met at which time all the nodes are allowed to proceed. Barriers are implemented in ZooKeeper by designating a barrier node. The barrier is in place if the barrier node exists. Here's the pseudo code:

1. Client calls the ZooKeeper API's exists() function on the barrier node, with watch set to true.
2. If exists() returns false, the barrier is gone and the client proceeds
3. Else, if exists() returns true, the clients wait for a watch event from ZooKeeper for the barrier node.
4. When the watch event is triggered, the client reissues the exists( ) call, again waiting until the barrier node is removed.

I plan on implementing this at some point if no one else does first...

I haven't decided if it makes sense to be in this gem or in a recipes gem. It seems reasonable it should be in the same place the locker is...

[ryanlecompte]

This would be a great addition for redis_failover, since it would be used for coordinated failover.

I had two rough implementations of a latch / barrier based on ZK groups. I am sure they have holes, however.

Latch: https://gist.github.com/3f262126207fe55141d2
Barrier: https://gist.github.com/aae42d31922f07bc5912

It probably makes sense to implement the barrier based on the recipe that @eric pasted above, as opposed to trying to overlay it on top of ZK groups. Not sure.

[slyphon]

I've been thinking about this for a while, and I would like to make the
following changes to the gems for release 2.0

• remove the old deprecated election stuff
• move the locker into its own gem as suggested. I think this should be a
  "zk-recipes" gem with Locker, Barrier, Semaphore, etc.
• possibly have main zk gem depend on the recipes gem, as people are
  probably going to want those building blocks.

The next 3 weeks or so are going to be pretty intensive as I transition to
a new job, so I don't know how much active participation I'll be able to do.

On Sunday, August 26, 2012, Eric Lindvall wrote:

From http://zookeeper.apache.org/doc/trunk/recipes.html

Distributed systems use barriers to block processing of a set of nodes
until a condition is met at which time all the nodes are allowed to
proceed. Barriers are implemented in ZooKeeper by designating a barrier
node. The barrier is in place if the barrier node exists. Here's the pseudo
code:

1. Client calls the ZooKeeper API's exists() function on the barrier
   node, with watch set to true.

2. If exists() returns false, the barrier is gone and the client
   proceeds

3. Else, if exists() returns true, the clients wait for a watch event
   from ZooKeeper for the barrier node.

4. When the watch event is triggered, the client reissues the exists(
   ) call, again waiting until the barrier node is removed.

   I plan on implementing this at some point if no one else does first...

I haven't decided if it makes sense to be in this gem or in a recipes gem.
It seems reasonable it should be in the same place the locker is...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42.