aleung
commented
5 years ago It's by design.
According to ZooKeeper FAQ - How should I handle SESSION_EXPIRED?
Session expiration is managed by the ZooKeeper cluster itself, not by the client. ... At this point the client of the expired session is still disconnected from the cluster, it will not be notified of the session expiration until/unless it is able to re-establish a connection to the cluster. The client will stay in disconnected state until the TCP connection is re-established with the cluster, at which point the watcher of the expired session will receive the "session expired" notification.
Application may listen to disconnected event as well to avoid hang forever.
Hey, really great module.
If a client has connected to a server, and then later on, there is a network partition and the client is unable to reconnect -- no SESSION_EXPIRED event is ever emitted by the client.
From my testing all the client emits is a DISCONNECTED event -- even if the client never reconnects to another server (which means that from the server point of view our session has expired since we couldn't reconnect to it). This is because the only time we emit SESSION_EXPIRED is when we get data from the socket: https://github.com/alexguan/node-zookeeper-client/blob/master/lib/ConnectionManager.js#L432
But if the socket was already closed and no data events will be emitted. In our case when there is a network partition, we'll never emit the SESSION_EXPIRED event. This means that if downstream consumers are only listening for SESSION_EXPIRED, they'll never get it on a network partition and hang forever. Specifically, if I've got a watch set on a znode, I won't get any more watch events or SESSION_EXPIRED events and I'll hang forever.