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. True. What should we do? Leave it as is?
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. Even if we could, the important stuff happens on the server so it’s moot. On September 13, 2015 at 11:42:16 PM, Cameron McKenzie ([email protected]) wrote: 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 > >
