zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kamel zaarouri <kamel.zaaro...@gmail.com>
Subject Re: out of order callbacks of events in ZK
Date Sat, 07 Nov 2015 20:42:00 GMT
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 <cnauroth@hortonworks.com>
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, "kamel.zaarouri@gmail.com"
> <kamel.zaarouri@gmail.com> 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 <cnauroth@hortonworks.com>
> >>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" <kamel.zaarouri@gmail.com>
> >>>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!,
> >>
> >
>
>

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