apache/cassandra · warning · RuntimeException
Failed to submit background compaction task
Error message
Failed to submit background compaction task
What it means
When the compaction executor rejects a submitted background compaction task (executor saturated or shutting down), rejectTask calls task.rejected() and then throws this RuntimeException. The exception (including any thrown by rejected()) is recorded via addAsyncError rather than propagating to the caller.
Source
Thrown at src/java/org/apache/cassandra/db/compaction/CompactionManager.java:483
task.execute(active);
}
catch (Throwable t)
{
addAsyncError(t);
}
finally
{
if (toComplete.decrementAndGet() == 0)
complete(true, asyncErrors.get());
}
}
private void rejectTask(AbstractCompactionTask task, AtomicInteger toComplete)
{
try
{
task.rejected();
throw new RuntimeException("Failed to submit background compaction task");
}
catch (Throwable t) // make sure we catch exceptions thrown by task.rejected() as well
{
addAsyncError(t);
}
finally
{
if (toComplete.decrementAndGet() == 0)
complete(false, asyncErrors.get());
}
}
private void complete(boolean submitNew, Throwable error)
{
compactingCF.remove(cfs);
if (error == null)
{
toSignalWhenDone.setSuccess(null);View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Check whether the node is shutting down or autocompaction is disabled (nodetool statusautocompaction); re-enable and let compaction resume.
- Inspect async error logs for the underlying rejection reason and address executor saturation (increase compaction throughput headroom).
- Retry compaction after the node stabilizes; rejected tasks are normally resubmitted later.
Defensive patterns
Strategy: try-catch
Validate before calling
// before triggering compaction programmatically if (storageService.isStarting() || !compactionManager.isEnabled()) skipSubmission();
Try / catch
try { scheduleCompaction(); } catch (RuntimeException e) { if (e.getMessage().equals("Failed to submit background compaction task")) { retryAfterStabilization(); } } Prevention
- Avoid submitting compactions during shutdown/decommission
- Ensure autocompaction is enabled before requesting tasks
- Watch executor backlog metrics to avoid saturation
When it happens
Trigger: Background compaction submission to the executor's queue is rejected — typically because the node is shutting down, the executor was paused/disabled, or the task queue is full.
Common situations: Node shutdown or decommission racing with compaction submission, disabling autocompaction while tasks are in flight, severe executor backlog on overloaded nodes.
Related errors
- ${executor.name} not terminated
- Unable to terminate fast tasks within 1 minute.
- UnsupportedOperationException
- Cannot resize core pool size of SEPExecutor
- Maximum number of workers must not be negative
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/3b8318ebe21cae8d.
Report an issue: GitHub.