[ https://issues.apache.org/jira/browse/ZOOKEEPER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669568#action_12669568 ]
Hudson commented on ZOOKEEPER-275: ---------------------------------- Integrated in ZooKeeper-trunk #217 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/217/]) > Bug in FastLeaderElection > ------------------------- > > Key: ZOOKEEPER-275 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-275 > Project: Zookeeper > Issue Type: Bug > Components: leaderElection > Affects Versions: 3.0.0, 3.0.1 > Reporter: Flavio Paiva Junqueira > Assignee: Flavio Paiva Junqueira > Fix For: 3.1.0 > > Attachments: ZOOKEEPER-275.patch, ZOOKEEPER-275.patch, > ZOOKEEPER-275.patch, ZOOKEEPER-275.patch > > > I found an execution in which leader election does not make progress. Here is > the problematic scenario: > - We have an ensemble of 3 servers, and we start only 2; > - We let them elect a leader, and then crash the one with lowest id, say S_1 > (call the other S_2); > - We restart the crashed server. > Upon restarting S_1, S_2 has its logical clock more advanced, and S_1 has its > logical clock set to 1. Once S_1 receives a notification from S_2, it notices > that it is in the wrong round and it advances its logical clock to the same > value as S_1. Now, the problem comes exactly in this point because in the > current code S_1 resets its vote to its initial vote (its own id and zxid). > Since S_2 has already notified S_1, it won't do it again, and we are stuck. > The patch I'm submitting fixes this problem by setting the vote of S_1 to the > one received if it satisfies the total order predicate ("received zxid" is > higher or "received zxid is the same and received id is higher"). > Related to this problem, I noticed that by trying to avoid unnecessary > notification duplicates, there could be scenarios in which a server fails > before electing a leader and restarts before leader election succeeds. This > could happen, for example, when there isn't enough servers available and one > available crashes and restarts. I fixed this problem in the attached patch by > allowing a server to send a new batch of notifications if there is at least > one outgoing queue of pending notifications empty. This is ok because we > space out consecutive batches of notifications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.