Github user enixon commented on a diff in the pull request:
https://github.com/apache/zookeeper/pull/546#discussion_r197574036
--- Diff: src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java
---
@@ -2069,4 +2073,9 @@ public QuorumCnxManager createCnxnManager() {
this.quorumCnxnThreadsSize,
this.isQuorumSaslAuthEnabled());
}
+
+ boolean isLeader(long id) {
+ Vote vote = getCurrentVote();
+ return vote != null && id == vote.getId();
--- End diff --
I'd second the request to sidestep the election logic for this method if
possible as it makes the method harder to reason about.
It would be nice if the method implied the server was currently performing
active leader actions and the current way also covers a server preparing for or
nominating itself to be leader (or at least it looks like it). For example,
with this code on a 5 server ensemble with one server dead, if one server
switches its vote midway through an election epoch then you could be displaying
two "leaders" by vote but this is not the same as a two leader splitbrain
scenario.
---
