cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8993) EffectiveIndexInterval calculation is incorrect
Date Thu, 19 Mar 2015 20:49:39 GMT


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

View raw message