[jira] [Updated] (RATIS-1014) checkLeadership() may make some test case become flaky under GitHub CI.

["Tsz-wo Sze (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RATIS-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tsz-wo Sze updated RATIS-1014:
------------------------------
        Parent: RATIS-863
    Issue Type: Sub-task  (was: Test)

> 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: Sub-task
>    Affects Versions: 2.0.0
>            Reporter: Glen Geng
>            Assignee: Glen Geng
>            Priority: Major
>         Attachments: image-2020-07-31-12-33-35-755.png, image-2020-07-31-12-34-08-384.png, image-2020-07-31-12-40-11-183.png
>
>
>  
> 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, especially resources is limited.
>  
> [https://github.com/apache/incubator-ratis/runs/927310008?check_suite_focus=true]
> [https://github.com/apache/incubator-ratis/runs/926606136?check_suite_focus=true]
>  
> !image-2020-07-31-12-33-35-755.png!
>  
> !image-2020-07-31-12-34-08-384.png!
>  
> !image-2020-07-31-12-40-11-183.png!
> Current walk around is to enlarge election timeout a little bit, e.g., from [150ms,300ms] to [300ms, 600ms], because larger election timeout will make leader become more stable.
>  
> TODO:
> 1) do we have better way besides changing election timeout ?
> 2) are there other test cases affected by LeaderState::checkLeadership() ?
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)