I'd probably lean towards leaving it as is, unless we're going to put some more trickery in there to handle the case where we've reported a session loss event and subsequently found out the session was not lost on reconnection. Not sure how this would be done though.
On Mon, Sep 14, 2015 at 3:24 PM, Jordan Zimmerman < [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. > > 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 > > > > > >
