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:

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


Reply via email to