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

Update comments #357

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update comments #357

wants to merge 1 commit into from

Conversation

hhbti
Copy link
Contributor

@hhbti hhbti commented Apr 5, 2020

I updated some comments (and a little bit code) while reading the library (it was a fun journey.)

I'm new to both rust and raft. Not sure whether this can be useful for others. Let me know if I made anything wrong. :)

src/raw_node.rs Outdated
/// HasReady called when RawNode user need to check if any Ready pending.
/// Checking logic in this method should be consistent with Ready.containsUpdates().
/// Checks if any Ready is pending.
/// This method should be consistent with Ready.containsUpdates().
Copy link
Member

Choose a reason for hiding this comment

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

Just for a hint, containsUpdates() seems not being implemented in this codebase.
It comes from https://github.com/etcd-io/etcd/blob/master/raft/node.go#L106

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm maybe remove this line?

@Fullstop000
Copy link
Member

@BusyJay @hicqu PTAL

src/raft.rs Outdated
@@ -361,6 +361,7 @@ impl<T: Storage> Raft<T> {

/// For testing leader lease
#[doc(hidden)]
#[cfg(test)]
Copy link
Member

Choose a reason for hiding this comment

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

This is not going to work. When running integration tests, test profile is disabled for the crate.

src/raft.rs Outdated Show resolved Hide resolved
// Before pre_vote enable, there may be a recieving candidate with higher term,
// but less log. After update to pre_vote, the cluster may deadlock if
// we drop messages with a lower term.
// Unlike normal election, both sender and receiver of MsgReqPreVote{Resp}
Copy link
Member

Choose a reason for hiding this comment

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

I think the original comment is quite sufficient. The comment in this PR may give a wrong impression that the check is for a rarely happen situation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe just for me but it took me a while to figure out what the deadlock is. :)
Surely the example is misleading a verbose. How about I remote that part?

src/raft.rs Outdated
// the message (it ignores all out of date messages).
// The term in the original message and current local term are the
// same in the case of regular votes, but different for pre-votes.
// When responding to MsgReq{Pre}Vote, we include the term from the
Copy link
Member

Choose a reason for hiding this comment

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

"," is required.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

May I know why? Is these comment semantically parsed? I thought only the comments start with /// are used in docs..

I updated some comments (and trivial code) while reading the library (it was a fun journey.)

I'm new to both rust and raft. Not sure whether this can be useful for others. Let me know if I made anything wrong. :)

Signed-off-by: Haibo Huang <[email protected]>
@hhbti
Copy link
Contributor Author

hhbti commented Apr 13, 2020

Thanks for taking time to read this boring change. 😀

By the way I have two questions about the design:

  1. What's the purpose of local messages? Seems the same functionality can be implemented by a direct invocation of corresponding functions.

  2. If implement this from scratch, an intuitive idea is to make it like a server: it waits for events, creates coroutines / fibers to process, and send out responses. This way request / response code can be well organized together. Timers can be used naturally. So what's wrong with this design?

Some reasons I can think of:
a) Needs to mocks more things to test.
b) Coroutines may introduce some non deterministic.

Is this correct?

Thanks a lot for your time.

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