[jira] [Comment Edited] (CASSANDRA-12220) utest RowIndexEntryTest.testC11206AgainstPreviousArray/Shallow failure

["Dave Brosius (JIRA)" <ji...@apache.org>]

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

Dave Brosius edited comment on CASSANDRA-12220 at 7/19/16 3:31 AM:
-------------------------------------------------------------------

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

{code}
{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}
{code}

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

{code}
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}
{code}

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

The problem is then, that in TreeCursor.seekTo, it 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 = comparator.compare(test, key); // order of provision matters for asymmetric comparators
            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.


was (Author: dbrosius):
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 size.

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 = comparator.compare(test, key); // order of provision matters for asymmetric comparators
            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: https://issues.apache.org/jira/browse/CASSANDRA-12220
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Robert Stupp
>
> The unit tests {{RowIndexEntryTest.testC11206AgainstPreviousArray}} and {{RowIndexEntryTest.testC11206AgainstPreviousShallow}} fail after [this single line change|https://github.com/apache/cassandra/commit/70fd80ae43f3902e651c956b6d4d07cbc203d30a#diff-75146ba408a51071a0b19ffdfbb2bb3cL307] as shown in [this build|http://cassci.datastax.com/view/trunk/job/trunk_testall/1044/].
> 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
(v6.3.4#6332)