What causes "Failed to execute warmup" in apache/cassandra?

Fix the root cause shown in the warmup thread output (create schema, correct nodes, credentials).

apache/cassandra · error · RuntimeException

Failed to execute warmup

Error message

Failed to execute warmup

What it means

StressAction.warmup runs a short measurement pass (up to ~50k iterations, no timing recorded) to JIT-warm all cluster nodes before the real run. It requires the warmup pass to succeed (success flag from run(...)); if it does not, it throws RuntimeException('Failed to execute warmup'). Since warmup exercises the same operations as the real run, failure almost always predicts the main run would fail too, so the tool fails fast.

Source

Thrown at tools/stress/src/org/apache/cassandra/stress/StressAction.java:129

                          ? Math.min(50000, (int)(settings.command.count * 0.25))
                          : 50000) * settings.node.nodes.size();
        if (iterations <= 0) return;

        int threads = 100;

        if (settings.rate.maxThreads > 0)
            threads = Math.min(threads, settings.rate.maxThreads);
        if (settings.rate.threadCount > 0)
            threads = Math.min(threads, settings.rate.threadCount);

        for (OpDistributionFactory single : operations.each())
        {
            // we need to warm up all the nodes in the cluster ideally, but we may not be the only stress instance;
            // so warm up all the nodes we're speaking to only.
            output.println(String.format("Warming up %s with %d iterations...", single.desc(), iterations));
            boolean success = null != run(single, threads, iterations, 0, null, null, ResultLogger.NOOP, true);
            if (!success)
                throw new RuntimeException("Failed to execute warmup");
        }

    }

    // TODO : permit varying more than just thread count
    // TODO : vary thread count based on percentage improvement of previous increment, not by fixed amounts
    private boolean runMulti(boolean auto, UniformRateLimiter rateLimiter)
    {
        if (settings.command.targetUncertainty >= 0)
            output.println("WARNING: uncertainty mode (err<) results in uneven workload between thread runs, so should be used for high level analysis only");
        int prevThreadCount = -1;
        int threadCount = settings.rate.minThreads;
        List<StressMetrics> results = new ArrayList<>();
        List<String> runIds = new ArrayList<>();
        do
        {
            output.println("");
            output.println(String.format("Running with %d threadCount", threadCount));

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Fix the root cause shown in the warmup thread output (create schema, correct nodes, credentials).
Disable or shorten warmup (e.g. -n with no warmup flag depending on profile) to proceed directly to measurement.
Verify connectivity with cqlsh to the same nodes before re-running stress.
Catch RuntimeException and fall back to running without warmup when the cluster is known-good.

Example fix

// before
stress write -n 1000000 ...            // warmup fails on missing schema
// after
cqlsh -e "CREATE TABLE IF NOT EXISTS ..." && stress write -n 1000000 ...

Defensive patterns

Strategy: try-catch

Validate before calling

// pre-flight before warmup:
// verify connectivity: cqlsh -e "DESCRIBE KEYSPACE ks" and check all -node hosts reachable on 9042

Try / catch

try {
    stressAction.run();
} catch (RuntimeException e) {
    if (e.getMessage() != null && e.getMessage().contains("warmup")) {
        log.warn("Warmup failed; retrying without warmup", e);
        runWithoutWarmup();
    } else throw e;
}

Prevention

Create the schema before running stress so warmup statements succeed.
Verify node reachability and auth credentials before launching stress.
Reduce warmup iterations on small clusters to limit exposure to transient errors.

When it happens

Trigger: Running stress with warmup enabled (default for most profiles) while any operation in the warmup pass fails — bad schema, unreachable nodes, wrong credentials — so run(single, threads, iterations, 0, null, null, NOOP, true) returns null and the RuntimeException is thrown.

Common situations: Fresh cluster without the schema created yet; wrong host/port in -node settings; authentication enabled but no credentials supplied; warmup against a keyspace that does not exist.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors

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