[ 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