[ https://issues.apache.org/jira/browse/ZOOKEEPER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stu Hood updated ZOOKEEPER-157: ------------------------------- Attachment: dead-follower.tar.gz This patch definitely resolves the nasty issue I was seeing yesterday that generated the log I attached to #62 (when applied to r701567). One problem I'm still noticing is that whenever I lose a follower, the leader and remaining follower start eating up the entire CPU. I've attached configs and stack traces. Thanks FPJ! > Peer can't find existing leader > ------------------------------- > > Key: ZOOKEEPER-157 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-157 > Project: Zookeeper > Issue Type: Bug > Affects Versions: 3.0.0 > Reporter: Flavio Paiva Junqueira > Assignee: Flavio Paiva Junqueira > Priority: Critical > Attachments: dead-follower.tar.gz, ZOOKEEPER-157.patch > > > In the patch of JIRA 127, I forgot to set the state of a peer when this peer > is looking for a leader and it receives a message from the current leader. In > this patch, I have fixed this problem, and also returned to what we had > previously. With this current patch, when a peer joins and there is already a > leader elected, the joining peer will only recognize the new leader as the > leader once it receives a confirmation from a majority. The alternative is to > set the leader once we receive a message from a peer claiming to be the > leader (what we have on trunk now, although broken because we don't set the > state of the peer), but there could be cases in which a peer believes to be > leader, although it is not the leader any longer, and the joining peer would > select this false leader to be its leader. Eventually, the false leader would > timeout, and both processes would select the correct leader. This small fix > gets rid of such problems, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.