[
https://issues.apache.org/jira/browse/CASSANDRA-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13130688#comment-13130688
]
Sylvain Lebresne commented on CASSANDRA-3116:
---------------------------------------------
Not sure this work correctly. I believe we first have a problem with
DT.removeAllSSTables(), because this is during the drop and really do remove
*all* sstables, including the ones that are being compacted (and thus it will
unreference those while they are being compacted, which is bad). So we should
first change that to only remove the one that are not compacting. Then we must
make sure that anything that was not removed by that gets removed later. Which
involves removing any flushed memtable (though that doesn't really matter since
a dropped CF is flushed before being invalidated) and we must make sure that
compacted sstable do are marked compacted but also that replacements are
directly marked as compacted too (which mainly involve that we call
removeOldSSTablesSize() on them). And I suppose we could make sure no new
compaction is automatically triggered on an invalidated CF so we don't have a
race or something.
bq. compactionLock is still used but only for major compaction. should we get
rid of that too and say "if you want to be absolutely sure you're compacting
everything, disable minor compactions before invoking major?"
I think there is really no much cost to keeping the lock in there if the write
lock is only acquired by events triggered by a user and I would prefer having
major compaction do what it pretend by default rather that having a
"complicated" procedure. That being said, I would be for replacing the global
compactionLock by one lock per CF (which should be easy).
> Compactions can (seriously) delay schema migrations
> ---------------------------------------------------
>
> Key: CASSANDRA-3116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3116
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0
> Reporter: Eric Evans
> Assignee: Jonathan Ellis
> Labels: compaction
> Fix For: 1.1
>
> Attachments: 3116.txt
>
>
> A compaction lock is acquired when dropping keyspaces or column families
> which will cause the schema migration to block if a compaction is in progress.
--
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
