curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: DEVS PLEASE READ: What is the correct timeout for a session
Date Mon, 14 Sep 2015 05:59:12 GMT
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