zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Kelly <iv...@apache.org>
Subject Re: locking/leader election and dealing with session loss
Date Thu, 16 Jul 2015 18:49:55 GMT
On Thu, Jul 16, 2015 at 7:57 PM Jordan Zimmerman <jordan@jordanzimmerman.com>

> I think this conversation is converging.
> Summary: there is always an edge case where VM pauses might exceed your
> client heartbeat and cause a client misperception about it’s state for a
> short period of time once the VM unpauses. In practice, a tuned VM that has
> been running within known bounds for a reasonable period will not exhibit
> this behavior. Session timeout must match this known bounds in order to
> have consistent client state.
This is assuming that the conditions won't change, because if they do, the
known bounds go out the window.

Ultimately, if you rely on timeouts you have to evaluate how much risk you
are willing to take with your data and how much work you are willing to do
to mitigate this risk. This risk goes away if the leader cannot update any
state when a new leader appears. For this you need some sort of fencing
mechanism, such as sequence numbers. Personally, I would always go for the
latter option.


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