hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: Watches - is delivery guaranteed?
Date Wed, 12 Aug 2009 16:49:24 GMT
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



Mime
View raw message