Yeah, that's certainly an option. As long as it's documented why it's there, I think it's not a bad idea.
On Mon, Sep 14, 2015 at 11:53 PM, Jordan Zimmerman < [email protected]> wrote: > Maybe the ConnectionHandlingPolicy could have an optional fudge factor for > checking session timeouts? > > -Jordan > > > > On September 14, 2015 at 12:59:12 AM, Cameron McKenzie ( > [email protected]) wrote: > > 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 >> > >> > >> >> >
