Skip to content

Conversation

@dumbbell
Copy link
Collaborator

Before that, we kept the old leader_id value around. If the same leader is elected, the leader_id remained the same: this prevented the pending_commands from being processed in ra_node_proc:follower_leader_change().

In the ra_SUITE:node_recovery() testcase, this caused a deadlock because the synchronous gen_statem:call() in the second ra:send_and_await_consensus() never got a reply.

@dumbbell dumbbell force-pushed the reset-leader_id-when-starting-election branch from ccf7434 to 98caffa Compare October 12, 2017 09:29
Before that, we kept the old `leader_id` value around. If the
same leader is elected, the `leader_id` remained the same:
this prevented the `pending_commands` from being processed in
`ra_node_proc:follower_leader_change()`.

In the `ra_SUITE:node_recovery()` testcase, this caused a deadlock
because the synchronous `gen_statem:call()` in the second
`ra:send_and_await_consensus()` never got a reply.
@dumbbell dumbbell force-pushed the reset-leader_id-when-starting-election branch from 98caffa to 3d43745 Compare October 12, 2017 09:36
@kjnilsson kjnilsson merged commit d807d2e into master Oct 13, 2017
@dumbbell dumbbell deleted the reset-leader_id-when-starting-election branch October 16, 2017 08:29
illotum pushed a commit to illotum/ra that referenced this pull request Sep 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants