curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: DEVS PLEASE READ: What is the correct timeout for a session
Date Mon, 14 Sep 2015 13:53:25 GMT
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 (mckenzie.cam@gmail.com) 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 <jordan@jordanzimmerman.com> 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 (mckenzie.cam@gmail.com) 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 <
jordan@jordanzimmerman.com> 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
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message