Github user cammckenzie commented on the issue:
My issue is the difference in timing in these events:
-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.
So, we can't reliably do anything with timers because we can't tell the
difference between these two events. In the first case, ideally, we would
inject a LOST event after the negotiated session timeout MS. In the second
case, ideally, we would inject a LOST event after 1/3 of the negotiated session
For a short session timeout the difference is minimal, but for a longer
session timeout, it will be significant. I guess all we can do is the approach
that we already have where the client of the Curator library can decide what %
of the session timeout they want to use before a session timeout is injected. I
would think that in general, connection loss is more likely than missed heart
beats, so maybe we should just leave the default % of session timeout as it is
at 100% as this will be correct for the most likely case.