[
https://issues.apache.org/jira/browse/RATIS-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Glen Geng updated RATIS-1014:
-----------------------------
Description:
After merge LeaderState::checkLeadership(), some test case become hard to pass
under GitHub CI, such as GroupManagementBaseTest and TestMultiRaftGroup.
Such case need do node restart operation or membership change operation, which
will make leader vulnerable.
The walk around is enlarge election timeout a little bit, e.g., from
[150ms,300ms] to [300ms, 600ms], since larger election timeout will make leader
become more stable.
TODO:
1) do we have better way besides change election timeout ?
2) are there other test cased affected by LeaderState::checkLeadership() ?
was:
After merge LeaderState::checkLeadership(), some test case become hard to pass
under GitHub CI, such as GroupManagementBaseTest and TestMultiRaftGroup.
> checkLeadership() may make some test case become flaky under GitHub CI.
> -----------------------------------------------------------------------
>
> Key: RATIS-1014
> URL: https://issues.apache.org/jira/browse/RATIS-1014
> Project: Ratis
> Issue Type: Test
> Reporter: Glen Geng
> Assignee: Glen Geng
> Priority: Major
>
> After merge LeaderState::checkLeadership(), some test case become hard to
> pass under GitHub CI, such as GroupManagementBaseTest and TestMultiRaftGroup.
> Such case need do node restart operation or membership change operation,
> which will make leader vulnerable.
> The walk around is enlarge election timeout a little bit, e.g., from
> [150ms,300ms] to [300ms, 600ms], since larger election timeout will make
> leader become more stable.
>
> TODO:
> 1) do we have better way besides change election timeout ?
> 2) are there other test cased affected by LeaderState::checkLeadership() ?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)