[
https://issues.apache.org/jira/browse/ZOOKEEPER-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976404#comment-13976404
]
Raul Gutierrez Segales commented on ZOOKEEPER-1910:
---------------------------------------------------
Hmm, added some nits to the RB but overall I am not convinced about this
approach. Why do we need to send a RemoveWatches request to the server with
remove=false if that is essentially a no-op? Just to check if the watch stills
exists in the server before we remove it on the client? It could still race, so
I think that if all we want to do is unregister a watcher locally we should do
it without paying a round-trip to the server.
Also, about the naming, do you think that renaming removeWatches to
removeWatchers would still be confusing?
> RemoveWatches wrongly removes the watcher if multiple watches exists on a path
> ------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-1910
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1910
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Rakesh R
> Assignee: Rakesh R
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-1910.patch, ZOOKEEPER-1910.patch,
> ZOOKEEPER-1910.patch
>
>
> Consider a case where zkclient has added 2 data watchers(say 'w1' and 'w2')
> on '/node1'.
> Now user has removed w1, but this is deleting the 'CnxnWatcher' in ZK server
> against the "/node1" path. This will affect other data watchers(if any) of
> same client on same path. In our case 'w2' would not be notified.
> Note: please see the attached test case to understand more.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
