zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Camille Fournier <cami...@apache.org>
Subject Re: locking/leader election and dealing with session loss
Date Wed, 15 Jul 2015 18:10:28 GMT
You should not commit suicide unless it goes into SESSION_EXPIRED state.
The quorum won't delete the ephemeral node immediately, it will only delete
it when the session expires. So if your client for whatever reason
disconnects and reconnects before the session expires, it will be fine.


On Wed, Jul 15, 2015 at 1:54 PM, Vikas Mehta <vikasmehta@gmail.com> wrote:

> When using zookeeper for leader election or distributed locking, my
> assumption is that as soon as the lock owner sees session transition to
> 'CONNECTING' state, it should commit suicide to avoid the risk of multiple
> owners. Please correct my assumption if I am wrong or there is a better way
> to guarantee a single lock owner/leader.
> If above assumption is correct, I am trying to figure out how I can improve
> the availability of the application (leader/lock owner) when zookeeper
> ensemble is broken (eg. undergoing zookeeper leader election for prolonged
> period of time). Options I have considered:
> 1/ use multiple ensembles for leader election/locking to avoid SPOF
> (complex
> to implement)
> 2/ extend the zookeeper protocol to provide client more info on connection
> loss, like zookeeper leader election in progress so that client can decide
> when it is ok to not commit suicide and still guarantee a single
> application
> leader/lock owner. (haven't been able to prove that this will guarantee
> single application leader/lock owner).
> If this has been already answered or solved, please point me to the
> post/doc.
> --
> View this message in context:
> http://zookeeper-user.578899.n2.nabble.com/locking-leader-election-and-dealing-with-session-loss-tp7581277.html
> Sent from the zookeeper-user mailing list archive at Nabble.com.

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