Alexey Serbin has posted comments on this change. Change subject: KUDU-2149: avoid election stacking by restoring failure monitor semantics ......................................................................
Patch Set 3: (1 comment) http://gerrit.cloudera.org:8080/#/c/8107/3/src/kudu/consensus/raft_consensus.h File src/kudu/consensus/raft_consensus.h: PS3, Line 786: Note: the lock is only ever acquired via try_lock(); if it cannot be : // acquired, an election must be in progress so the next one is skipped. I'm not sure I understand this. As I could see, LeaderElection::Run() requests consensus votes asynchronously, so even if RaftConsensus::StartElection() returns, that doesn't mean election is complete. Could you please clarify on this? -- To view, visit http://gerrit.cloudera.org:8080/8107 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ifeaf99ce57f7d5cd01a6c786c178567a98438ced Gerrit-PatchSet: 3 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Mike Percy <mpe...@apache.org> Gerrit-Reviewer: Tidy Bot Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-HasComments: Yes
