cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8993) EffectiveIndexInterval calculation is incorrect
Date Thu, 26 Mar 2015 22:31:53 GMT

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

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

bq. without a setNextSamplePosition(-minIndexInterval) it doesn't pass its test cases (i.e.
initiating the first sample index deterministically to zero caused unit test failures)

I looked into this.  When I simply replaced the {{setNextSamplePosition(-minIndexInterval)}}
call with {{nextSamplePosition = 0}}, I got failures in IndexSummaryManagerTest.  Perhaps
that's what you were seeing?  It looks like the correct replacement for that line is:

{noformat}
nextSamplePosition = 0;
indexIntervalMatches++;
{noformat}

since we implicitly have an index interval match at 0.  With that code, the index summary
related tests pass.

bq.  I wonder if we couldn't get a lot of the benefit of downsampling by sticking to powers
of 2, as it might simplify the code significantly? 

That's true, it would simplify the code, we would just lose granularity in how the index summary
memory pool is distributed.  I wouldn't be opposed to doing that, but I don't think it's a
pressing issue yet.

> 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-2.1-v2.txt, 8993-2.1.txt, 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)

Mime
View raw message