Alexey Serbin has uploaded this change for review. ( http://gerrit.cloudera.org:8080/16106
Change subject: [mini-cluster] fix GetLeaderMasterIndex() ...................................................................... [mini-cluster] fix GetLeaderMasterIndex() Prior to this patch, when running external mini-cluster in BindMode::UNIQUE_LOOPBACK mode, in rare cases masters might be bound to the same port number of different loopback IP addresses. In such cases, GetLeaderMasterIndex() might return incorrect results. I saw a manifestation of such an issue with failure of the MultiMasterIdleConnectionsITest.ClientReacquiresAuthnToken scenario at http://dist-test.cloudera.org/job?job_id=jenkins-slave.1592866280.18987 I think in that run the leader master index was detected as 0 (due to the issue this patch fixes), but in reality the index was 1, so all the attempts to start an election with current leader master didn't change the leadership role, where the leader master output messages like the following for every RunLeaderElectionRequest() call: I0622 22:58:08.909113 20844 raft_consensus.cc:461] T 00000000000000000000000000000000 P d31fb2325643457e8787dc92f8c3a4cf [term 1 LEADER]: Not starting forced leader election -- already a leader src/kudu/integration-tests/auth_token_expire-itest.cc:587: Failure Eventually, the test failed with the message: Expected: (former_leader_master_idx) != (idx), actual: 1 vs 1 Change-Id: I3f445e587fe2152efbb67e4a36d36c760b486dac --- M src/kudu/mini-cluster/external_mini_cluster.cc 1 file changed, 9 insertions(+), 1 deletion(-) git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/06/16106/1 -- To view, visit http://gerrit.cloudera.org:8080/16106 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: newchange Gerrit-Change-Id: I3f445e587fe2152efbb67e4a36d36c760b486dac Gerrit-Change-Number: 16106 Gerrit-PatchSet: 1 Gerrit-Owner: Alexey Serbin <[email protected]>
