Xushaohong opened a new pull request #560:
URL: https://github.com/apache/ratis/pull/560
## What changes were proposed in this pull request?
Candidate shall not start leader election in these cases in case of possible
NPE caused by conf.getPeer().getPriority().
With this patch, the candidate will become a follower again when receiving
the future appendEntries request.
Phenomenon:
The bootstrapped follower becomes the leader after the election timeout
somehow, with an empty raft conf. Then in the process of
yieldLeaderToHigherPriorityPeer, NPE happens as (null).getPriority().
Setconfiguration action takes place at the end of appendEntriesAsync. If we
make it possible to raise electiontimeout before this action, we can replay the
NPE case.
```
1private void yieldLeaderToHigherPriorityPeer() {
2 if (!server.getInfo().isLeader()) {
3 return;
4 }
5 final RaftConfigurationImpl conf = server.getRaftConf();
6 int leaderPriority = conf.getPeer(server.getId()).getPriority();
```
Possible reason:
Network delay/loss? The leader did not send entries in time or the follower
did not receive entries.
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/RATIS-1446
## How was this patch tested?
Manual simulation in UT.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
