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?
