Avinash Lakshman wrote:
Hi All
Suppose I have a znode, say /Me, and have three nodes A, B and C who have
set watches on this znode. Now suppose some process changes some value on
/Me then watches get delivered to A, B and C. Now if at that instant of time
C were down I could always read the znode on coming back up. However if C
were partitioned away would the watch be delivered in a guaranteed fashion
when the partition heals? Or are watches best effort delivery?
yes, watch delivery is guaranteed. See this section:
http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkWatches
specifically:
"Watches will not be received while disconnected from a server. When a
client reconnects, any previously registered watches will be
reregistered and triggered if needed. In general this all occurs
transparently. There is one case where a watch may be missed: a watch
for the existance of a znode not yet created will be missed if the znode
is created and deleted while disconnected."
so in your case, as long as the C session is re-established before being
expired by the ZK cluster, C will get the notification.
If a znode is changed N times am I going to get N watches delivered one for
each change or could I be in a situation where I could get only a few
watches but the final change will be delivered to me. The reason for this is
that I have a situation where I set a watch on znode /Parent underneath
which many znodes /Parent/Child-i could be added one per process in my
cluster on startup. I need to get all the znodes under /Parent when startup
is complete. Am I guaranteed to get the watch which contains all the
children provided all the processes do successfully put an entry in ZK. Is
this clear? If not I can try to articulate it better.
watches are one-time triggers. so if a change occurs you'll be notified,
once you subsequently re-register the watch you'll be notified of any
further change. so typically you implement this like:
1) getchildren(/foo, watcher) --> returns current children
2) if the watcher is notified then goto 1)
so any time changes occur you will get notified and you can look at the
current list, if it changes in future, you can get the current list
again and watch for subsequent changes... loop forever (or based on your
biz logic) There may be multiple changes occurring to /foo btw running
1), but that's ok - you will always get the current list when things change.
Patrick
