> @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
