Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper, mail # dev - Random Idea for Watches


Copy link to this message
-
Re: Random Idea for Watches
Benjamin Reed 2011-05-23, 21:19
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
>