-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zk-ref watcher called with wrong values #1
Comments
Further experimenting shows sometime the watchers are not called at all. |
This problem was observed with avout 0.5.3 and ZooKeeper client (org.apache.zookeeper/zookeeper) 3.3.6. |
...and the server reports its version as "Server environment:zookeeper.version=3.4.4-1386507, built on 09/17/2012 08:33 GMT" |
According to the ZooKeeper Watches documentation, ZooKeeper guarantees "A client will see a watch event for a znode it is watching before seeing the new data that corresponds to that znode." Furthermore, "Because watches are one time triggers and there is latency between getting the event and sending a new request to get a watch you cannot reliably see every change that happens to a node in ZooKeeper." (emphasis added) Therefore, Avout's implementation of The ZooKeeper documentation leaves some ambiguity as to whether it is possible for a client to see the old value of a node in the callback triggered by a watch. According to Getting data after the watch (ZooKeeper mailing list), a client that calls In Avout, setting the root binding of |
I have created a zk-ref and added two watchers. One is added inline at created of the ref, the other is added subsequently using add-watch.
I then run tests by manually (from the REPL) changing the zk-ref from a remote machine.
Occasionally, I notice both watchers are called with the PREVIOUS state in the new (last) argument. Immediately after this problem, I verify that the distributed ref has the correct value on the same machine where the watcher was invoked incorrectly.
set-to/watcher-called-with/zk-ref-has
1/1/1
2/2/2
3/2/3
The text was updated successfully, but these errors were encountered: