[ 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)