cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Brosius (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12220) utest RowIndexEntryTest.testC11206AgainstPreviousArray/Shallow failure
Date Tue, 19 Jul 2016 03:28:20 GMT


Dave Brosius commented on CASSANDRA-12220:

When the test works (new HashMap), CFMetaData.columnMetaData is laid out in memory as

{java.nio.HeapByteBuffer[pos=0 lim=3 cap=3]=val, java.nio.HeapByteBuffer[pos=0 lim=2 cap=2]=pk,
java.nio.HeapByteBuffer[pos=0 lim=2 cap=2]=ck}

When it doesn't work (Maps.newHashMapWithExpectedSize) the order is

java.nio.HeapByteBuffer[pos=0 lim=2 cap=2]=ck,
java.nio.HeapByteBuffer[pos=0 lim=2 cap=2]=pk,
{java.nio.HeapByteBuffer[pos=0 lim=3 cap=3]=val}

given that this is a HashMap the difference is explained naturally by the different allocation

The problem is then, that in TreeCursor.seekTo expects the columns to be visited in alphabetic
order, where you see

if (key == test) cmp = 0; // check object identity first, since we utilise that in some places
and it's very cheap
            else cmp =, key); // order of provision matters for asymmetric
            if (forwards ? cmp >= 0 : cmp <= 0)
                // we've either matched, or excluded the value from being present
                this.cur = cur;
                return cmp == 0;

in this case key (ck) is not test (val), and so jumps to the else, which forwards == true,
and cmp == 1, and thus returns false for seekTo.

This causes stuff to fail.

I can only assume i'm missing something else, because one would think this would be failing
all over the place, and one assumes it's not.

> utest RowIndexEntryTest.testC11206AgainstPreviousArray/Shallow failure
> ----------------------------------------------------------------------
>                 Key: CASSANDRA-12220
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Robert Stupp
> The unit tests {{RowIndexEntryTest.testC11206AgainstPreviousArray}} and {{RowIndexEntryTest.testC11206AgainstPreviousShallow}}
fail after [this single line change|]
as shown in [this build|].
> Reverting that line to {{new HashMap<>()}} fixes the unit test issues - but _does
not_ explain why it fails, since initializing a collection with the expected size should not
change the overall behaviour. There seems to be something else being wrong.
> /cc [~dbrosius]

This message was sent by Atlassian JIRA

View raw message