The liveness of a session is maintained by heart beats between ZK client
and server, and this heartbeat comes as two forms: the periodic ping, or an
explicit request (e..g getData). So yes, a client sends a getData request
will extend the timeout of the session.
>> In other words, will a client request extend the lifetime of the session
by another session timeout?
I think the session will be extended to some value close to 'another
session' - might not be exact value because ZK group sessions into buckets
for expiration, so a session is not expired precisely as it's configured,
but it should be something close.
>> session timeout is configured to 10 seconds
Please be aware that ZK server has minSessionTimeout and maxSessionTimeout
configuration which could override what you configured at client side - the
final session timeout value is some value between the two (if both values
were not configured explicitly, then default multiples of tick time is
On Thu, Oct 13, 2016 at 10:59 PM, Peng Li <peng.pen...@gmail.com> wrote:
> Hi there,
> Suppose a zookeeper session timeout is configured to 10 seconds. If at time
> t, a client sends a getData() request to the ensemble and succeeds, can I
> assume the client's zookeeper session will be live for the next (10 -
> delta) seconds according to the client's local clock? In other words, will
> a client request extend the lifetime of the session by another session
> The delta will account for clock skew between client and server. In
> practice, the clock skew is bounded and very small (<<10 seconds) in a 10
> seconds interval. Absolute clock skew doesn't matter. Only the clock rate
> skew matters.