cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony Molinaro (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1300) Assert in RandomPartitioner causes unending compaction
Date Mon, 19 Jul 2010 20:25:59 GMT

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

Anthony Molinaro commented on CASSANDRA-1300:
---------------------------------------------

So looking at the other bug it seems like the way to detect a bad sstable is to run sstablekeys
and see if there is an exception thrown?

If so, I did that on the 4 -Data.db files and got no exceptions.  However, it looks like the
-Index.db and -Filter.db files are also sstables, so should I run on each of them?  Also,
I assume its then okay to just delete the bad sstable (ie, if I find a bad -Index.db delete
it, then repair), or do I need to delete all 3 files (ie, if 3-Index.db is bad, do I delete
3-Data.db, 3-Filter.db and 3-Index.db)?

> Assert in RandomPartitioner causes unending compaction
> ------------------------------------------------------
>
>                 Key: CASSANDRA-1300
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1300
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 0.6.3
>            Reporter: Anthony Molinaro
>
> I have a set of 4 sstables which equal about 600GB of data, whenever they are compacted
after about 2 days I get this exception
> ERROR [COMPACTION-POOL:1] 2010-07-17 19:09:49,784 CassandraDaemon.java (line 83) Uncaught
exception in thread Thread[COMPACTION-POOL:1,5,main]                  
> java.util.concurrent.ExecutionException: java.lang.StringIndexOutOfBoundsException: String
index out of range: -1       
>         at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)   
>         at java.util.concurrent.FutureTask.get(FutureTask.java:83)              
>         at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.afterExecute(Debug+gableThreadPoolExecutor.java:86)
                                              
>         at org.apache.cassandra.db.CompactionManager$CompactionExecutor.afterExecute(CompactionManager.java:577)
                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:888)
                                                                          
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)Caused by: java.lang.StringIndexOutOfBoundsException:
String index out of range: -1       
>         at java.lang.String.substring(String.java:1938)                         
>         at org.apache.cassandra.dht.RandomPartitioner.convertFromDiskFormat(RandomPartitioner.java:50)
                                                                  
>         at org.apache.cassandra.io.IteratingRow.<init>(IteratingRow.java:48)  
 
>         at org.apache.cassandra.io.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:136)
                                                                     
>         at org.apache.cassandra.io.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:113)
                                                                     
>         at org.apache.cassandra.io.SSTableScanner.next(SSTableScanner.java:105) 
>         at org.apache.cassandra.io.SSTableScanner.next(SSTableScanner.java:34)  
>         at org.apache.commons.collections.iterators.CollatingIterator.set(CollatingIterator.java:284)
                                                                   
>         at org.apache.commons.collections.iterators.CollatingIterator.least(CollatingIterator.java:326)
                                                                 
>         at org.apache.commons.collections.iterators.CollatingIterator.next(CollatingIterator.java:230)
                                                                  
>         at org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:68)
                                                                            
>         at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:135)
>         at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:130)
 
>         at org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183)
                                                               
>         at org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:94)
                                                                      
>         at org.apache.cassandra.db.CompactionManager.doCompaction(CompactionManager.java:295)
                                                                           
>         at org.apache.cassandra.db.CompactionManager$1.call(CompactionManager.java:102)
  
>         at org.apache.cassandra.db.CompactionManager$1.call(CompactionManager.java:83)
   
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)   
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)             
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
                                                                          
>         ... 2 more  
> After this expection, the compaction starts over and then crashes again.   This led to
several thousand outstanding sstables hanging out waiting to be compacted.
>                                                                              

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message