zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Missing session state handling in most Leader Election implementations
Date Mon, 14 Nov 2011 15:18:30 GMT
You should be good to go with a very aggressive session timeout.  The lack
of correct handling for disconnects should not hurt you and may actually
help since there may be clients who can access the master who is
partitioned away from the ZK cluster, but not access the newly elected
master.

On Mon, Nov 14, 2011 at 3:25 AM, Jérémie BORDIER
<jeremie.bordier@gmail.com>wrote:

> Ted, can't add much to what you said, totally agree. We already
> planned on having a watchdog on this anyway. Having several master for
> a very short time wouldn't be a problem for us, but this must be an
> ephemeral state. (We use master election to determine a single host
> responsible of generating unique 64 bit IDs with the first 16 bits
> dedicated to an incremental "master id", so when a new master gets
> elected, the whole range changes. Having 2 masters for a few seconds
> wouldn't be an issue as the IDs cannot overlap, but still that's
> something we want to avoid as much as possible).
>

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