right now we don't keep enough meta-data around to reliably trigger those more specific watches if a client gets temporarily disconnected from zookeeper.
ben On Mon, May 23, 2011 at 11:27 AM, Stephen Tyree <[email protected]> wrote: > Hello all, > > I had an idea as to how we could improve the interface for watches. When > people set watches, they often do so with specific events in mind. For > instance, when I set a watch on a getChildren call, maybe I'm only concerned > with when new children are added. In another case, when I set an existence > watch on a particular znode, maybe I'm only concerned if it is created. This > behavior is mostly recreatable today by retrying the setting of watches > until you are successful in waiting for the right event, but that approach > can lead to coding errors and definitely increases the number of requests > made by the client. On top of this, you are also less likely to capture the > desired event in a timely fashion for a number of reasons: > > - For existence watches you need to set the watch for the event you are > interested in (e.g.: created) only when the znode is in the opposite state > (e.g.: deleted). Failure would require checking to see if the node was > actually created (using the czxid), and resetting the watch if not. > - For getChildren watches, to capture only specific events (znodes added), > you would have to create a watch on the list of children and manually parse > for any differences when the watch is fired. Failure would require resetting > the watch. > > Not sure of the feasibility on this one since I am woefully not familiar > with the server side of things, but it seems like it could be useful to > have. > > Thanks, > Stephen Tyree >
