[
https://issues.apache.org/jira/browse/CASSANDRA-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14388695#comment-14388695
]
Yuki Morishita commented on CASSANDRA-9070:
-------------------------------------------
I think there is still a chance that {{ColumnFamilyStore#markAllCompacting()}}
can throw AE after this patch.
If {{CompactionTask}} is already queued with 'marked' SSTables, those SSTables
are not unmarked until the task actually runs.
If we really want to cancel all the things, we need to cancel all the task in
the queue and release resources associated with.
> Race in cancelling compactions
> ------------------------------
>
> Key: CASSANDRA-9070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9070
> Project: Cassandra
> Issue Type: Bug
> Reporter: Marcus Eriksson
> Assignee: Marcus Eriksson
> Fix For: 2.0.14
>
> Attachments:
> 0001-check-if-we-are-paused-before-starting-compaction.patch
>
>
> seems we might have a race situation when cancelling compactions
> currently we do the following to ensure that we don't start any new
> compactions when we try to do markAllCompacting()
> # pause compactions - this makes sure we don't create any new compaction
> tasks from the compaction strategies
> # cancel any ongoing compactions - compactions register themselves with the
> CompactionMetrics and then, when cancelling we get all compactions here, and
> tell them to stop
> Problem is that there is a window between when the CompactionTask is created
> and when it is registered in CompactionMetrics meaning with a bit of bad
> luck, we could have a situation like this:
> # we finish a compaction and create a new CompactionTask from the compaction
> strategy
> # we pause the compaction strategies to not create any new CompactionTasks
> # we cancel all ongoing compactions
> # The CompactionTask created in #1 above registers itself in
> CompactionMetrics and misses that it should be cancelled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
