Hi Weide, Consider upgrading to the 3.4 branch. Also, it is not a problem that two servers are in the leader state, since only one will be able to make progress. To make progress, the leader needs a majority of supporters.
-Flavio On Tuesday, July 15, 2014 3:18 AM, Weide Zhang <[email protected]> wrote: > > >Hi > >We are using zookeeper 3.3.4 in our production cluster with 5 machines with >additional 4 observers for read traffic. We currently observe some weird >behavior when zookeeper relects leader to another server, sometimes, the >old zookeeper seems still in the state of LEADING (even though it >disconnects the other followers) and new leader has been elected. We could >still see the following log message after the server loses leadership. And >it causes observer to continuously connect to the server. The session >timeout for observer is set to 1 hour. (I'm not sure if it's relevant here >though) > >INFO [WorkerReceiver Thread:FastLeaderElection@496] - Notification: 5 >(n.leader), 1988571642783 (n.zxid), 535 (n.round), LEADING (n.state), 5 >(n.sid), LEADING (my state) > >Do you guys know any bugs for zookeeper 3.3.4 that could have this issue or >how shall we debug this issue further ? > > >Thanks a lot, > > >Weide > > >
