apache/cassandra · warning

{} Timed out waiting to acquire sstables

Error message

{} Timed out waiting to acquire sstables

What it means

PendingAntiCompaction acquires sstables for an incremental repair by disabling compaction and compaction-blocking the relevant readers. When acquisition keeps failing (e.g. a compaction is concurrently writing those sstables), it retries with a backoff until a total 'delay' elapses; when the deadline passes it logs this warning while continuing the retry loop until the caller-level timeout aborts the session.

Source

Thrown at src/java/org/apache/cassandra/db/repair/PendingAntiCompaction.java:251

            do
            {
                try
                {
                    // Note that anticompactions are not disabled when running this. This is safe since runWithCompactionsDisabled
                    // is synchronized - acquireTuple and predicate can only be run by a single thread (for the given cfs).
                    return acquireSSTables();
                }
                catch (SSTableAcquisitionException e)
                {
                    logger.warn("Session {} failed acquiring sstables: {}, retrying every {}ms for another {}s",
                                sessionID,
                                e.getMessage(),
                                acquireSleepMillis,
                                TimeUnit.SECONDS.convert(delay + start - currentTimeMillis(), TimeUnit.MILLISECONDS));
                    Uninterruptibles.sleepUninterruptibly(acquireSleepMillis, TimeUnit.MILLISECONDS);

                    if (currentTimeMillis() - start > delay)
                        logger.warn("{} Timed out waiting to acquire sstables", sessionID, e);

                }
                catch (Throwable t)
                {
                    logger.error("Got exception disabling compactions for session {}", sessionID, t);
                    throw t;
                }
            } while (currentTimeMillis() - start < delay);
            return null;
        }
    }

    static class AcquisitionCallback implements Function<List<AcquireResult>, Future<List<Void>>>
    {
        private final TimeUUID parentRepairSession;
        private final RangesAtEndpoint tokenRanges;
        private final BooleanSupplier isCancelled;

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Find and stop the concurrent incremental repair sessions that overlap token ranges (nodetool repair_admin list, cancel duplicates) then re-run the repair
2. Reduce compaction activity or wait for compactions to drain and retry the repair
3. Increase the acquisition delay/timeout for repair so sstable acquisition has more time
4. Stagger repair scheduling across nodes sharing ranges to avoid contention

// before repair: check no other incremental repairs hold sstables
ProcessHandle lists = // nodetool repair_admin list
// verify no overlapping sessions and compaction queue is idle:// nodetool compactionstats -- show no active compactions on repaired tables

When it happens

Trigger: call() enters its acquisition retry loop, each attempt throws (typically CompactionInterruptedException from disabling compaction while a compaction is active), and currentTimeMillis() - start exceeds the configured delay without all sstables being acquired.

Common situations: Multiple incremental repair sessions overlapping on nodes that share token ranges; heavy continuous compaction workload that prevents compaction from being stopped within the delay window; very small repair delays configured (compaction_throughput / concurrent_compactors keeping writers busy).

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• (dynamic) e.getMessage() from SSTableAcquisitionException
• Prepare phase for incremental repair session %s was unable t
• No holder claimed isPendingRepair: %s, isPendingRepair %s
• You can't mix repaired and unrepaired data in a compaction
• You can't compact sstables from different pending repair ses

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/681eb184b966230f. Report an issue: GitHub.