Hello again Kamel, ZooKeeper does order watch notifications in the same order as the updates that triggered those notifications. Therefore, if your application guarantees that it updates grand_child first and child second, I expect the client to receive notifications in the same order: grand_child first followed by child second.
I read your original email again more closely, and now I'm thinking that the behavior you described sounds unusual. I'd expect the ordering guarantee on watches to deliver the "parent2 NodeChildrenChanged" event before the "Child1 NodeDataChanged" event. My earlier statements about the sync API shouldn't really be applicable here, unless the 2 processes are doing some other out-of-band coordination outside ZooKeeper. Is there something else happening in the application that might be a contributing factor? Do you have a simplified code sample that demonstrates the behavior? I'm not aware of any bugs in this behavior, but please let us know your version of ZooKeeper too. Thanks! --Chris Nauroth From: kamel zaarouri <[email protected]<mailto:[email protected]>> Date: Saturday, November 7, 2015 at 1:42 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Chris Nauroth <[email protected]<mailto:[email protected]>> Subject: Re: out of order callbacks of events in ZK Hi Chris, I went through the documentation you send me. A guarantee caught my attention: A client will see a watch event for a znode it is watching before seeing the new data that corresponds to that znode. Does it mean that if: parent <--- There's a watcher here to see changed in child |___child <--- There's a watcher here to see changed in grand_child |___grand_child Then if another client updates grand_child and then child, I will see the changes in order? i.e. grand_child callback and then child? Thanks a lot. On Fri, Nov 6, 2015 at 4:56 PM, Chris Nauroth <[email protected]<mailto:[email protected]>> wrote: The same doc I sent earlier describes how the sync API can be used to achieve this level of consistency on a particular path. http://zookeeper.apache.org/doc/r3.4.6/api/org/apache/zookeeper/ZooKeeper.h tml#sync(java.lang.String, org.apache.zookeeper.AsyncCallback.VoidCallback, java.lang.Object) <http://zookeeper.apache.org/doc/r3.4.6/api/org/apache/zookeeper/ZooKeeper. html#sync(java.lang.String,%20org.apache.zookeeper.AsyncCallback.VoidCallba ck,%20java.lang.Object)> However, it's more typical to copy the well-known recipes from the documentation to provide a higher-level construct like distributed lock or barrier. http://zookeeper.apache.org/doc/r3.4.6/recipes.html Sample source code for recipes is available here. https://github.com/apache/zookeeper/tree/release-3.4.6/src/recipes Additionally, you might consider looking at Curator, which provides a higher-level API over the ZooKeeper client. http://curator.apache.org/curator-recipes/ --Chris Nauroth On 11/6/15, 12:50 PM, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> wrote: >Thanks you for your reply. > >In that case is there a standard solution to synchronize different >clients? >If ordered changes to ZK might be seen out of order with certain clients, >then what is the standard way to synchronize clients? > > > >> On Nov 6, 2015, at 3:41 PM, Chris Nauroth >> <[email protected]<mailto:[email protected]>> >>wrote: >> >> Hello Kamel, >> >> The behavior you're seeing is not at odds with ZooKeeper's guarantees. >> For more details, please refer to the ZooKeeper programmer's guide >> statements on consistency guarantees. >> >> >>http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html#ch_zkGua >>ra >> ntees >> >> >> In particularly, note the sidebar describing how ZooKeeper does not >> guarantee simultaneously consistent cross-client views. >> >> --Chris Nauroth >> >> >> >> >>> On 11/6/15, 12:32 PM, "kamel zaarouri" >>> <[email protected]<mailto:[email protected]>> >>>wrote: >>> >>> Hi zk-users, >>> >>> Assume this tree: >>> >>> >>> parent1 >>> | |____Child1 >>> | >>> | >>> parent2 >>> |_____<empty> >>> >>> >>> I have 1 watchers on parent1 and another watcher on parent2. I have >>>those >>> watchers setup to receive updates of the child nodes of both parents. >>> >>> Child1 is a non-ephemeral node. >>> >>> If another client: >>> >>> - Creates an ephemeral node (let's call it ephem2) under parent2 >>> then and only then it >>> - Updates Child1 >>> >>> What I am seeing now is that 20% of the time, I receive the callbacks >>>out >>> of order, i.e. I see the Child1 being updated before ephem2 is seen >>> created. >>> >>> Is this is a bug in the client I am using or does ZK not guarantee >>>order >>> in >>> this way? >>> >>> Thank you!, >> >
