apache/cassandra · warning
Exception occurred updating coordinatorWriteLatency metric
Error message
Exception occurred updating coordinatorWriteLatency metric
What it means
After completing a write, StorageProxy updates the coordinatorWriteLatency latency metric. Any exception thrown while recording that metric (timing, histogram registration, etc.) is caught and logged at warn level — the write itself already succeeded, so this only indicates a metrics-infrastructure problem, not data loss.
Solutions
- Read the attached exception stack trace in the log to identify the actual cause
- Verify the metrics registry/JMX reporting configuration is valid
- Upgrade to a version where the specific metrics bug (if any) is fixed — include the stack trace in a report if reproducible
- Confirm writes are succeeding (check write latency/throughput metrics); this warning alone does not affect data
Defensive patterns
Strategy: try-catch
Try / catch
// the library already catches it; treat as noisy-log signal only
if (logsContain("Exception occurred updating coordinatorWriteLatency metric"))
alertOnMetricsPipeline(); // investigate metrics/JMX infra, not writes Prevention
- Keep Dropwizard/JMX registry configuration valid and tested
- Alert on this log pattern to catch metrics-infrastructure regressions early
- Confirm write SLOs independently of metric recording
When it happens
Trigger: An Exception escapes the metric update code in the write-completion path (e.g. during coordinatorWriteLatency latency recording), caught by the catch block that logs this message with the stack trace as the argument.
Common situations: Metrics library (Dropwizard) issues; unexpected nulls or races in the latency-recording path; usually seen in logs alongside JMX/metrics registry problems.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- Invalid row " + row + " in table: " +…
- Aborting index memtable flush for
- Already logging to
- An empty map of logger names and their logging levels was…
- Artificial latency limit is
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/82d5cceb5609dd26.
Report an issue: GitHub.
Appendix: source
Thrown at src/java/org/apache/cassandra/service/StorageProxy.java:1640
ColumnFamilyStore store = keyspace.getColumnFamilyStore(tableId);
if (firstColumnFamilyStore == null)
{
store.metric.coordinatorWriteLatency.update(latency, NANOSECONDS);
firstColumnFamilyStore = store;
}
else if (!firstColumnFamilyStore.equals(store))
{
if (uniqueColumnFamilyStores == null)
uniqueColumnFamilyStores = new HashSet<>();
if (uniqueColumnFamilyStores.add(store))
store.metric.coordinatorWriteLatency.update(latency, NANOSECONDS);
}
}
}
}
catch (Exception ex)
{
logger.warn("Exception occurred updating coordinatorWriteLatency metric", ex);
}
}
private static void syncWriteToBatchlog(Collection<Mutation> mutations, ReplicaPlan.ForWrite replicaPlan, TimeUUID uuid, Dispatcher.RequestTime requestTime)
throws WriteTimeoutException, WriteFailureException
{
WriteResponseHandler<?> handler = new WriteResponseHandler<>(replicaPlan,
WriteType.BATCH_LOG,
null,
requestTime);
Batch batch = Batch.createLocal(uuid, FBUtilities.timestampMicros(), mutations);
Message<Batch> message = Message.out(BATCH_STORE_REQ, batch);
for (Replica replica : replicaPlan.liveAndDown())
{
if (logger.isTraceEnabled())
logger.trace("Sending batchlog store request {} to {} for {} mutations", batch.id, replica, batch.size());
View on GitHub (pinned to 88fd0f6a0e)