[ 
https://issues.apache.org/jira/browse/CASSANDRA-15696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jon Haddad updated CASSANDRA-15696:
-----------------------------------
    Description: 
When ideal_consistency_level is set (CASSANDRA-13289), we currently increment a 
counter if a request doesn’t meet the consistency level specified in the 
configuration (or through JMX).

At the moment, we increment the counter if the query was successful or not. I 
think it would be slightly better if we only incremented the counter if the 
ideal CL wasn’t achieved but the query’s CL was met.

The original JIRA, stated the following as an objective:
{quote}If your application writes at LOCAL_QUORUM how often are those writes 
failing to achieve EACH_QUORUM at other data centers. If you failed your 
application over to one of those data centers roughly how inconsistent might it 
be given the number of writes that didn't propagate since the last incremental 
repair?
{quote}
The main benefit to the JIRA was to set a CL higher than the CL being used, and 
to track how often we weren’t able to hit that CL despise hitting the 
underlying CL. We should only increment the counter in a case where we were 
able to meet the query provided consistency but were unable to meet the ideal 
consistency level.

  was:
When ideal_consistency_level is set (CASSANDRA-13289), we currently increment a 
counter if a request doesn’t use the consistency level specified in the 
configuration (or through JMX).  

At the moment, we increment the counter if the query was successful or not.  I 
think it would be slightly better if we only incremented the counter if the 
ideal CL wasn’t achieved but the query’s CL was met. 

The original JIRA, stated the following as an objective:

{quote}
If your application writes at LOCAL_QUORUM how often are those writes failing 
to achieve EACH_QUORUM at other data centers. If you failed your application 
over to one of those data centers roughly how inconsistent might it be given 
the number of writes that didn't propagate since the last incremental repair?
{quote}

The main benefit to the JIRA was to set a CL higher than the CL being used, and 
to track how often we weren’t able to hit that CL despise hitting the 
underlying CL.  We should only increment the counter in a case where we were 
able to meet the query provided consistency but were unable to meet the ideal 
consistency level.


> Only track ideal CL failure when request CL is met
> --------------------------------------------------
>
>                 Key: CASSANDRA-15696
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15696
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Observability/Metrics
>            Reporter: Jon Haddad
>            Assignee: Jon Haddad
>            Priority: Normal
>
> When ideal_consistency_level is set (CASSANDRA-13289), we currently increment 
> a counter if a request doesn’t meet the consistency level specified in the 
> configuration (or through JMX).
> At the moment, we increment the counter if the query was successful or not. I 
> think it would be slightly better if we only incremented the counter if the 
> ideal CL wasn’t achieved but the query’s CL was met.
> The original JIRA, stated the following as an objective:
> {quote}If your application writes at LOCAL_QUORUM how often are those writes 
> failing to achieve EACH_QUORUM at other data centers. If you failed your 
> application over to one of those data centers roughly how inconsistent might 
> it be given the number of writes that didn't propagate since the last 
> incremental repair?
> {quote}
> The main benefit to the JIRA was to set a CL higher than the CL being used, 
> and to track how often we weren’t able to hit that CL despise hitting the 
> underlying CL. We should only increment the counter in a case where we were 
> able to meet the query provided consistency but were unable to meet the ideal 
> consistency level.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to