Details
-
Bug
-
Status: Resolved
-
Low
-
Resolution: Duplicate
-
None
-
None
-
None
-
Low
Description
This can cause repeated compaction failures and buildup if an SSTable opens correctly but fails during iteration. The exception will trigger a writer.abort() in CompactionTask, which in turn will replace suspect tables with clones obtained through cloneWithNewStart(). The latter does not copy suspect status, hence the node no longer knows that reading from this table has failed.
Attachments
Issue Links
- duplicates
-
CASSANDRA-9478 SSTables are not always properly marked suspected
- Resolved