Todd Lipcon has posted comments on this change.

Change subject: KUDU-1469. Fix handling of fully-deduped requests after a 
leader change
......................................................................


Patch Set 4:

(1 comment)

http://gerrit.cloudera.org:8080/#/c/3228/4/src/kudu/consensus/raft_consensus_state.cc
File src/kudu/consensus/raft_consensus_state.cc:

Line 653:   last_received_op_id_current_leader_ = last_received_op_id_;
> Err. Is that something that would not be hard to fix? It seems like missing
Looked at this for a while, and I think it wasn't causing an issue because on 
any term change, if the new leader's first operation causes us to truncate our 
log, we've already reset the last_received_op_id_ down to that truncation 
point. And if it didn't cause us to truncate our log (i.e it's ahead), then 
sending back our own last_received would cause the leader to re-send the next 
batch at that same index, which would cause the truncation/reset on the next 
round trip. So, either one is actually correct. I can't think of a scenario 
that would break in either case, at least (this one might be more conservative, 
though)


-- 
To view, visit http://gerrit.cloudera.org:8080/3228
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Iced21ae1b69c1079efc9aa9cf23e2fa592b8bebd
Gerrit-PatchSet: 4
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Todd Lipcon <t...@apache.org>
Gerrit-Reviewer: David Ribeiro Alves <dral...@apache.org>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Mike Percy <mpe...@apache.org>
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>
Gerrit-HasComments: Yes

Reply via email to