I don't think that the API gives you an option of removing ONLY client side watches. You can set a flag indicating that if the call to the server fails that the client side watches should still be removed.
On Tue, Jan 19, 2016 at 8:10 AM, Scott Blum <[email protected]> wrote: > 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 < > [email protected]> 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 <[email protected]> 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 < > > > [email protected]> 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 > > >> > > > > >
