Yes. You should get that event. You should also debug why you are getting disconnected in the first place. This is often a symptom of something really bad that is happening on your client side such as very long GC's. If these are unavoidable, then you need to adjust the timeouts with ZK to reflect reality. Another possibility is that your network connections are dropping or that your application is freezing for a non-GC reason. Any of these problems are something you should address.
Of course, the connection loss event should be handled correctly as well since honest to god disconnects can happen. On Tue, Oct 12, 2010 at 10:57 AM, Avinash Lakshman < avinash.laksh...@gmail.com> wrote: > Would my watcher get invoked on this ConnectionLoss event? If so I am > thinking I will check for KeeperState.Disconnected and reset my state. Is > my > understanding correct? Please advice. > > Thanks > Avinash > > On Tue, Oct 12, 2010 at 10:45 AM, Benjamin Reed <br...@yahoo-inc.com> > wrote: > > > ZooKeeper considers a client dead when it hasn't heard from that client > > during the timeout period. clients make sure to communicate with > ZooKeeper > > at least once in 1/3 the timeout period. if the client doesn't hear from > > ZooKeeper in 2/3 the timeout period, the client will issue a > ConnectionLoss > > event and cause outstanding requests to fail with a ConnectionLoss. > > > > So, if ZooKeeper decides a process is dead, the process will get a > > ConnectionLoss event. Once ZooKeeper decides that a client is dead, if > the > > client reconnects, the client will get a SessionExpired. Once a session > is > > expired, the expired handle will become useless, so no new requests, no > > watches, etc. > > > > The bottom line is if your process gets a process expired, you need to > > treat that process as expired and recover by creating a new zookeeper > handle > > (possibly by restarting the process) and resetup your state. > > > > ben > > > > > > On 10/12/2010 09:54 AM, Avinash Lakshman wrote: > > > >> This is what I have going: > >> > >> I have a bunch of 200 nodes come up and create an ephemeral entry under > a > >> znode names /Membership. When nodes are detected dead the node > associated > >> with the dead node under /Membership is deleted and watch delivered to > the > >> rest of the members. Now there are circumstances a node A is deemed dead > >> while the process is still up and running on A. It is a false detection > >> which I need to probably deal with. How do I deal with this situation? > >> Over > >> time false detections delete all the entries underneath the /Membership > >> znode even though all processes are up and running. > >> > >> So my questions are: > >> Would the watches be pushed out to the node that is falsely deemed dead? > >> If > >> so I can have that process recreate the ephemeral znode underneath > >> /Membership. > >> If a node leaves a watch and then truly crashes. When it comes back up > >> would > >> it get watches it missed during the interim period? In any case how do > >> watches behave in the event of false/true failure detection? > >> > >> Thanks > >> A > >> > > > > >
