[
https://issues.apache.org/jira/browse/ZOOKEEPER-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419158#comment-16419158
]
Andor Molnar commented on ZOOKEEPER-3014:
-----------------------------------------
Sorry, ignore my previous comments. Now I see your point.
When you talked about exists() method, you were actually referring to Curator's
checkExists(), which eventually calls exists(), so it doesn't really matter.
Later Curator fixed the issue by calling getData() instead which - as you said
- doesn't add watch if the node doesn't exist, so Curator doesn't leak watches
anymore.
All fine.
But that's not an issue with ZooKeeper. You should be able to setup a watch on
non-existent node to get notified when it gets created. That's a feature, so I
think you can close this Jira as not-an-issue.
> watch can be added to non-existed path by exist command
> -------------------------------------------------------
>
> Key: ZOOKEEPER-3014
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3014
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.4.5, 3.4.6
> Reporter: CHQ
> Priority: Major
> Fix For: 3.4.12
>
> Attachments: TestCurator.java, image-2018-03-28-22-51-33-751.png
>
>
> We have client A which create a znode ,and its path is /zk/lock/100000.
> Another client B thread is acquiring for the lock, so it calls the exist
> command with watch periodically to check if it is available. Then Client A
> has finished this work, and delete this znode. Client b still calls exist
> command with watch. Because the code doesn't check node existence, when the
> Watch add operation comes , it will add to non-exist node path.
> This problem may be cause by the follow code.
> {code:java}
> public Stat statNode(String path, Watcher watcher)
> throws KeeperException.NoNodeException {
> Stat stat = new Stat();
> DataNode n = nodes.get(path);
> if (watcher != null) {
> dataWatches.addWatch(path, watcher);
> }
> if (n == null) {
> throw new KeeperException.NoNodeException();
> }
> synchronized (n) {
> n.copyStat(stat);
> return stat;
> }
> }
> {code}
> The zk version we use is 3.4.5. We meet a problem that is the zk client try
> to reestablish to zk cluster failed after disconnect for some reason.We find
> it causes by ZOOKEEPER-706. But we try to know why there are so many watches.
> Then we find this problem.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
