cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Mitchell (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-6721) READ-STAGE: IllegalArgumentException when re-reading wide row immediately upon creation
Date Tue, 18 Feb 2014 22:11:21 GMT


Bill Mitchell updated CASSANDRA-6721:

    Environment: Windows 7 x64 dual core, 8GB memory, single Cassandra node, Java 1.7.0_45
 (was: Windows 7 x64, 8GB memory, single Cassandra node, Java 1.7.0_45)

> READ-STAGE: IllegalArgumentException when re-reading wide row immediately upon creation
> -----------------------------------------------------------------------------------------
>                 Key: CASSANDRA-6721
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Windows 7 x64 dual core, 8GB memory, single Cassandra node, Java
>            Reporter: Bill Mitchell
>         Attachments: 2014-02-15.txt, 2014-02-17-21-05.txt, 2014-02-17-22-05.txt, 2014-02-18-13-45.txt
> In my test case, I am writing a wide row to one table, ordering the columns in reverse
chronogical order, newest to oldest, by insertion time.  A simplified version of the schema:
k BIGINT, properties TEXT, PRIMARY KEY ((s, p, l), createDate, ec) ) WITH CLUSTERING ORDER
BY (createDate DESC) AND compression = {'sstable_compression' : 'LZ4Compressor'} 
> Intermittently, after inserting 1,000,000 or 10,000,000 or more rows, when my test immediately
turns around and tries to read this partition in its entirety, the client times out on the
read and the Cassandra log looks like the following:
> java.lang.RuntimeException: java.lang.IllegalArgumentException
> 	at org.apache.cassandra.service.StorageProxy$
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$ Source)
> 	at Source)
> Caused by: java.lang.IllegalArgumentException
> 	at java.nio.Buffer.limit(Unknown Source)
> 	at org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(
> 	at org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(
> 	at
> 	at
> 	at org.apache.cassandra.db.marshal.AbstractType$
> 	at org.apache.cassandra.db.marshal.AbstractType$
> 	at org.apache.cassandra.utils.MergeIterator$Candidate.compareTo(
> 	at org.apache.cassandra.utils.MergeIterator$Candidate.compareTo(
> 	at java.util.PriorityQueue.siftUpComparable(Unknown Source)
> 	at java.util.PriorityQueue.siftUp(Unknown Source)
> 	at java.util.PriorityQueue.offer(Unknown Source)
> 	at java.util.PriorityQueue.add(Unknown Source)
> 	at org.apache.cassandra.utils.MergeIterator$ManyToOne.<init>(
> 	at org.apache.cassandra.utils.MergeIterator.get(
> 	at org.apache.cassandra.db.filter.QueryFilter.collateColumns(
> 	at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(
> 	at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(
> 	at org.apache.cassandra.db.CollationController.collectAllData(
> 	at org.apache.cassandra.db.CollationController.getTopLevelColumns(
> 	at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(
> 	at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(
> 	at org.apache.cassandra.db.Keyspace.getRow(
> 	at org.apache.cassandra.db.SliceFromReadCommand.getRow(
> 	at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(
> 	at org.apache.cassandra.service.StorageProxy$
> 	... 3 more
> I have seen the same failure whether I use the LZ4Compressor or the SnappyCompressor,
so it is not dependent on the choice of compression. 
> When compression is disabled, the log is similar, differing slightly in the details.
 The exception is then:
> mmap segment underflow; remaining is 10778639
but 876635247 requested
> At least in this case of no compression, although the read test failed when run immediately
after the data was written, running just the read tests again later succeeded.  Which suggests
this is a problem with a cached version of the data, as the underlying file itself is not
> The attached 2014-02-15 and 2014-02-17-21-05 files show the initial failure with LZ4Compressor.
 The 2014-02-17-22-05 file shows the log from the uncompressed test.
> In all of these, the log includes the message 
> (line 192) Compacting large row testdb/sr:5:1:6 (1079784915
bytes) incrementally.  
> This may be coincidental, as it turns out, as I may be seeing the same issue on a table
with narrow rows and a large number of composite primary keys.  See the attached log 2014-02-18-13-45.

This message was sent by Atlassian JIRA

View raw message