zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amirhossein Kiani <amirhki...@gmail.com>
Subject Re: Getting data after the watch
Date Fri, 02 Mar 2012 23:33:25 GMT
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!

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

> I don't think that your test tests what you think it tests.
> 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.
> On Fri, Mar 2, 2012 at 1:58 PM, Amirhossein Kiani <amirhkiani@gmail.com>wrote:
>> 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.
>> I wonder if the way I'm setting the data or getting it is incorrect.
>> Here are the main files in my test:
>> https://gist.github.com/1961660
>> You can run my test by running "mvn test" in the maven project attached.
>> Many thanks for your help!
>> Amir
>> On Mar 2, 2012, at 11:27 AM, Patrick Hunt wrote:
>> On Fri, Mar 2, 2012 at 11:23 AM, Amirhossein Kiani <amirhkiani@gmail.com>
>> wrote:
>> Many thanks Patrick for pointing me to the new documentation. I just found
>> the other one from Google somehow.
>> No problem.
>> 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.
>> 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...
>> 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? :-)
>> Patrick

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