[CASSANDRA-19651] idealCLWriteLatency metric reports the worst response time instead of the time when ideal CL is satisfied - ASF JIRA

XML

Word

Printable

JSON

Details

Type: Bug
Status: Resolved
Priority: Normal
Resolution: Fixed
Fix Version/s: 4.0.14, 4.1.7, 5.0.1, 5.1
Component/s: Legacy/Observability
Labels:
None

Bug Category:
Correctness
Severity:
Normal
Complexity:
Low Hanging Fruit
Discovered By:
User Report
Platform:

All
Impacts:

None
Since Version:

4.0
Source Control Link:

https://github.com/apache/cassandra/commit/6da9141d3ccfb21aead3b19474f8855724e0ca85
Test and Documentation Plan:

Hide

an existing unit test is updated and 2 more are added to cover the issue
docs updates are not planned

Show
an existing unit test is updated and 2 more are added to cover the issue docs updates are not planned

Description

org.apache.cassandra.service.AbstractWriteResponseHandler:

private final void decrementResponseOrExpired()
{
    int decrementedValue = responsesAndExpirations.decrementAndGet();
    if (decrementedValue == 0)
    {
        // The condition being signaled is a valid proxy for the CL being achieved
        // Only mark it as failed if the requested CL was achieved.
        if (!condition.isSignalled() && requestedCLAchieved)
        {
            replicaPlan.keyspace().metric.writeFailedIdealCL.inc();
        }
        else
        {
            replicaPlan.keyspace().metric.idealCLWriteLatency.addNano(nanoTime() - queryStartNanoTime);
        }
    }
}

Actual result: responsesAndExpirations is a total number of replicas across all DCs which does not depend on the ideal CL, so the metric value for replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get the latest response/timeout for all replicas.
Expected result: replicaPlan.keyspace().metric.idealCLWriteLatency is updated when we get enough responses from replicas according to the ideal CL.