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.
>
> 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
>>
>>
>>
>>
|