apache/cassandra · error · IllegalStateException
No holder claimed
Error message
No holder claimed
What it means
CompactionStrategyManager partitions a table's SSTables among holders (repaired/unrepaired, transient, pending-repair, and per-directory strategy holders). getHolderIndex(sstable) is an internal lookup that assumes every SSTable belongs to exactly one holder; if none claims it the internal bookkeeping is inconsistent, so an IllegalStateException is thrown. This is an invariant violation, not user error per se.
Source
Thrown at src/java/org/apache/cassandra/db/compaction/CompactionStrategyManager.java:936
/**
* Should only be called holding the readLock
*/
private void handleFlushNotification(Iterable<SSTableReader> added)
{
for (SSTableReader sstable : added)
getHolder(sstable).addSSTable(sstable);
}
private int getHolderIndex(SSTableReader sstable)
{
for (int i = 0; i < holders.size(); i++)
{
if (holders.get(i).managesSSTable(sstable))
return i;
}
throw new IllegalStateException("No holder claimed " + sstable);
}
private AbstractStrategyHolder getHolder(SSTableReader sstable)
{
for (AbstractStrategyHolder holder : holders)
{
if (holder.managesSSTable(sstable))
return holder;
}
throw new IllegalStateException("No holder claimed " + sstable);
}
private AbstractStrategyHolder getHolder(long repairedAt, TimeUUID pendingRepair, boolean isTransient)
{
return getHolder(repairedAt != ActiveRepairService.UNREPAIRED_SSTABLE,
pendingRepair != ActiveRepairService.NO_PENDING_REPAIR,
isTransient);View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Restart the node - holders and disk boundaries are rebuilt on startup, reclassifying orphaned sstables
- Run nodetool relocate / nodetool garbagcollect or trigger a strategy reload (nodetool reloadcompactionstrategy) to resync holder lists
- Check for concurrent disk-boundary changes and ensure compaction operations are not racing a topology/directory change
- If reproducible, file a Cassandra bug with the sstable descriptor and compaction strategy config
Defensive patterns
Strategy: validation
Validate before calling
// before sstable operations, confirm the sstable is managed
List<AbstractStrategyHolder> holders = csm.getHolders();
boolean managed = holders.stream().anyMatch(h -> h.managesSSTable(sstable));
if (!managed) throw new IllegalStateException("sstable not claimed by any holder: " + sstable); Try / catch
try { idx = csm.getHolderIndex(sstable); }
catch (IllegalStateException e) {
logger.error("holder bookkeeping out of sync; restart/reload strategy", e);
cfs.getCompactionStrategyManager().maybeReloadDiskBoundaries();
} Prevention
- Avoid moving sstable files between data directories out-of-band
- Do not run sstable operations concurrently with strategy reloads or relocation
- Keep repair sessions properly finished/released
- Run nodetool reloadcompactionstrategy after changing data directories
When it happens
Trigger: An SSTableReader is passed to getHolderIndex/getHolder (e.g. via compaction task creation, sstable lifecycle operations, or nodetool sstable operations) whose location (directory index, repaired/pending-repair/transient state) does not match any registered holder - typically because disk boundaries or strategy state changed without the sstable being reclassified.
Common situations: Race between disk-boundary relocation/reload and compaction on the same sstable; sstables moved between directories out-of-band; bugs in pending-repair lifecycle (session finished/forgotten while sstable still tagged); running with JBOD and changing data directories.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- No holder claimed isPendingRepair: %s, isPendingRepair %s
- You can't mix repaired and unrepaired data in a compaction
- Could not reference sstables
- Failed to create a key iterator for sstable ${filename}
- Last written key %s >= current key %s, writing into %s
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/b4dbdfe5b428911b.
Report an issue: GitHub.