curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <>
Subject Re: DEVS PLEASE READ: What is the correct timeout for a session
Date Mon, 14 Sep 2015 04:34:00 GMT
My reading of it is similar to yours I think.

There's a session expiry queue which puts sessions into buckets based on
their expiry time. Whenever an event is received for a given session, the
expiry time gets recalculated, and the session moves to a new bucket in the

Then, the SessionTrackerImpl thread just polls this queue and times out any
session that hasn't had any activity for longer than the negotiated session

So, I guess that Curator could be slightly slower at determining a session
timeout than ZK would be, because ZK is going to begin its timeout check at
the time of the last event received for the session, whereas Curator can
only begin the session timeout check when it sees a disconnected event.
Which is potentially going to be up to a heartbeat interval slower than ZK?

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.

On Mon, Sep 14, 2015 at 8:38 AM, Jordan Zimmerman <> wrote:

> Devs,
> Given that Curator 3.0 will try to accurately track the session, I realize
> I’m a bit confused about when a session actually expires. In the
> implementation I pushed, a timer starts
> when Watcher.Event.KeeperState.Disconnected is seen. Then, if the
> negotiated session timeout elapses, Curator simulates a session expiration.
> However, the timeout is based on the saved time when Disconnected is seen.
> I’ve been searching in the ZK code and it’s hard to tell if that’s correct.
> I’d appreciate a few other eyes on this. The significant class in ZK is
> touchSession() is called periodically and a kind
> of priority queue is used to pull out expiring sessions.
> Thanks!
> -Jordan

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