cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3399) Truncate disregards running compactions when deleting sstables
Date Mon, 31 Oct 2011 16:33:32 GMT

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

Jonathan Ellis commented on CASSANDRA-3399:
-------------------------------------------

created CASSANDRA-3429 and CASSANDRA-3430.
                
> Truncate disregards running compactions when deleting sstables
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-3399
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3399
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.0
>            Reporter: Sylvain Lebresne
>             Fix For: 1.0.2
>
>
> All truncation do is `cfs.markCompacted(truncatedSSTables)` without holding any lock
or anything. Which have the effect of actually deleting sstables that may be compacting. More
precisely there is three problems:
> # It removes those compacting sstables from the current set of active sstables for the
cfs. But when they are done compacting, DataTracker.replaceCompactedSSTables() will be called
and it assumes that the compacted sstable are parts of the current set of active sstables.
In other words, we'll get an exception looking like the one of CASSANDRA-3306.
> # The result of the compaction will be added as a new active sstable (actually no, because
the code will throw an exception before because of the preceding point, but that's something
we should probably deal with).
> # Currently, compaction don't 'acquire references' on SSTR. That's because the code assumes
we won't compact twice the same sstable and that compaction is the only mean to delete an
sstable. With these two assumption, acquiring references is not necessary, but truncate break
that first assumption.
> As for solution, I see two possibilities:
> # make the compaction lock be per-cf instead of global (which I think is easy and a good
idea anyway) and grab the write lock to do the markCompacted call. The big downside is that
truncation will potentially take much longer.
> # had two phases: mark the sstable that are not compacting as compacted and set the dataTracker
as 'truncated at', and let it deal with the other sstable when their compaction is done. A
bit like what is proposed for CASSANDRA-3116 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message