[
https://issues.apache.org/jira/browse/CASSANDRA-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095861#comment-13095861
]
Sylvain Lebresne commented on CASSANDRA-3116:
---------------------------------------------
I think the _raison d'être_ of the lock is because we need to mark all sstables
compacted for them to be removed when dropping, but that cannot be done
correctly if some sstable are being compacted. But couldn't we just "delay" the
compacted marking ? For instance, we could have a 'isDropped' switch in
DataTracker such that when that switch is on the replace() method just remove
the 'replacements' sstables. So the drop keyspace/cf would set the isDropped
flag first, then grab any sstable files that is not being compacted and mark
those right away. It may be a bit tricky to do that atomically but _à priori_
it sounds doable. We'll probably want to add a call to some checkForDropped()
method in case a compaction fails to be sure we don't leave sstables behind in
that case.
Another option may be to just stop the running compactions (CASSANDRA-1740) so
that we can mark everything compacted at once. I may be harder to make that
thread safe though, not sure, and CASSANDRA-1740 is not in yet.
> 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.8.4
> Reporter: Eric Evans
> Fix For: 1.1
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
