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 22:09:27 GMT
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 <
jordan@jordanzimmerman.com> 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 (
> 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