> On Aug 17, 2019, at 2:50 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > > > > On Sat, Aug 17, 2019 at 10:19 AM Jordan Zimmerman <jor...@jordanzimmerman.com > <mailto:jor...@jordanzimmerman.com>> wrote: > Some thoughts: > > It doesn't really help with any of the "standard" recipes as they all need to > set watches. > > I don't understand that. Watches can be set in a multi.
Not in the public API: https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/Op.java - is it supported in the back-end? > > Not to open a can of worms, but if there were a firehose version of watches > that could be set independently, this type of multi-op could radically > simplify some of the recipes. i.e. one could imagine a multi-op that creates > an ephemeral node and then returns a sorted list of child node names so that > leader election and locks can be done in one shot. > > I don't understand that, either. But this time I just don't understand what > you are suggesting and how it helps. The standard lock recipe creates an ephemeral-sequential node. Once your node (with its sequence number) is returned you call getChildren() to see if you have the lowest numbered node. The lowest numbered node is defined to be the lock holder (or leader, etc.). This requires two round trips. It would be nice to consolidate this into 1 API call. Further, if you're not the lowest numbered node, you must set a watch on the node that precedes you so you know when to check again. This is all very cumbersome to do in client code (thus Curator). Maybe there's a way to specify this entire behavior in a multi call. --- I'll read/review the queue idea separately. -Jordan
