[
https://issues.apache.org/jira/browse/ZOOKEEPER-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
CHQ resolved ZOOKEEPER-3014.
----------------------------
Resolution: Not A Problem
Thank you [~andorm].
Yes, it is not a issue Of ZK, but a issue of curator before version 2.5.0.
> 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)
