Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (nike.apache.org: domain of amirhkiani@gmail.com designates
 209.85.160.42 as permitted sender)
Received-SPF: pass (google.com: domain of amirhkiani@gmail.com designates
 10.68.72.138 as permitted sender) client-ip=10.68.72.138;
Subject: Re: Getting data after the watch
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_25A44D5C-61D1-40AD-8206-89A5E4E8BF0A"
From: Amirhossein Kiani <amirhkiani@gmail.com>
In-Reply-To: 
 <CAJwFCa1tC1=TgWyUwBB0ZuO3hn56h=EQVjAMvL65PgJyS26DYQ@mail.gmail.com>
Date: Fri, 2 Mar 2012 15:33:25 -0800
Cc: Patrick Hunt <phunt@apache.org>
Message-Id: <773AC303-A474-473E-B05A-B4288CEC74DE@gmail.com>
References: <B51B153D-6179-44C4-901B-A985C1038386@gmail.com>
 <CANLc_9+0izMWc8sV7TnxwAHA_vq_daXPfjhc6uovq267u86d=g@mail.gmail.com>
 <E2E85F7B-7F69-4080-8393-7FA0CC4773AD@gmail.com>
 <CANLc_9JVxE5ryDF49W8b860R7kcz7QD8w_uoqXhSS2LVL57sMw@mail.gmail.com>
 <9D6A630B-92C0-4D27-A5DA-FA41E32BD5A1@gmail.com>
 <CAJwFCa1tC1=TgWyUwBB0ZuO3hn56h=EQVjAMvL65PgJyS26DYQ@mail.gmail.com>
To: user@zookeeper.apache.org

--Apple-Mail=_25A44D5C-61D1-40AD-8206-89A5E4E8BF0A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Oh.. you are right. The value was skipped because I was getting two of =
some values (newer but not older)
So I should restructure my code to not make decisions that rely on locks =
created based on node data (unless I come up with a way to sync the =
state myself :D) I think I'll implement that by creating a chain of =
children instead.

The statement about getting every value exactly once is not correct =
though, because I do get some values twice (when one is skipped)

Thanks a lot!
Amir

On Mar 2, 2012, at 2:52 PM, Ted Dunning wrote:

> I don't think that your test tests what you think it tests.
>=20
> You won't necessarily get a notification every time a value changes.  =
If a
> value changes and a watch is queued, you won't get another =
notification
> until you get the data and set the new watch.  If another change =
happens
> before you reset the watch, you will get the second changed value, not =
the
> first.  With your test, you will see a skipped value in your table and
> conclude that you saw an old value twice.  The correct inference is =
that
> you saw every value exactly once except the skipped one.
>=20
> On Fri, Mar 2, 2012 at 1:58 PM, Amirhossein Kiani =
<amirhkiani@gmail.com>wrote:
>=20
>> Hmm... I tried testing the idea that if I call the getData() on =
updated
>> node in the watcher's process() method I'll get the updated data.
>> I created a watcher class that keeps track of the values it's =
receiving
>> and in my test I sequentially set 10000 values on the node. I do see =
that
>> some times I'm getting the OLD VALUE.
>>=20
>> I wonder if the way I'm setting the data or getting it is incorrect.
>>=20
>> Here are the main files in my test:
>> https://gist.github.com/1961660
>>=20
>> You can run my test by running "mvn test" in the maven project =
attached.
>>=20
>>=20
>>=20
>> Many thanks for your help!
>> Amir
>>=20
>> On Mar 2, 2012, at 11:27 AM, Patrick Hunt wrote:
>>=20
>> On Fri, Mar 2, 2012 at 11:23 AM, Amirhossein Kiani =
<amirhkiani@gmail.com>
>> wrote:
>>=20
>> Many thanks Patrick for pointing me to the new documentation. I just =
found
>> the other one from Google somehow.
>>=20
>>=20
>>=20
>> No problem.
>>=20
>> So what I think is happening is actually impossible: to do getData() =
on a
>> node and see the OLD data. in other words, I do not need to loop on a
>> getData() to get the actual new data after being notified about the =
data
>> change.
>>=20
>> The reason that I'm saying that is that's the behavior I'm seeing in =
my
>> code, but it might be just a bug on my side...
>>=20
>>=20
>> Sounds like. Keep in mind that there might be multiple changes btw =
the
>> time the notification fires and when your getData runs on the server.
>> Perhaps someone's changing it back? :-)
>>=20
>> Patrick
>>=20
>>=20
>>=20
>>=20


--Apple-Mail=_25A44D5C-61D1-40AD-8206-89A5E4E8BF0A--