Thanks so much for the kind words! :-) I agree that ZOOKEEPER-1274 would be a helpful enhancement, so I've volunteered to help. I see you added yourself as a watcher on the issue, so you'll get email updates about any progress.
--Chris Nauroth On 4/29/15, 6:50 AM, "B. Heath Robinson" <[email protected]> wrote: >I love it when people know what they are talking about! I did not expect >the code to be written that way, but it is. Thanks for the help. I guess >I'll have to figure out another solution until ZOOKEEPER-1274 is released. > >On Tue, Apr 28, 2015 at 5:52 PM Chris Nauroth <[email protected]> >wrote: > >> If you're seeing a non-zero zk_watch_count from mntr, but no watch >> information from wchs, wchp and wchc, then it's likely that the client >> applications connecting to the ZooKeeper cluster are implemented to set >> child watches, not data watches. If you have access to the client >> application code, then you can confirm this by looking at the ZooKeeper >> calls. Data watches are set in calls to ZooKeeper#exists or >> ZooKeeper#getData. Child watches are set in calls to >> ZooKeeper#getChildren. >> >> Your original email mentioned that the client watches ephemeral nodes. >> I'm guessing that the client's logic is to set a watch by calling >> getChildren on a parent node, like /parent, into which other processes >> create their ephemeral nodes, like /parent/ephemeral1, >>/parent/ephemeral2, >> etc. If that is the case, then this is a child watch. >> >> The current implementation of mntr counts both data watches and child >> watches towards zk_watch_count. wchs, wchp and wchc are only looking at >> data watches. ZOOKEEPER-1274 tracks the work of changing the ZooKeeper >> code to include child watches in the output of wchs, wchp and wchc. >> Unfortunately, I'm not aware of any other easy way to get this >>information >> for child watches. >> >> --Chris Nauroth >> >> >> >> >> On 4/28/15, 9:39 AM, "B. Heath Robinson" <[email protected]> wrote: >> >> >Thanks. I ran into these, but they don't seem to working as I >>expected. >> >For example: >> > >> >hrobinson@fortress:~$ echo mntr |nc 10.1.0.172 2181 >> >zk_version 3.4.6-1569965, built on 02/20/2014 09:09 GMT >> >zk_avg_latency 0 >> >zk_max_latency 441 >> >zk_min_latency 0 >> >zk_packets_received 28675194 >> >zk_packets_sent 28674836 >> >zk_num_alive_connections 153 >> >zk_outstanding_requests 0 >> >zk_server_state follower >> >zk_znode_count 1580 >> >zk_watch_count 147 >> >zk_ephemerals_count 129 >> >zk_approximate_data_size 274629 >> >zk_open_file_descriptor_count 183 >> >zk_max_file_descriptor_count 4096 >> >hrobinson@fortress:~$ echo wchp|nc 10.1.0.172 2181 >> > >> >hrobinson@fortress:~$ >> > >> >My cluster does have 7 members, and the way I read the docs for wchp, >>it >> >only returns watches on that server, so I did the same wchp for all 7 >> >members, and I get nothing. >> > >> > >> >On Tue, Apr 28, 2015 at 11:17 AM Chris Nauroth >><[email protected]> >> >wrote: >> > >> >> One thing to keep in mind is that the wchs, wchp and wchc commands >> >> currently return information only about data change watches (Watcher >> >> instances passed to ZooKeeper#exists or ZooKeeper#getData). These >> >> commands will not return information about child watches (Watcher >> >> instances passed to ZooKeeper#getChildren). ZOOKEEPER-1274 is an >>open >> >> issue tracking enhancements to these commands to support returning >> >> information about child watches too. >> >> >> >> https://issues.apache.org/jira/browse/ZOOKEEPER-1274 >> >> >> >> >> >> --Chris Nauroth >> >> >> >> >> >> >> >> >> >> On 4/28/15, 8:23 AM, "Sékine Coulibaly" <[email protected]> wrote: >> >> >> >> >The four letters command can be of some help here : >> >> > >> >> >echo "wchp" | nc localhost 2181 >> >> > >> >> >Do you need access from a Java or C API ? >> >> > >> >> >Reference: >> >> > >> >> >> >> >> >>http://zookeeper.apache.org/doc/trunk/zookeeperAdmin.html#The+Four+Letter >> >>+ >> >> >Words >> >> > >> >> > >> >> >2015-04-28 16:45 GMT+02:00 B. Heath Robinson >><[email protected]>: >> >> > >> >> >> I have a system where a client watches ephemeral nodes. I would >>like >> >> >>to be >> >> >> able to know if there are any watches for a node. Is there any >>way >> >>to >> >> >>do >> >> >> this? >> >> >> >> >> >> >> >> >>
