From: Tom Pantelis Date: Sat, 15 Apr 2017 02:00:57 +0000 (-0400) Subject: Fix intermittent failure in ClusterAdminRpcServiceTest.testModuleShardLeaderMovement X-Git-Tag: release/nitrogen~337 X-Git-Url: https://git.opendaylight.org/gerrit/gitweb?p=controller.git;a=commitdiff_plain;h=37238e4339ec7bfbfb0c7e57bf1545543f27a6cf;hp=37238e4339ec7bfbfb0c7e57bf1545543f27a6cf Fix intermittent failure in ClusterAdminRpcServiceTest.testModuleShardLeaderMovement java.lang.AssertionError: Rpc failed with error: RpcError [message=leadership transfer failed, severity=ERROR, errorType=APPLICATION, tag=operation-failed, applicationTag=null, info=null, cause=org.opendaylight.controller.cluster.raft.LeadershipTransferFailedException: Failed to transfer leadership to member-2-shard-cars-config_testModuleShardLeaderMovement. Follower is not ready to become leader] at org.opendaylight.controller.cluster.datastore.admin.ClusterAdminRpcServiceTest.verifySuccessfulRpcResult(ClusterAdminRpcServiceTest.java:461) at org.opendaylight.controller.cluster.datastore.admin.ClusterAdminRpcServiceTest.doMakeShardLeaderLocal(ClusterAdminRpcServiceTest.java:450) at org.opendaylight.controller.cluster.datastore.admin.ClusterAdminRpcServiceTest.testModuleShardLeaderMovement(ClusterAdminRpcServiceTest.java:263) It failed when trying to make member-2 the leader for a couple reasons. One is that member-2 hadn't yet received the MemberUp event for member-3 from akka clustering and thus didn't have its address when it started the election and tried to send RequestVote. The second problem is a result of the first - since member-2 couldn't get a vote from member-3, it needed the vote from member-1, which was in the process of stepping down as leader. When member-1 received the RequestVote with the higher term, it switched to Follower. Therefore member-2 didn't receive any votes for that election term. The request to transfer leadership, which was issued on member-1, then timed out and failed. The wait period for the new leader to be elected is 2 sec. This was chosen b/c originally leadership transfer was only used on shutdown and we don't want to block shutdown for too long. However, when requesting leadership outside of shutdown, we should wait at least one election timeout period (plus some cushion to take into account the variance). This alleviates the time out but it still failed sometimes if member-1 timed out in the Follower state and started a new election before member-2 timed out in Candidate state. member-1 would then win the election and grab leadership back. To alleiviate this, it would be ideal if member-1 replied to the RequestVote from member-2 prior to switching to Follower. Normally when it receives a RaftRPC with a higher term, the Leader is supposed to immediately switch to Follower and not process and reply to the RaftRPC, as per raft. However if it's in the process of transferring leadership it makes sense to process the RequestVote and make every effort to get the requesting node elected. I also fixed a couple issues in the test code, mainly adding waitForMembersUp. Change-Id: Ibb1b00f03065680fe1fd338c3d26161ec6336d5a Signed-off-by: Tom Pantelis ---