zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Bangert <...@groovie.org>
Subject Re: Clarification of watch behavior at the Zookeeper Server
Date Fri, 13 Sep 2013 16:32:36 GMT
On Sep 12, 2013, at 10:57 AM, Ben Bangert <ben@groovie.org> wrote:

> Why do the docs conflict with the code on how many types of watches there are?

Answering my own question, the answer seems to be that despite the code suggesting there are
existsWatches, these are actually setup to special case a situation (which I'm not entirely
sure of). The code is actually adding exist watches to the dataWatches HashMap, unless rc
<> 0. I'm not sure what condition is required for that.

> All the code indicates there are three types of watches, saying that 'exists' is a separate
watch type. The code however merges exists watches for the same path into data watches (as
it should given what the docs say), but then there's this bizarre comment in the code on line
306 of http://svn.apache.org/viewvc/zookeeper/trunk/src/java/main/org/apache/zookeeper/ZooKeeper.java?view=markup
> LOG.warn("We are triggering an exists watch for delete! Shouldn't happen!");
> This makes no sense. All the docs indicate exists watches should and will be triggered
for a NodeDelete event (the doc example above specifically uses exists in a delete example!).
After reading the code a bit more, I believe there's also a bug:
> 301	 // XXX This shouldn't be needed, but just in case
> 302	 synchronized (existWatches) {
> 303	 Set<Watcher> list = existWatches.remove(clientPath);
> 304	 if (list != null) {
> 305	 addTo(existWatches.remove(clientPath), result);
> 306	 LOG.warn("We are triggering an exists watch for delete! Shouldn't happen!"); 
> 307	 }
> 308	 }
> Line 303 removes the watch, so line 305's return will be a null, no?. I believe line
305 should be adding the new list made on line 303.

This bug will likely never occur, as I think the comment is probably right. It should be impossible
for existWatches to ever have anything in it by the time a NodeDelete for the path occurs.
Perhaps clever use of SetWatches on a reconnect right as the node is being deleted by another
client could cause it.... not sure.

View raw message