apache/cassandra · error · IOException

%s

Error message

%s

What it means

Operation.error is the stress operation's standard failure reporter. Depending on settings.errors.ignore it either throws IOException carrying the supplied message, or, when errors are being ignored, only prints the message to stderr if the log level exceeds MINIMAL. Hitting the exception means an operation failed (e.g. query error, write timeout, coordinator error) and the run is configured NOT to ignore errors, so the harness aborts with this IOException whose message names the operation failure.

Source

Thrown at tools/stress/src/org/apache/cassandra/stress/Operation.java:127

                        ? "Data returned was not validated"
                        : "Error executing: " + exceptionMessage));
        }

    }

    public abstract String key();

    protected String getExceptionMessage(Exception e)
    {
        String className = e.getClass().getSimpleName();
        String message = e.getMessage();
        return (message == null) ? "(" + className + ")" : String.format("(%s): %s", className, message);
    }

    protected void error(String message) throws IOException
    {
        if (!settings.errors.ignore)
            throw new IOException(message);
        else if (settings.log.level.compareTo(SettingsLog.Level.MINIMAL) > 0)
            System.err.println(message);
    }

    public void intendedStartNs(long intendedTime)
    {
        timer.intendedTimeNs(intendedTime);
    }
}

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Fix the underlying operation failure reported in the message (timeout, unavailable, schema mismatch).
2. Re-run with --errors ignore (or equivalent settings.errors.ignore=true) if failures should be tolerated and counted.
3. Increase --errors skip-timeout / adjust retries so transient coordinator issues do not abort the run.
4. Catch IOException around the stress run and inspect the message for the wrapped Cassandra exception class.

Example fix

// before
stress write --errors strict ...   // aborts on first op error
// after
stress write --errors ignore ...   // logs and continues

// pre-flight: verify cluster health and schema before stressing
// cqlsh -e "SELECT peer FROM system.peers"; ensure all nodes UP and schema agreed

try {
    op.timeWithRetry(run);
} catch (IOException e) {
    if (settings.errors.ignore) log.warn("op error ignored: {}", e.getMessage());
    else throw e;
}

When it happens

Trigger: A stress operation detects a per-op failure and calls error(message); because settings.errors.ignore is false (default --errors behavior), the IOException propagates up through timeWithRetry and fails the stress run with '(ExceptionClass): message' style text.

Common situations: Cassandra cluster returning write/read failures or timeouts during stress; schema mismatch between the stress profile and the live cluster; running with strict error handling against a partially loaded cluster.

Related errors

• CorruptSSTableException wrapping deserialization failure for
• Could not compact segments: " + toCompact
• JournalReadError(descriptor, file, e)
• Failed to read log entries
• Failed to execute stress action

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