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)