zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: FYI - zetcd: running ZooKeeper apps without ZooKeeper
Date Tue, 23 May 2017 10:42:04 GMT
> @jordan
> I'm really interested in your observation about the Consul herding.  Could you elaborate
on the herding argument? Perhaps we should write a post about it...

Here's their recipe for Leader Election (which is the same as a lock in this case): https://www.consul.io/docs/guides/leader-election.html
<https://www.consul.io/docs/guides/leader-election.html>

curl -X PUT -d <body> http://localhost:8500/v1/kv/<key>?acquire=<session>
<http://localhost:8500/v1/kv/%3Ckey%3E?acquire=%3Csession%3E>
Note that a given session can not hold the same lock more than once. ZooKeeper is better here
- a single client can have multiple threads participating in the same lock
If you don't get the lock via the first call, you start "Watching for changes ... via a blocking
query against <key>."
In their API, the way you watch for changes is to use what they call "blocking queries": https://www.consul.io/api/index.html#blocking-queries
<https://www.consul.io/api/index.html#blocking-queries> - whereby "the HTTP request
will "hang" until a change in the system occurs, or the maximum timeout is reached. ". In
other words, when the lock is released all watchers are notified - i.e. a herd (also not fair).
ZooKeeper is superior here because of sequential ephemeral nodes. A client waiting for a lock
only watches the node the precedes him. This has the benefit of being fair and not causing
a herd.

-JZ
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message