What's the impact of ZOOKEEPER-961? If it shows up, does that mean the client won't get any watcher events afterwards? If so, this sounds like a blocker for 3.4 release to me. What's the temporary solution for 3.3.3?
Also, for the very first time that the ZK client gets disconnected, I saw the following entry in the log. It seems that the client can't ping the server for 4 seconds. The ZK server was up at that time and the load was minimal. What could cause the time out? Client GC pauses? 2011/08/26 10:58:22.306 INFO [ClientCnxn] [main-SendThread(esv4-app27.stg:12913)] [kafka] Client session timed out, have not heard from server in 4001ms for sessionid 0x131f ddd84bc0006, closing socket connection and attempting reconnect Thanks, Jun On Mon, Aug 29, 2011 at 7:54 AM, Thomas Koch <[email protected]> wrote: > Fournier, Camille F.: > > Did anyone ever check resetting watches at client reconnect on a client > > with a chroot? Looking at the code, we store the watches associated with > > the non-chroot path, but they are set by the original request prepending > > chroot to the request. However, it looks like the SetWatches request on > > reconnect just calls get on the various watch lists from ZooKeeper, which > > don't have the prepended chroot. > > > > I haven't written a test but I would bet dollars to donuts this is the > > problem. > > > > C > seems to be this: > ZOOKEEPER-961, ZOOKEEPER-1091 > > Regards, > > Thomas Koch, http://www.koch.ro >
