Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Scott Carey <scott@richrelevance.com>
To: "zookeeper-user@hadoop.apache.org" <zookeeper-user@hadoop.apache.org>
Date: Fri, 8 May 2009 13:38:15 -0700
Subject: Re: NodeChildrenChanged WatchedEvent
Thread-Topic: NodeChildrenChanged WatchedEvent
Thread-Index: AcnQHCpKSkoORUKWR6a7Igh8shUo8gAAL8Yj
Message-ID: <C629E647.5C62%scott@richrelevance.com>
In-Reply-To: <a94a47380905081331r68e547f7jb3efa32203f7f6c3@mail.gmail.com>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

It won't work, because when you call watchChildren() you don't actually kno=
w
the list of children from the previous getChildren() if the initial watch
fired.

The initial watch may have fired because child X was added, but by the time
you get that message and call your watchChildren(), child Y and Z may have
been added as well, and you won't get events for that.

So, the pattern is to call getChildren() with a watch, save the list, then
when the event fires you call getChildren() again and set a watch, do a dif=
f
of the result with the previous result to calculate what was added or
removed, do your app specific things as a result, and save the new state fo=
r
when the next watch fires.


On 5/8/09 1:31 PM, "Javier Vegas" <javier@beboinc.com> wrote:

> Sorry, what I meant is issuing the new method watchChildren() on the
> parent node (basically the same as getChildren() but returning just a
> boolean instead of a list of children, because I already know the
> paths of the original children and the ones that were added/deleted so
> I dont need the list again). I wasnt thinking (yet) about
> grandchildren, but If I want to watch for them, I will need to do a
> initial getChildren() on the new child that NodeChildrenChanged told
> me about, followed by a watchChildren() after each event. Does this
> make sense?
>=20
> Javier
>=20
> On Fri, May 8, 2009 at 1:23 PM, Patrick Hunt <phunt@apache.org> wrote:
>> Javier, also note that the subsequent getChildren you mention in your
>> original email is usually not entirely superfluous given that you genera=
lly
>> want to watch the parent node for further changes, and a getChildren is
>> required to set that watch.
>>=20
>> Patrick
>>=20
>> Benjamin Reed wrote:
>>>=20
>>> i'm adding a faq on this right now. it's a rather common request.
>>>=20
>>> we could put in the name of the node that is changing. indeed, we did i=
n
>>> the first cut of zookeeper, but then we found that every instance of
>>> programs that used this resulted in bugs, so we removed it.
>>>=20
>>> here is the problem:
>>>=20
>>> you do a getChildren(), an event comes in that "foo" is deleted, and ri=
ght
>>> afterwords "goo" gets deleted, but you aren't going to get that event s=
ince
>>> the previous delete fired and you haven't done another getChildren(). t=
his
>>> almost always results in an error, so much so that we don't even give p=
eople
>>> the rope.
>>>=20
>>> ben
>>>=20
>>> Javier Vegas wrote:
>>>>=20
>>>> Hi, I am starting to implement Zookeeper as an arbiter for a high
>>>> performance client-server service, it is working really well but I
>>>> have a question. When my Watcher receives an event of
>>>> NodeChildrenChanged event, is there any way of getting from the event
>>>> the path for the child that changed? The WatchedEvent javadoc says
>>>> that it "includes exactly what happened" but all I am able to extract
>>>> is a vague "NodeChildrenChanged" type. What I am doing now to figure
>>>> out the path of teh new child is to do a new getChildren and compare
>>>> the new children list with the old children list, but that seems a
>>>> waste of time and bandwith if my node has lots of children and is
>>>> watched by a loot of zookeepers (which will be in prod). If I can
>>>> somehow get the path of the added/deleted child from the
>>>> WatchedEvent, it will make my life easier and my Zookeeper-powered
>>>> system much more simple, robust and scalable. Any suggestions?
>>>>=20
>>>> Thanks,
>>>>=20
>>>> Javier Vegas
>>>>=20
>>>=20
>>=20
>=20