[
https://issues.apache.org/jira/browse/CASSANDRA-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130525#comment-15130525
]
Yuki Morishita commented on CASSANDRA-10099:
--------------------------------------------
[~krummas] I don't think granularly controlling lock in
CompactionStrategyManager helps much, and we will have little concurrency issue
as you mentioned.
I noticed that all 3 compaction strategies loop in {{getNextBackgroundTask}} to
eagerly create compaction task while holding lock(synchronized), but I think we
can just give up if we cannot create one is fine. We can try in next round, and
this will release the lock early so we do not block flushing memtable.
WDYT?
> Improve concurrency in CompactionStrategyManager
> ------------------------------------------------
>
> Key: CASSANDRA-10099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10099
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Yuki Morishita
> Assignee: Marcus Eriksson
> Fix For: 2.1.x, 2.2.x, 3.x
>
>
> Continue discussion from CASSANDRA-9882.
> CompactionStrategyManager(WrappingCompactionStrategy for <3.0) tracks SSTable
> changes mainly for separating repaired / unrepaired SSTables (+ LCS manages
> level).
> This is blocking operation, and can lead to block of flush etc. when
> determining next background task takes longer.
> Explore the way to mitigate this concurrency issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
