cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuki Morishita (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10099) Improve concurrency in CompactionStrategyManager
Date Wed, 03 Feb 2016 15:02:39 GMT

    [ 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)

Mime
View raw message