[ 
https://issues.apache.org/jira/browse/CASSANDRA-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15947063#comment-15947063
 ] 

Jason Brown commented on CASSANDRA-13289:
-----------------------------------------

I'm pretty much +1 on the patch, except for the 
{{AbstractWriteResponseHandler#responsesAndExpirations}} extra garbage and two 
trivial nits, which you can feel free to completely ignore:

- maybe use the javacdoc comment style on {{Config#ideal_consistency_level}} 
rather than the line comment style?
- {{StorageProxy#setIdealConsistencyLevel}} returns the previous value of the 
{{ideal_consistency_level}}. Would that be confusing to operators who execute 
the JMX command? maybe return "updating setIdealConsistencyLevel, previous 
value was <VALUE>"?

The last thing is testing: i think it's possible to add unit tests to confirm 
most of the behaviors here. Can you take a look into that?

> Make it possible to monitor an ideal consistency level separate from actual 
> consistency level
> ---------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-13289
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13289
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Ariel Weisberg
>            Assignee: Ariel Weisberg
>             Fix For: 4.0
>
>
> As an operator there are several issues related to multi-datacenter 
> replication and consistency you may want to have more information on from 
> your production database.
> For instance. 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?
> You might also want to know roughly what the latency of writes would be if 
> you switched to a different consistency level. For instance you are writing 
> at LOCAL_QUORUM and want to know what would happen if you switched to 
> EACH_QUORUM.
> The proposed change is to allow an ideal_consistency_level to be specified in 
> cassandra.yaml as well as get/set via JMX. If no ideal consistency level is 
> specified no additional tracking is done.
> if an ideal consistency level is specified then the 
> {{AbstractWriteResponesHandler}} will contain a delegate WriteResponseHandler 
> that tracks whether the ideal consistency level is met before a write times 
> out. It also tracks the latency for achieving the ideal CL  of successful 
> writes.
> These two metrics would be reported on a per keyspace basis.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to