You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Blake Eggleston (Jira)" <ji...@apache.org> on 2020/09/15 00:00:19 UTC

[jira] [Commented] (CASSANDRA-14103) Fix potential race during compaction strategy reload

    [ https://issues.apache.org/jira/browse/CASSANDRA-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195759#comment-17195759 ] 

Blake Eggleston commented on CASSANDRA-14103:
---------------------------------------------

This looks like if fixes the issue and looks good for the most part. I had some questions about how we react to sstables that are in the wrong levels for whatever reason. AFAICT, misclassified sstables makes leveled compaction less effective, but it doesn't seem like it has the potential to cause data loss, correctness bugs, or outages. What do you think about logging something scary in LeveledGenerations.maybeVerifyLevels and putting the sstable in the right spot instead of throwing an assertion error? If so, we should also correct misplaced sstables in LeveledGenerations.addAll when we check its level against getLevelIfExists, if not, we should throw an exception there.

Also 2 nits:
* the fields added to CompactionStrategyManager (and the 2 existing ones, supportsEarlyOpen and fanout, should be volatile)
* the comment in LeveledGenerations.addAll should be indented.

> Fix potential race during compaction strategy reload
> ----------------------------------------------------
>
>                 Key: CASSANDRA-14103
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14103
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local/Compaction
>            Reporter: Paulo Motta
>            Assignee: Marcus Eriksson
>            Priority: Urgent
>         Attachments: 3.11-14103-dtest.png, 3.11-14103-testall.png, trunk-14103-dtest.png, trunk-14103-testall.png
>
>
> When the compaction strategies are reloaded after disk boundary changes (CASSANDRA-13948), it's possible that a recently finished SSTable is added twice to the compaction strategy: once when the compaction strategies are reloaded due to the disk boundary change ({{maybeReloadDiskBoundarie}}), and another when the {{CompactionStrategyManager}} is processing the {{SSTableAddedNotification}}.
> This should be quite unlikely because a compaction must finish as soon as the disk boundary changes, and even if it happens most compaction strategies would not be affected by it since they deduplicate sstables internally, but we should protect against such scenario. 
> For more context see [this comment|https://issues.apache.org/jira/browse/CASSANDRA-13948?focusedCommentId=16280448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280448] from Marcus.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org