[
https://issues.apache.org/jira/browse/ZOOKEEPER-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969354#comment-13969354
]
Rakesh R commented on ZOOKEEPER-1910:
-------------------------------------
{quote}
a) removing the watch set on the Server
b) unregister a given watcher or set of watchers
Since 3.5.0 isn't out yet, are we still on time for changing our API? If so,
how would you feel about having removeWatches *only* deal with the server-side
part (i.e.: unregistering the watch from the data tree) and having something
like unregisterWatcher() deal with the watchers known by the client?
{quote}
Thanks [~rgs]. I think 'zk#unregister(watcher)' api name will confuse with the
existing zk#register(watcher), which is actually meant for connection watchers.
So I've tried to do some refinement, kindly see the below section for more
details and would like to know the comments.
# removeWatches - The difference with the earlier api is,
(1)this won't remove the given watcher from the server set even if the watcher
set is empty, but it will remove the reference from the zkclient. This api will
invoke a call to server and maintain orderly execution as earlier. IMHO sending
to server is required to handle packet in-flight cases.
(2)null watcher is not allowed, client will validate and throw
IllegalArgumentException.
# removeAllWatches - This is new api which is meant for clearing all the
watchers both client and server set. Will provide both sync & async api versions
{code}
/**
* For the given znode path, removes the specified watcher of given
* watcherType.
* <p>
* Watcher shouldn't be null. A successful call guarantees that, the
* removed watcher won't be triggered.
* <p>
* @param path - the path of the node
* @param watcher
* - a concrete watcher or null to remove all watchers for the
* given path and watcherType
* @param watcherType - the type of watcher to be removed
* @param local
* - whether the watcher can be removed locally when there is no
* server connection
* @throws InterruptedException
* if the server transaction is interrupted.
* @throws KeeperException.NoWatcher
* if no watcher exists that match the specified parameters
* @throws KeeperException
* if the server signals an error with a non-zero error code.
* @throws IllegalArgumentException
* if an invalid path is specified
* if the watcher is null
* @since 3.5.0
*/
public void removeWatches(String path, Watcher watcher, WatcherType
watcherType, boolean local)
{code}
{code}
/**
* For the given znode path, removes all the watchers of given watcherType.
* <p>
* A successful call guarantees that, the removed watcher won't be
triggered.
* <p>
* @param path - the path of the node
* @param watcherType - the type of watcher to be removed
* @param local
* - whether the watcher can be removed locally when there is no
* server connection
* @throws InterruptedException
* if the server transaction is interrupted.
* @throws KeeperException.NoWatcher
* if no watcher exists that match the specified parameters
* @throws KeeperException
* if the server signals an error with a non-zero error code.
* @throws IllegalArgumentException
* if an invalid path is specified
* @since 3.5.0
*/
public void removeAllWatches(String path, WatcherType watcherType, boolean
local)
{code}
> 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
>
>
> 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)
