[
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)
