I'm not sure.... the thing is that you don't need to make a server call for the watch removal. This looks like it's going to make a server call? The node's deleted, so on the server the watch has already been removed. The only point to the old code was to remove any client-side state associated with the watch in order to allow internal structures to GC.
On Mon, Jan 18, 2016 at 3:56 PM, Jordan Zimmerman < jordan.zimmer...@elastic.co> wrote: > So, this would be right then? > > client.watches().remove(this).ofType(WatcherType.Any).inBackground().forPath(path); > // NEW > > > > On Jan 18, 2016, at 3:42 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > > > It looks like the history has gotten super gnarly, so it's hard to track > > code provenance. But the call to client.clearWatcherReferences(this) has > > always been there. It's important for long running TreeCaches to be able > > to clear dead watchers as they go. > > > > On Mon, Jan 18, 2016 at 2:09 PM, Jordan Zimmerman < > > jordan.zimmer...@elastic.co> wrote: > > > >> Hi Scott, > >> > >> In TreeCache wasDeleted(), there is a call to clear watchers. When was > >> this added? I’m trying to merge into CURATOR-3.0 and the new behavior > would > >> be to remove the watcher via the ZK API. Is this correct or should the > >> watcher stay? Please advise. The new code would be: > >> > >> stat.getAndSet(null); > >> data.getAndSet(null); > >> > client.watches().remove(this).ofType(WatcherType.Any).inBackground().forPath(path); > >> // NEW > >> > >
