You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Mike Percy (JIRA)" <ji...@apache.org> on 2016/02/26 13:09:18 UTC
[jira] [Updated] (KUDU-792) Investigate "optimization" where LMP
mismatch is handled in two places
[ https://issues.apache.org/jira/browse/KUDU-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Percy updated KUDU-792:
----------------------------
Parent: KUDU-560
> Investigate "optimization" where LMP mismatch is handled in two places
> ----------------------------------------------------------------------
>
> Key: KUDU-792
> URL: https://issues.apache.org/jira/browse/KUDU-792
> Project: Kudu
> Issue Type: Sub-task
> Components: consensus
> Affects Versions: Private Beta
> Reporter: Todd Lipcon
>
> We have a bit of code when handling the LMP mismatch that says:
> {code}
> // If the terms mismatch we abort down to the index before the leader's preceding,
> // since we know that is the last opid that has a chance of not being overwritten.
> // Aborting preemptively here avoids us reporting a last received index that is
> // possibly higher than the leader's causing an avoidable cache miss on the leader's
> // queue.
> if (term_mismatch) {
> return state_->AbortOpsAfterUnlocked(req.preceding_opid->index() - 1);
> }
> {code}
> The code _looks_ like it's somewhat redundant (since we also abort operations elsewhere on the replica side), and it claims to be an optimization, but if we remove it, a bunch of correctness tests fail. We should understand better why this code is here and at least update the comment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)