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: domain of javier@beboinc.com designates
 74.125.46.30 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4A0494A7.9040307@apache.org>
References: <a94a47380905081211i242d92d6kf1517cb410cc0c3f@mail.gmail.com>
	<4A048F93.1000309@yahoo-inc.com> <4A0494A7.9040307@apache.org>
From: Javier Vegas <javier@beboinc.com>
Date: Fri, 8 May 2009 13:31:58 -0700
Message-ID: <a94a47380905081331r68e547f7jb3efa32203f7f6c3@mail.gmail.com>
Subject: Re: NodeChildrenChanged WatchedEvent
To: zookeeper-user@hadoop.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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?

Javier

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 generally
> want to watch the parent node for further changes, and a getChildren is
> required to set that watch.
>
> Patrick
>
> Benjamin Reed wrote:
>>
>> i'm adding a faq on this right now. it's a rather common request.
>>
>> we could put in the name of the node that is changing. indeed, we did in
>> the first cut of zookeeper, but then we found that every instance of
>> programs that used this resulted in bugs, so we removed it.
>>
>> here is the problem:
>>
>> you do a getChildren(), an event comes in that "foo" is deleted, and right
>> afterwords "goo" gets deleted, but you aren't going to get that event since
>> the previous delete fired and you haven't done another getChildren(). this
>> almost always results in an error, so much so that we don't even give people
>> the rope.
>>
>> ben
>>
>> Javier Vegas wrote:
>>>
>>> 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?
>>>
>>> Thanks,
>>>
>>> Javier Vegas
>>>
>>
>