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)