[
https://issues.apache.org/jira/browse/CASSANDRA-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14487678#comment-14487678
]
Sam Tunnicliffe commented on CASSANDRA-9062:
--------------------------------------------
This looks to be a regression caused by CASSANDRA-8793 (git bisect agrees). The
issue is triggered by the fact that the keys in the 2i table are UUIDs. The
RowPosition passed to BigTableReader#getPosition uses a heap buffer, with
default byte order. When keys are then read back from the summary in
IndexSummary#binarySearch the hollow byte buffer has native ordering so the 2
buffers don't compare as expected, which ultimately causes the sstable to be
skipped.
[~benedict] I confirmed that forcing the byte order of the hollow buffer to
BigEndian in IndexSummary#binarySearch fixes this specific case but I'm sure
there must be a better solution, any suggestions?
> Investigate failing collection indexing dtests
> ----------------------------------------------
>
> Key: CASSANDRA-9062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9062
> Project: Cassandra
> Issue Type: Bug
> Components: Tests
> Reporter: Tyler Hobbs
> Assignee: Sam Tunnicliffe
> Fix For: 3.0
>
>
> There are frequent failures with the dtests related to indexing collections
> ({{secondary_indexes_test.py:TestSecondaryIndexesOnCollections}}).
> I tried to look into the reason for failure. The test does seem to be
> correct, because it can occasionally pass. It seems like the failures are
> due to indexing lagging behind the inserts, resulting in a partial set of
> results when the index is queried shortly afterwards (getting ~20k matching
> rows instead of the expected 50k).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
