https://github.com/apache/curator/pull/105
On September 14, 2015 at 5:09:28 PM, Cameron McKenzie ([email protected]) wrote: 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 > >
