[
https://issues.apache.org/jira/browse/CASSANDRA-13786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16140617#comment-16140617
]
Blake Eggleston commented on CASSANDRA-13786:
---------------------------------------------
[~kohlisankalp] and I were talking about this, and he mentioned that even if
the operator can't do anything to fix, it's still good to know it's happening.
I coded up a more "correct" solution. [This
branch|https://github.com/bdeggleston/cassandra/tree/orphan-sstables2] adjusts
how mutating repairedAt is synchronized, and how getScanners is synchronized.
So that the scenario causing the warning in this case shouldn't be able to
happen.
1. for {{getScanners}}, it moves the organizing of sstables into
unrepaired/pending/repaired into the same read locked block that actually gets
the scanners
2. adds a {{mutateRepaired}} method to {{CompactionStrategyManager}} that is
used to mutate the repaired time and move the sstables between compaction
strategies with a write lock held.
> Validation compactions can cause orphan sstable warnings
> --------------------------------------------------------
>
> Key: CASSANDRA-13786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13786
> Project: Cassandra
> Issue Type: Bug
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Priority: Minor
> Fix For: 4.0
>
>
> I've seen LevelledCompactionStrategy occasionally logging:
> {quote}<sstable_name> from level 0 is not on corresponding level in the
> leveled manifest. This is not a problem per se, but may indicate an orphaned
> sstable due to a failed compaction not cleaned up properly."{quote} warnings
> from a ValidationExecutor thread.
> What's happening here is that a compaction running concurrently with the
> validation is promoting (or demoting) sstables as part of an incremental
> repair, and an sstable has changed hands by the time the validation
> compaction gets around to getting scanners for it. The sstable
> isolation/synchronization done by validation compactions is a lot looser than
> normal compactions, so seeing this happen isn't very surprising. Given that
> it's harmless, and not unexpected, I think it would be best to not log these
> during validation compactions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
