cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6733) Upgrade of 1.2.11 to 2.0.5 make IllegalArgumentException in Buffer.limit on read of a super column family
Date Tue, 04 Mar 2014 10:23:21 GMT

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

Aleksey Yeschenko commented on CASSANDRA-6733:
----------------------------------------------

bq. I wonder if requiring them to upgrade their sstable is a huge deal, which would let us
get rid of said compatibility code.

Not a huge deal as long as it's limited to super columnfamilies only, since it wouldn't affect
most anyone, relatively. That said, I prefer this to go into both 2.0 and 2.1, now that I
realised that this affects CASSANDRA-6506 as well, which I now have to update (once this is
pushed to 2.1). And not, it's not ugly.

> Upgrade of 1.2.11 to 2.0.5 make IllegalArgumentException in Buffer.limit on read of a
super column family
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6733
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6733
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Nicolas Lalevée
>            Assignee: Sylvain Lebresne
>             Fix For: 2.0.6
>
>         Attachments: 6733.txt, QaUser_user_view_node1.tgz, QaUser_user_view_node2.tgz
>
>
> We have a super column family which was first created with a 1.0.x. Then upgraded to
1.1.x, then to 1.2.11, and now to 2.0.5.
> {noformat}
> cqlsh:QaUser> desc table user_view;
> CREATE TABLE user_view (
>   key bigint,
>   column1 varint,
>   column2 text,
>   value counter,
>   PRIMARY KEY (key, column1, column2)
> ) WITH COMPACT STORAGE AND
>   bloom_filter_fp_chance=0.010000 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.000000 AND
>   gc_grace_seconds=864000 AND
>   index_interval=128 AND
>   read_repair_chance=1.000000 AND
>   replicate_on_write='true' AND
>   populate_io_cache_on_flush='false' AND
>   default_time_to_live=0 AND
>   speculative_retry='99.0PERCENTILE' AND
>   memtable_flush_period_in_ms=0 AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'SnappyCompressor'};
> {noformat}
> With cqlsh, the following query was doing a timeout:
> {noformat}
> select * from user_view where key = 3 and column1 = 1 and column2 = '20130218';
> {noformat}
> In the log of cassandra, we could read:
> {noformat}
> ERROR [ReadStage:1385] 2014-02-19 14:45:19,549 CassandraDaemon.java (line 192) Exception
in thread Thread[ReadStage:1385,5,main]
> java.lang.IllegalArgumentException
>         at java.nio.Buffer.limit(Buffer.java:267)
>         at org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:55)
>         at org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:64)
>         at org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:82)
>         at org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:35)
>         at org.apache.cassandra.db.marshal.AbstractType$1.compare(AbstractType.java:63)
>         at org.apache.cassandra.db.marshal.AbstractType$1.compare(AbstractType.java:60)
>         at java.util.Collections.indexedBinarySearch(Collections.java:377)
>         at java.util.Collections.binarySearch(Collections.java:365)
>         at org.apache.cassandra.io.sstable.IndexHelper.indexFor(IndexHelper.java:144)
>         at org.apache.cassandra.db.columniterator.IndexedSliceReader$IndexedBlockFetcher.setNextSlice(IndexedSliceReader.java:262)
>         at org.apache.cassandra.db.columniterator.IndexedSliceReader$IndexedBlockFetcher.<init>(IndexedSliceReader.java:255)
>         at org.apache.cassandra.db.columniterator.IndexedSliceReader.<init>(IndexedSliceReader.java:91)
>         at org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:65)
>         at org.apache.cassandra.db.columniterator.SSTableSliceIterator.<init>(SSTableSliceIterator.java:42)
>         at org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:167)
>         at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:62)
>         at org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:250)
>         at org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53)
>         at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1560)
>         at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1379)
>         at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:327)
>         at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:65)
>         at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47)
>         at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:724)
> {noformat}
> I tried launching repair on our 2 nodes, nothing improved.
> I tried launching a major compaction on this column family, the query doesn't fail anymore
and return expected results;
> This happens on our cluster which is used for integration and test purpose, not much
activity on it. There are only 2 nodes and the replication factor is at 1. Since it is our
test cluster, I have a quite small (2 x ~500K) snapshot done before the upgrade of the cluster
I could share, if needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message