Good point, either way it probably needs to be documented, as it would probably be confusing to get a session loss event from Curator and then manage to reconnect to ZK and still find all your sessions ephemeral nodes present.
I presume it's not possible to get a hook into the acknowledgement of an event from ZK? We could use that as the start of the session timeout timer. On Mon, Sep 14, 2015 at 2:39 PM, Jordan Zimmerman < [email protected]> wrote: > Not sure if this is an issue or not. It's better that Curator declares a > session lost a bit later than a bit earlier than ZK. > Actually, I was thinking it would be better if Curator declares lost > before ZK does. The idea is to wait until the last moment to stop locks, > etc. But, users would still want to not have two processes thinking they > own the same lock. I wonder if we need to add a “fudge factor” of some kind > so that Curator fakes the session loss a bit before the negotiated session > timeout elapses. > > > > -JZ > >
