apache/cassandra · warning · RuntimeException

Can not replay during shutdown

Error message

Can not replay during shutdown

What it means

RemoteProcessor.fetchLogAndWait wraps an InterruptedException from waiting on the metadata replay future and rethrows it as a RuntimeException with message 'Can not replay during shutdown'. When the JVM/node is shutting down, the thread waiting for EpochAwareDebounce's replay future is interrupted, and rather than silently returning stale metadata, the processor aborts with this error. It means TCM log replay was cancelled because the process is stopping.

Source

Thrown at src/java/org/apache/cassandra/tcm/RemoteProcessor.java:229

    public ClusterMetadata fetchLogAndWait(Epoch waitFor, Retry retryPolicy)
    {
        // Synchonous, non-debounced call if we are waiting for the highest epoch (without knowing/caring what it is).
        // Should be used sparingly.
        if (waitFor == null)
            return fetchLogAndWait(new CandidateIterator(candidates(true), false), log);

        Future<ClusterMetadata> cmFuture = null;
        try
        {
            Supplier<Future<ClusterMetadata>> fetchFunction = () -> fetchLogAndWaitInternal(new CandidateIterator(candidates(true), false),
                                                                                            log);

            cmFuture = EpochAwareDebounce.instance.getAsync(fetchFunction, waitFor);
            return cmFuture.get(retryPolicy.remainingNanos(), TimeUnit.NANOSECONDS);
        }
        catch (InterruptedException e)
        {
            throw new RuntimeException("Can not replay during shutdown", e);
        }
        catch (ExecutionException | TimeoutException e)
        {
            throw new RuntimeException("Could not replay", e);
        }
    }

    public static ClusterMetadata fetchLogAndWait(CandidateIterator candidateIterator, LocalLog log)
    {
        try
        {
            return fetchLogAndWaitInternal(candidateIterator, log).await().get();
        }
        catch (InterruptedException | ExecutionException e)
        {
            throw new RuntimeException(e);
        }
    }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Nothing to fix if intentional shutdown: the error is expected during stop; ensure retries after shutdown are suppressed.
  2. Check shutdown ordering so TCM clients stop before interrupting replay threads.
  3. Retry node startup after a clean shutdown; replay will proceed normally.
  4. If seen outside shutdown, find what is calling Thread.interrupt() on the replay thread (thread pools closed early, cancelled tasks).
Defensive patterns

Strategy: try-catch

Try / catch

try { ClusterMetadata cm = RemoteProcessor.fetchLogAndWait(candidates, log); }
catch (RuntimeException e) {
    if ("Can not replay during shutdown".equals(e.getMessage())) {
        // shutdown in progress: stop retrying, abort catch-up
        return;
    }
    throw e;
}

Prevention

When it happens

Trigger: fetchLogAndWait's cmFuture.get(retryPolicy.remainingNanos(), NANOSECONDS) throws InterruptedException because the waiting thread was interrupted during node shutdown; shutdown hooks interrupt in-flight metadata replay.

Common situations: Nodetool stop / kill during a metadata read; a CMS leadership change or teardown interrupting replay; JVM shutdown while background TCM catch-up is still in flight.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


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