Recipe: Barrier #42

Open
eric opened this Issue Aug 27, 2012 · 2 comments

3 participants

@eric
zk-ruby member

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
zk-ruby member

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
@zuazo zuazo referenced this issue in zuazo/zookeeper_bridge-cookbook Nov 27, 2014
Open

Support for "double barriers" #2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment