You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Tyler Hobbs (JIRA)" <ji...@apache.org> on 2015/03/19 19:55:39 UTC

[jira] [Commented] (CASSANDRA-8993) EffectiveIndexInterval calculation is incorrect

    [ https://issues.apache.org/jira/browse/CASSANDRA-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369903#comment-14369903 ] 

Tyler Hobbs commented on CASSANDRA-8993:
----------------------------------------

I'm okay with the patch to mitigate incorrect calculations, but at the moment I'm at a loss as to where the calculation is going wrong.  We have pretty thorough test coverage around downsampling (especially with the modifications to the test in your patch).  I can only guess that it may be some interaction between downsampling and early opening.  We don't have a way to reproduce yet, correct?  Do you think extending the SSTableRewriterTests with checks on {{getPosition(..., EQ)}} and downsampling of index summaries would yield something?

> EffectiveIndexInterval calculation is incorrect
> -----------------------------------------------
>
>                 Key: CASSANDRA-8993
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8993
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Blocker
>             Fix For: 2.1.4
>
>         Attachments: 8993.txt
>
>
> I'm not familiar enough with the calculation itself to understand why this is happening, but see discussion on CASSANDRA-8851 for the background. I've introduced a test case to look for this during downsampling, but it seems to pass just fine, so it may be an artefact of upgrading.
> The problem was, unfortunately, not manifesting directly because it would simply result in a failed lookup. This was only exposed when early opening used firstKeyBeyond, which does not use the effective interval, and provided the result to getPosition().
> I propose a simple fix that ensures a bug here cannot break correctness. Perhaps [~thobbs] can follow up with an investigation as to how it actually went wrong?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)