Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 4 Mar 2014 07:33:21 +0000 (UTC)
From: "Vijay (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12695964.1392819509788.8613.1393918401087@arcas>
In-Reply-To: <JIRA.12695964.1392819509788@arcas>
References: <JIRA.12695964.1392819509788@arcas>
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
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-6733?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
13919091#comment-13919091 ]=20

Vijay commented on CASSANDRA-6733:
----------------------------------

Hi Sylvain, No Problem and would love to do so.

+1

Not sure why we do redundant checks on metadata.isSuper() inside SuperColum=
ns.getComparatorFor()... (Not introduced by this patch though).
Nit: looks like isAfterSliceFinish is not used any more...

> 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=C3=A9e
>            Assignee: Sylvain Lebresne
>             Fix For: 2.0.6
>
>         Attachments: 6733.txt, QaUser_user_view_node1.tgz, QaUser_user_vi=
ew_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=3D0.010000 AND
>   caching=3D'KEYS_ONLY' AND
>   comment=3D'' AND
>   dclocal_read_repair_chance=3D0.000000 AND
>   gc_grace_seconds=3D864000 AND
>   index_interval=3D128 AND
>   read_repair_chance=3D1.000000 AND
>   replicate_on_write=3D'true' AND
>   populate_io_cache_on_flush=3D'false' AND
>   default_time_to_live=3D0 AND
>   speculative_retry=3D'99.0PERCENTILE' AND
>   memtable_flush_period_in_ms=3D0 AND
>   compaction=3D{'class': 'SizeTieredCompactionStrategy'} AND
>   compression=3D{'sstable_compression': 'SnappyCompressor'};
> {noformat}
> With cqlsh, the following query was doing a timeout:
> {noformat}
> select * from user_view where key =3D 3 and column1 =3D 1 and column2 =3D=
 '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.getWithS=
hortLength(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(Abstrac=
tType.java:63)
>         at org.apache.cassandra.db.marshal.AbstractType$1.compare(Abstrac=
tType.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(IndexHelp=
er.java:144)
>         at org.apache.cassandra.db.columniterator.IndexedSliceReader$Inde=
xedBlockFetcher.setNextSlice(IndexedSliceReader.java:262)
>         at org.apache.cassandra.db.columniterator.IndexedSliceReader$Inde=
xedBlockFetcher.<init>(IndexedSliceReader.java:255)
>         at org.apache.cassandra.db.columniterator.IndexedSliceReader.<ini=
t>(IndexedSliceReader.java:91)
>         at org.apache.cassandra.db.columniterator.SSTableSliceIterator.cr=
eateReader(SSTableSliceIterator.java:65)
>         at org.apache.cassandra.db.columniterator.SSTableSliceIterator.<i=
nit>(SSTableSliceIterator.java:42)
>         at org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColu=
mnIterator(SliceQueryFilter.java:167)
>         at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIte=
rator(QueryFilter.java:62)
>         at org.apache.cassandra.db.CollationController.collectAllData(Col=
lationController.java:250)
>         at org.apache.cassandra.db.CollationController.getTopLevelColumns=
(CollationController.java:53)
>         at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(C=
olumnFamilyStore.java:1560)
>         at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(Colu=
mnFamilyStore.java:1379)
>         at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:327)
>         at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromR=
eadCommand.java:65)
>         at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler=
.java:47)
>         at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDelive=
ryTask.java:60)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolEx=
ecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolE=
xecutor.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 doe=
sn't fail anymore and return expected results;
> This happens on our cluster which is used for integration and test purpos=
e, not much activity on it. There are only 2 nodes and the replication fact=
or 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)