ZooKeeper only tells you about states that it is sure about, so you will
not get the Expired event until you reconnect to ZooKeeper. if you never
connect again to ZooKeeper, you will not get the Expired event. if you
want to timeout using some sanity value, 2 times the session timeout for
example, you can implement that yourself by setting a timer when you get
the disconnected event and then close the session explicitly when the
timer goes off.
there is a caveat in doing this: if your whole cluster goes down for 20
mins and then comes back up, your session timeout will get reset and the
session will still be alive even though you have closed it. it will then
have to timeout before it actually goes away. closing the session when
the client is disconnected just stops the client from trying to reconnect.
does this make sense?
Jean-Daniel Cryans wrote:
Working on integrating HBase with ZK, we came around an issue that we
are unable to resolve. I was trying to see how was our handling of
network partitions and session expirations and what I did is just
starting a single ZK instance with a very simple HBase setup, then I
killed the ZK server. The only thing I got from Zookeeper was a
KeeperState.Disconnected then... nothing (for like 20+ minutes).
Normally if I had a quorum I would still get that message but then I
would get another one telling me it's connected to another ZK quorum
server. So how do I know if I'm really partitioned from the ZK quroum?
Shouldn't we get a session expired at some point? From what I
understand you can only get a KeeperState.Expired when you connect
back to the quorum after x time, but what if you can "never" connect
back to it?