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

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

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

Benedict edited comment on CASSANDRA-8993 at 3/19/15 7:52 PM:
--------------------------------------------------------------

Early opening doesn't touch the index or index summary contents. I've reproduced the problem on the raw sstable directly with some hacky code to just open the index and summary directly. The sstable is a prior format, so it has never been successfully subjected to early opening or rewriting. You can download the files from CASSANDRA-8851 yourself, and I can provide you with the gpg key.


was (Author: benedict):
Early opening doesn't touch the index or index summary contents. I've reproduced the problem on the raw sstable directly with some hacky code to just open the index and summary directly. The sstable is a prior format, so it has never been successfully subjected to early opening or rewriting. You can download the files from CASSANDRA-8851 yourself, and I can provide you with the gpg key. I suspect the problem is related to the elimination of "indexInterval" from CfMetaData prematurely. It looks like it is needed to establish the actual sampling level - users that have modified this will have the incorrect level set after upgrade until their sstables are rewritten.



> 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)