-
Notifications
You must be signed in to change notification settings - Fork 1k
Add WaitCommitted #640
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
base: main
Are you sure you want to change the base?
Add WaitCommitted #640
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -569,6 +569,7 @@ func (r *Raft) runLeader() { | |
// maintain that there exists at most one uncommitted configuration entry in | ||
// any log, so we have to do proper no-ops here. | ||
noop := &logFuture{log: Log{Type: LogNoop}} | ||
noop.init() | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems that the no-op command issued by the leader at the beginning of a term is not properly initialized (which is probably fine), but it is necessary for the change introduced in this PR. |
||
r.dispatchLogs([]*logFuture{noop}) | ||
|
||
// Sit in the leader loop until we step down | ||
|
@@ -818,6 +819,7 @@ func (r *Raft) leaderLoop() { | |
groupReady = append(groupReady, e) | ||
groupFutures[idx] = commitLog | ||
lastIdxInGroup = idx | ||
close(commitLog.committed) | ||
Comment on lines
821
to
+822
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I went back and forth between a "safer" option with a nil check (similar to the future error channel) and a more direct approach with an unconditional |
||
} | ||
|
||
// Process the group | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, there's an implicit dependency on the
applyCh
buffer size, which is controlled via theBatchApplyCh
andMaxAppendEntries
configuration parameters (defaults to 64, max 1024, ifBatchApplyCh
is set to true). Once the buffer is full,Apply
blocks.I'd like to control the
applyCh
buffer size explicitly (as 1024 is fairly conservative) via a separate option, e.g.,ApplyBufferSize
, which would default toMaxAppendEntries
and must not be less than that. The option could supersede theBatchApplyCh
option.