What causes "Failed to update speculative retry thresholds." in apache/cassandra?

Run nodetool describecluster / check schema agreement to resolve any schema disagreement before restarting

Failed to update speculative retry thresholds.

Error message

Failed to update speculative retry thresholds.

What it means

A warning logged in the CassandraDaemon static initializer when refreshing speculative-retry thresholds for all existing column families throws. The table properties that drive speculative retry could not be re-applied (typically during dynamic schema/property updates), and JVMStabilityInspector decides whether it is fatal.

Solutions

Run nodetool describecluster / check schema agreement to resolve any schema disagreement before restarting
Validate every table's speculative_retry value (ALTER TABLE ... WITH speculative_retry = '99PERCENTILE' or 'NONE') and fix invalid values
Inspect the chained Throwable in the log for the root cause; if JVMStabilityInspector marked it fatal, fix that root cause and restart

Example fix

// before
ALTER TABLE ks.tbl WITH speculative_retry = '95percentile';
// after
ALTER TABLE ks.tbl WITH speculative_retry = '95PERCENTILE';

Defensive patterns

Strategy: try-catch

Validate before calling

// verify schema agreement before restart
nodetool describecluster | grep -i 'schema versions'
// one version = safe; multiple = resolve disagreement first

Try / catch

try {
    Keyspace.allExisting().forEach(k -> k.getColumnFamilyStores().forEach(ColumnFamilyStore::updateSpeculationThreshold));
} catch (Throwable t) {
    logger.warn("Failed to update speculative retry thresholds.", t);
    JVMStabilityInspector.inspectThrowable(t);
}

Prevention

Keep speculative_retry values to documented forms (NONE, Xms, XPERCENTILE)
Resolve schema disagreement before rolling restarts
Avoid DROP/ALTER on tables during node startup

When it happens

Trigger: The runnable wrapping Keyspace.allExisting() -> ColumnFamilyStore.updateSpeculationThreshold throws (e.g. schema disagreement, a table being dropped concurrently, or an invalid speculative_retry value being parsed) while the daemon class initializes or thresholds are updated.

Common situations: Concurrent DDL (ALTER/DROP TABLE) racing with daemon startup or threshold refresh; a table schema with an unparseable speculative_retry value from an older version; schema version mismatch across the ring.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

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

Appendix: source

Thrown at src/java/org/apache/cassandra/service/CassandraDaemon.java:215

            jmxServer = JMXServerUtils.createJMXServer(jmxServerOptions);
        }
        catch (IOException e)
        {
            exitOrFail(1, e.getMessage(), e.getCause());
        }
    }

    @VisibleForTesting
    public static Runnable SPECULATION_THRESHOLD_UPDATER =
        () ->
        {
            try
            {
                Keyspace.allExisting().forEach(k -> k.getColumnFamilyStores().forEach(ColumnFamilyStore::updateSpeculationThreshold));
            }
            catch (Throwable t)
            {
                logger.warn("Failed to update speculative retry thresholds.", t);
                JVMStabilityInspector.inspectThrowable(t);
            }
        };

    static final CassandraDaemon instance = new CassandraDaemon();

    private volatile NativeTransportService nativeTransportService;
    private JMXConnectorServer jmxServer;

    private final boolean runManaged;
    private boolean setupCompleted;

    public CassandraDaemon()
    {
        this(false);
    }

    public CassandraDaemon(boolean runManaged)

View on GitHub (pinned to 88fd0f6a0e)