[
https://issues.apache.org/jira/browse/ZOOKEEPER-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16293516#comment-16293516
]
ASF GitHub Bot commented on ZOOKEEPER-2953:
-------------------------------------------
Github user afine closed the pull request at:
https://github.com/apache/zookeeper/pull/433
> Flaky Test: testNoLogBeforeLeaderEstablishment
> ----------------------------------------------
>
> Key: ZOOKEEPER-2953
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2953
> Project: ZooKeeper
> Issue Type: Bug
> Affects Versions: 3.5.3, 3.4.11, 3.6.0
> Reporter: Abraham Fine
> Assignee: Abraham Fine
> Fix For: 3.5.4, 3.6.0, 3.4.12
>
>
> testNoLogBeforeLeaderEstablishment has been flaky on 3.4, 3.5, and master for
> quite awhile. My understanding is that the purpose of the test is to make
> sure that a server receives support from the quorum before changing the epoch
> and acting as leader.
> There are a couple issues with the test in its current state. First, the
> assertions the test makes are not always true. It is possible, if the
> zookeeper database is not cleared, for a follower to be ahead of a leader
> when the quorum is shutdown. That follower will then likely become leader
> when the quorum is restarted. This is the cause of the flaky behavior.
> Second, the test does not appear to create the conditions it wants to test
> for. Since, ZOOKEEPER-335 (specifically the ZOOKEEPER-1081 subtask) we take
> the epoch into consideration in {{FastLeaderElection}} so the test no longer
> "believes it is the leader once it recovers".
> After discussing the issue offline with [~phunt] we decided it would still be
> valuable to test the situation where a server is elected leader without the
> support of the quorum. So I removed {{testNoLogBeforeLeaderEstablishment}}
> and created a new test called {{testElectionFraud}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
