Github user Randgalt commented on the issue:
https://github.com/apache/curator/pull/262
> -If the connection between client and server is lost a disconnected event
is received essentially immediately.
> -If a heart beat is missed it takes 2/3 of the session timeout.
Thinking more about this... There are three scenarios:
1. The internal ZK client detects a missed heartbeat, closes the connection
and sends `Event.KeeperState.Disconnected` (note: this is done by
ClientCnxn.java in the SendThread class's run() method - the huge catch
handler).
2. The server detects a missed heartbeat and closes the connection which
causes the client to get a closed connection and most likely a
`SocketException` (which is handled in that same catch clause)
3. The connection fails for other reasons (TCP errors, server crashes,
etc.).
Unfortunately, cases 2 and 3 look _exactly the same_ to the client. In case
2, the client should ideally act as if 2/3 of the session have elapsed. In case
3, the client should act as if none of the session has elapsed. Worse still, if
the entire ZK cluster is down, it could conceivably come back up and clients
won't lose their sessions at all because "time" in ZK is based on the leader's
start time (I still think there's value in killing the session on the client
side anyway as clients could be left hanging interminably).
So, even if we can know the client side heartbeat miss (case 1), we have no
way of mitigating cases 2/3. I'm not sure what to do. Maybe leave
`StandardConnectionHandlingPolicy` as is and add a new, optional policy,
`AggressiveConnectionHandlingPolicy` that always assumes connection loss is due
to missed heartbeats? Or, possibly, just do nothing and leave things as they
are?
Thoughts?
---
