cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blake Eggleston (Jira)" <>
Subject [jira] [Updated] (CASSANDRA-15569) StorageProxy updateCoordinatorWriteLatencyTableMetric can produce misleading metrics
Date Fri, 14 Feb 2020 21:50:00 GMT


Blake Eggleston updated CASSANDRA-15569:
          Since Version: 4.0-alpha
    Source Control Link:
             Resolution: Fixed
                 Status: Resolved  (was: Ready to Commit)

+1, this fixes the potential double counting issue. Committed to trunk as [247502c5d19c181bbe0a224da3ad6ebd0156f607

It wouldn’t be a bad idea to revisit whether we we want to update this metric on failed
or speculated reads (or writes). We want to speculate if it looks like a read won’t be responded
to quickly. Using the latency of reads that have been speculated on, needed read repair, or
timed out to inform our decision seems like it would artificially inflate this number. It
may turn out that this is intentional, but it would be nice to have a comment explaining this
if that’s the case.

> StorageProxy updateCoordinatorWriteLatencyTableMetric can produce misleading metrics
> ------------------------------------------------------------------------------------
>                 Key: CASSANDRA-15569
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Consistency/Coordination, Legacy/Local Write-Read Paths, Observability/Metrics
>            Reporter: David Capwell
>            Assignee: David Capwell
>            Priority: Normal
>              Labels: pull-request-available
>             Fix For: 4.0-alpha
>          Time Spent: 20m
>  Remaining Estimate: 0h
> If multiple mutations affect the same table, then metrics will get posted multiple times
to the same table.
> [Circle CI|]

This message was sent by Atlassian Jira

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message