zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@hortonworks.com>
Subject Re: out of order callbacks of events in ZK
Date Sun, 08 Nov 2015 19:22:22 GMT
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 <kamel.zaarouri@gmail.com<mailto:kamel.zaarouri@gmail.com>>
Date: Saturday, November 7, 2015 at 1:42 PM
To: "user@zookeeper.apache.org<mailto:user@zookeeper.apache.org>" <user@zookeeper.apache.org<mailto:user@zookeeper.apache.org>>,
Chris Nauroth <cnauroth@hortonworks.com<mailto:cnauroth@hortonworks.com>>
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

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 <cnauroth@hortonworks.com<mailto:cnauroth@hortonworks.com>>
The same doc I sent earlier describes how the sync API can be used to
achieve this level of consistency on a particular path.

org.apache.zookeeper.AsyncCallback.VoidCallback, java.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


Sample source code for recipes is available here.


Additionally, you might consider looking at Curator, which provides a
higher-level API over the ZooKeeper client.


--Chris Nauroth

On 11/6/15, 12:50 PM, "kamel.zaarouri@gmail.com<mailto:kamel.zaarouri@gmail.com>"
<kamel.zaarouri@gmail.com<mailto:kamel.zaarouri@gmail.com>> wrote:

>Thanks you for your reply.
>In that case is there a standard solution to synchronize different
>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 <cnauroth@hortonworks.com<mailto:cnauroth@hortonworks.com>>
>> 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.
>> 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" <kamel.zaarouri@gmail.com<mailto:kamel.zaarouri@gmail.com>>
>>> Hi zk-users,
>>> Assume this tree:
>>> parent1
>>> |         |____Child1
>>> |
>>> |
>>> parent2
>>>        |_____<empty>
>>> I have 1 watchers on parent1 and another watcher on parent2. I have
>>> 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
>>> 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
>>> in
>>> this way?
>>> Thank you!,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message