You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Mirza Aliev (Jira)" <ji...@apache.org> on 2022/05/31 10:42:00 UTC

[jira] [Created] (IGNITE-17064) ItRaftGroupServiceTest#testTransferLeadership is flaky

Mirza Aliev created IGNITE-17064:
------------------------------------

             Summary: ItRaftGroupServiceTest#testTransferLeadership is flaky
                 Key: IGNITE-17064
                 URL: https://issues.apache.org/jira/browse/IGNITE-17064
             Project: Ignite
          Issue Type: Bug
            Reporter: Mirza Aliev


ItRaftGroupServiceTest#testTransferLeadership is flaky.

There is a comment in {{ItRaftGroupServiceTest#testTransferLeadership}} about the situation when EBUSY:Changing the configuration is thrown:

 
{noformat}
                // It's very messy to deal with the case when the |peer| received
                // TimeoutNowRequest and increase the term while somehow another leader
                // which was not replicated with the newest configuration has been
                // elected. If no add_peer with this very |peer| is to be invoked ever
                // after nor this peer is to be killed, this peer will spin in the voting
                // procedure and make the each new leader stepped down when the peer
                // reached vote timeout and it starts to vote (because it will increase
                // the term of the group)
                // To make things simple, refuse the operation and force users to
                // invoke transfer_leadership_to after configuration changing is
                // completed so that the peer's configuration is up-to-date when it
                // receives the TimeOutNowRequest.
{noformat}

The current limitation must be investigated.
Seems like the easies way to fix test is to rewrite test and repeat transfer leadership invocation  


 



--
This message was sent by Atlassian Jira
(v8.20.7#820007)