[
https://issues.apache.org/jira/browse/CASSANDRA-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler resolved CASSANDRA-6721.
---------------------------------------
Resolution: Not a Problem
Closing this as not a problem, judging by the comments.
> READ-STAGE: IllegalArgumentException when re-reading wide row immediately
> upon creation
> -----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-6721
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6721
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows 7 x64 dual core, 8GB memory, single Cassandra
> node, Java 1.7.0_45
> 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:
> CREATE TABLE IF NOT EXISTS sr (s BIGINT, p INT, l BIGINT, ec TEXT, createDate
> TIMESTAMP, 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$DroppableRunnable.run(StorageProxy.java:1935)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Unknown Source)
> 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$3.compare(AbstractType.java:77)
> at
> org.apache.cassandra.db.marshal.AbstractType$3.compare(AbstractType.java:74)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.compareTo(MergeIterator.java:152)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.compareTo(MergeIterator.java:129)
> 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>(MergeIterator.java:90)
> at org.apache.cassandra.utils.MergeIterator.get(MergeIterator.java:46)
> at
> org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:120)
> at
> org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:80)
> at
> org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:72)
> at
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:297)
> 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.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1396)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1931)
> ... 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:
> java.io.IOError: java.io.IOException: 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 corrupted.
> 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
> CompactionController.java (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
(v6.2#6252)
