[
https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600549#comment-14600549
]
Camille Fournier commented on ZOOKEEPER-2217:
---------------------------------------------
This is a fundamental aspect of the design of ZK watches, they do not guarantee
that events will be caught in-between the watch being fired and the new data
being read. See the documentation here:
http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html#ch_zkWatches
In particular, they are not designed to be a messaging bus where you get every
change in order.
> event might lost before re-watch
> --------------------------------
>
> Key: ZOOKEEPER-2217
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2217
> Project: ZooKeeper
> Issue Type: Improvement
> Components: c client, java client
> Affects Versions: 3.4.5, 3.4.6
> Environment: jdk1.7_45 on centos6.5 and ubuntu14.4
> Reporter: Caspian
>
> I use zk to monitor the children nodes under a path, eg: /servers.
> when the client is told that children changes, I have to re-watch the path
> again, during the peroid, it's possible that some children down, or some up.
> And those events will be missed.
> For now, my temporary solution is not to use getChildren(path, true...) to
> get children and re-watch this path, but re-watch this path first, then get
> the children. Thus non events can be ignored, but I don't know what will the
> zk server be like if there are too much clients that act like this.
> How do you think of this problem? Is there any other solutions?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
