-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multiraft: TestRemoveLeader deadlocks in multi cpu #2639
Labels
C-test-failure
Broken test (automatically or manually discovered).
Comments
tamird
added
C-test-failure
Broken test (automatically or manually discovered).
multi-cpu
labels
Sep 23, 2015
Haven't seen in a while, closing. |
Reopening, I'm able to reproduce this locally in multi-cpu:
|
tamird
changed the title
TestRemoveLeader deadlocks in multi cpu
multiraft: TestRemoveLeader deadlocks in multi cpu
Nov 5, 2015
bdarnell
added a commit
to bdarnell/cockroach
that referenced
this issue
Nov 17, 2015
When a proposal is forwarded from a follower to a leader, waitForCallback is incorrect: what matters is whether the *leader* is waiting for a pending config change callback. Instead, we need to repropose from the follower when the leader has completed its pending config change. This is difficult to observe directly but does have a side effect: when a config change is dropped, it is replaced with an empty entry. When we see such an entry, we know we have to re-propose. Since empty entries are also used to signal leader changes, we can remove the re-proposals in maybeSendLeaderEvent. Fixes cockroachdb#2639
bdarnell
added a commit
to bdarnell/cockroach
that referenced
this issue
Nov 17, 2015
When a proposal is forwarded from a follower to a leader, waitForCallback is incorrect: what matters is whether the *leader* is waiting for a pending config change callback. Instead, we need to repropose from the follower when the leader has completed its pending config change. This is difficult to observe directly but does have a side effect: when a config change is dropped, it is replaced with an empty entry. When we see such an entry, we know we have to re-propose. Since empty entries are also used to signal leader changes, we can remove the re-proposals in maybeSendLeaderEvent. Fixes cockroachdb#2639
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
discovered in #1839
https://circleci.com/gh/cockroachdb/cockroach/7882
The text was updated successfully, but these errors were encountered: