cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blake Eggleston (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-13688) Anticompaction race can leak sstables/txn
Date Wed, 12 Jul 2017 21:59:00 GMT


Blake Eggleston updated CASSANDRA-13688:
    Status: Patch Available  (was: Open)

Branch below. This also fixes 2 edge cases I found while diagnosing this and tests them

1. If a promotion/demotion compaction fails, none of the sstables that have had their repairedAt/pendingRepair
value changed prior to the failure were being moved to the correct strategy.
2. Removal of the compaction strategy for a given repair session doesn't check that the strategy
is empty before removing it. If there are sstables still in the strategy, they will be left
in compaction limbo until the node is bounced (or the compaction strategy is reloaded)
3. CompactionTask wasn't validating that repaired/unrepaired/pending repair sstables weren't
being compacted together.


> Anticompaction race can leak sstables/txn
> -----------------------------------------
>                 Key: CASSANDRA-13688
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Blake Eggleston
>            Assignee: Blake Eggleston
>             Fix For: 4.0
> At the top of {{CompactionManager#performAntiCompaction}}, the parent repair session
is loaded, if the session can't be found, a RuntimeException is thrown. This can happen if
a participant is evicted after the IR prepare message is received, but before the anticompaction
starts. This exception is thrown outside of the try/finally block that guards the sstable
and lifecycle transaction, causing them to leak, and preventing the sstables from ever being
removed from View.compacting.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message