[
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: [email protected]
For additional commands, e-mail: [email protected]
