Skip to content
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

Replace inflight tracker with commitment tracker (retargeted) #102

Merged
merged 9 commits into from
Mar 21, 2016

Conversation

ongardie
Copy link
Contributor

Retargeted #87 onto the issue-84-integration branch. The original commit (259e54d) is the same as before, only rebased. The subsequent commits address the comments from PR #87. This should probably be squashed into one commit when merging.

The only comment I didn't take from #87 was @armon's about switching to an RWMutex. (I don't plan to do that unless you insist.)

inflight.go used to have two jobs: it buffered log futures until they were
committed, and it marked new log entries committed. This second job is what
commitment.go does, while raft.go now tracks its own uncommitted log futures.

Inflight used to track the replication factor of each log future/entry
independently. It kept a count of how many servers stored that entry, and how
many were needed to mark it committed. The primary issue is that a simple count
of how many servers store an entry is fragile with respect to membership changes,
where the identity of the voting servers might change over time. It was also a
fair amount of bookkeeping to track this information per entry.

The new 'commitment' module instead tracks the match index for each server: the
last entry that the server has on disk that agrees with this leader. This has
several advantages:
 - No information is kept per log entry.
 - Only the latest known membership configuration is used to mark entries
   committed, as described in the Raft paper/dissertation.
 - Servers that aren't voters are simply ignored for the purpose of commitment.
   This is useful for leaders that remove themselves today but would also be
   useful for more general non-voting members in the future.

Because no information is kept per log entry, the log futures can now be state
kept local to the leader goroutine, without any need for locking. This
simplified the interface to commitment.go (relative to inflight.go)
significantly, while only adding a few lines here and there to raft.go.
r.leaderState.inflight = newInflight(r.leaderState.commitCh)
r.leaderState.commitment = newCommitment(r.leaderState.commitCh,
append([]string{r.localAddr}, r.peers...),
/* first index that may be committed in this term: */ r.getLastIndex()+1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add the comment as trailing instead of leading?

@armon
Copy link
Member

armon commented Mar 21, 2016

Minor nit, but LGTM

@ongardie
Copy link
Contributor Author

Updated based on @armon's comment.

And mentioning #84.

@slackpad
Copy link
Contributor

Looks good!

slackpad added a commit that referenced this pull request Mar 21, 2016
Replace inflight tracker with commitment tracker (retargeted)
@slackpad slackpad merged commit ee1f21c into hashicorp:issue-84-integration Mar 21, 2016
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