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 <[email protected]>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 <[email protected]> >> 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 >> >> >> >>
