zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Stribling <st...@nicira.com>
Subject Re: watcher semantics for session events in the C client
Date Fri, 25 Mar 2011 15:56:16 GMT
Stephen Tyree wrote:
> Yeah, it's a feature. You can think of those session events as notification
> that the watcher will or will not be triggered in a given time period. Given
> that watches are not triggered while you are not connected, and won't be
> resent when you do become connected, having it so the watcher callbacks
> receive session events as well is a way to allow consumers of Zookeeper to
> prepare for and recover from situations where watches they expect to fire
> might not. Also, if every time the network had a little blip your watchers
> were reset that would get annoying quick. Blips in the connection could lead
> to stampedes of resetting watches, which would be silly.
>   

Thanks Stephen, that's what I figured was going on, I was just confused 
by the documentation.

> An example of the utility of this was in a notification system I set up.
> Essentially, whenever I was notified in a watcher callback that I had just
> been reconnected, I would check to see if my watcher should have fired in
> the time I was disconnected. If it should have, I performed the notification
> and reset the watch, otherwise I continued to wait.
>   

But in either case, it sounds like the semantics are that the watch 
would still be set because it was never fired.  So why do you need to 
reset the watch in the case that you fire the notification?


Mime
View raw message