Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 19 Mar 2015 20:49:39 +0000 (UTC)
From: "Tyler Hobbs (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12783196.1426764615000.148264.1426798179772@Atlassian.JIRA>
In-Reply-To: <JIRA.12783196.1426764615000@Atlassian.JIRA>
References: <JIRA.12783196.1426764615000@Atlassian.JIRA>
 <JIRA.12783196.1426764615565@arcas>
Subject: [jira] [Commented] (CASSANDRA-8993) EffectiveIndexInterval
 calculation is incorrect
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

bq. I have had another closer look. It seems that we're reading an interval of 128, when in fact it is 2048.

Are you referring to when we deserialize the index summary?  The default {{index_interval}} in 2.0 was 128.  In 2.1, we use the old value of {{index_interval}} for {{min_index_interval}} and set {{max_index_interval}} to 2048.  Unfortunately there was a bug in cqlsh in 2.1, so neither property is shown in the {{DESCRIBE}} output.  I'm assuming you inspected the serialized index summary and saw an (old) interval of 2048?

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