[ https://issues.apache.org/jira/browse/CASSANDRA-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13745602#comment-13745602 ]
Jonathan Ellis edited comment on CASSANDRA-5907 at 8/20/13 11:08 PM: --------------------------------------------------------------------- It looks like the problem then is a race when we are running getCandidatesFor before a parallel compaction has marked its sources compacting. We synchronize getCompactionCandidates (caller of getCandidatesFor) but that is not adequate. (Edit: which would mean that it can indeed happen with any number of candidates, in theory.) was (Author: jbellis): It looks like the problem then is a race when we are running getCandidatesFor before a parallel compaction has marked its sources compacting. We synchronize getCompactionCandidates (caller of getCandidatesFor) but that is not adequate. > Leveled compaction may cause overlap in L1 when L0 compaction get behind > ------------------------------------------------------------------------ > > Key: CASSANDRA-5907 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5907 > Project: Cassandra > Issue Type: Bug > Reporter: Yuki Morishita > Assignee: Yuki Morishita > Priority: Minor > Fix For: 1.2.9 > > > 1.2 makes LCS run parallel, though if L0 compaction get far behind and > concurrent compactions at L0 where each compaction holds maximum number of > SSTable to compact at L0(32), it will likely cause overlap in L1. There will > be ERROR log as follows: > {code} > ERROR [CompactionExecutor:30] 2013-08-19 17:54:29,648 LeveledManifest.java > (line 244) At level 1, SSTableReader(path='xxx-Data.db') > [DecoratedKey(204853724659241194183955214890519, 30303132343830), > DecoratedKey(69227335985728660912035125310473966323, 30393537373332)] > overlaps SSTableReader(path='xxx-Data.db') > [DecoratedKey(217896711032704014921095870827202, 30333635363932), > DecoratedKey(71430242198281555888954138354238066233, 30333035343132)]. This > is caused by a bug in Cassandra 1.1.0 .. 1.1.3. Sending back to L0. If you > have not yet run scrub, you should do so since you may also have rows > out-of-order within an sstable > {code} > We should send back compacted SSTables to L0 when compacting max SSTables at > L0. Also, the above error message is confusing, at version 1.2, we can reduce > to WARNing level without mentioning scrub. > C* 2.0 performs Size-Tiered compaction on L0 when it has max SSTables and > sends back compacted SSTable to L0, so I think we don't need to fix this on > 2.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira