[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14603922#comment-14603922 ] Camille Fournier commented on ZOOKEEPER-2217: - [~caspian] I am closing this jira because this was a fundamental design decision of the system and there seems to be some confusion about the intended usage and behavior. We're happy to discuss this in more depth on the users or dev mailing lists if you are interested in feedback on what you are trying to do. Thanks! > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14603844#comment-14603844 ] Raul Gutierrez Segales commented on ZOOKEEPER-2217: --- getChildren (and getData, etc) do get the data & set their watches atomically, so how would inverting the order change anything? The only way of getting _every_ intermediate state would be by tailing the transaction logs, but at that point maybe ZooKeeper is not the right tool for the job. > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14602268#comment-14602268 ] Caspian commented on ZOOKEEPER-2217: This means that the client needs to handle the events happend between the watch firing and new watch is set. But as I metioned above, why don't make the apis like getChildren to set watch first and then get data, is the zk server support that? If not, why? Thanks > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14602258#comment-14602258 ] Caspian commented on ZOOKEEPER-2217: No, I'm using the java and go client. > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14602253#comment-14602253 ] Caspian commented on ZOOKEEPER-2217: Yeah, the former one. So my question is why don't make the apis like getChildren to set watch first then get data, which guarantee it's conflicted with? > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600709#comment-14600709 ] Raul Gutierrez Segales commented on ZOOKEEPER-2217: --- also, are you using a library like https://github.com/twitter/commons/blob/master/src/java/com/twitter/common/zookeeper/ServerSet.java for service discovery? > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600707#comment-14600707 ] Raul Gutierrez Segales commented on ZOOKEEPER-2217: --- What does missing an event mean in this context? Not being able to capture an intermediate state of the data tree or actually having a watch not firing when it had too? (the former is not supported by desing and the latter shouldn't happen with a stable version, if it did we should track it since it's a huge bug). > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600704#comment-14600704 ] Raul Gutierrez Segales commented on ZOOKEEPER-2217: --- What Camille says below - it doesn't matter if you don't get a view of every intermediate state, because it's design for you to always be able to sync up as long you reset your watch every time it fires. > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600703#comment-14600703 ] Caspian commented on ZOOKEEPER-2217: Yeah, I'm doing service discovery, it's better that the client doesn't miss any events, if some events lost like one child is gone but the client is not notified, some operation will be failed and its's not good for business. > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600530#comment-14600530 ] Caspian commented on ZOOKEEPER-2217: [~kylar] Thanks for your respond. Between the time of event fires and rewatch, some events may happend, these events will be lost, right? > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600120#comment-14600120 ] Raul Gutierrez Segales commented on ZOOKEEPER-2217: --- I think the illustrated scenario is when an event fires and a few nodes are added/removed before the next read actually happens - which is totally legit. I do wonder, what's the use case for which missing an intermediate state of a path would be problematic? Sounds like you are doing service discovery [~caspian]? > 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)
[jira] [Commented] (ZOOKEEPER-2217) event might lost before re-watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600054#comment-14600054 ] Tom Byrne commented on ZOOKEEPER-2217: -- Doesn't Zookeeper.getChildren(final String path, Watcher watcher) do what you want? It re-sets a watch on the path when getting the children, and you never miss events. > 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)
