cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CASSANDRA-5720) AssertionError in CompactionExecutor
Date Tue, 18 Mar 2014 14:37:43 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jonathan Ellis resolved CASSANDRA-5720.
---------------------------------------

    Resolution: Fixed

As with the other errors from 2-pass compaction, the fix is to upgrade to 2.0.x.

> AssertionError in CompactionExecutor
> ------------------------------------
>
>                 Key: CASSANDRA-5720
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5720
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.5, 1.2.7
>         Environment: 4 nodes
> RF 2
>            Reporter: Eric Falcao
>              Labels: compaction, ttl
>
> Seeing this on all 4 of my nodes during a major compaction.
> {code}
> ERROR [CompactionExecutor:57927] 2013-07-03 13:41:27,591 CassandraDaemon.java (line 175)
Exception in thread Thread[CompactionExecutor:57927,1,RMI Runtime]
> java.lang.AssertionError: originally calculated column size of 443395646 but now it is
443395712
>         at org.apache.cassandra.db.compaction.LazilyCompactedRow.write(LazilyCompactedRow.java:135)
>         at org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:160)
>         at org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:162)
>         at org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)
>         at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>         at org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:58)
>         at org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
>         at org.apache.cassandra.db.compaction.CompactionManager$6.runMayThrow(CompactionManager.java:355)
>         at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>         at java.lang.Thread.run(Thread.java:722)
> {code}
> A little bit about this CF. It stores data with a TTL of up to 30 days. These rows are
wide. We run major compactions to remove expired data. This has been our setup for almost
2 years and this issue only started cropping up after upgrading to 1.2.5 (from 1.1.5)
> I've been running scrub in the meantime to remove expired data. Now, I'm ending up with
lots of similarly sized SSTables that C* is trying constantly to compact. These minor compactions
of the bigger SSTables are failing also.



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

Mime
View raw message