cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13289) Make it possible to monitor an ideal consistency level separate from actual consistency level
Date Wed, 29 Mar 2017 12:09:41 GMT

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

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

bq. There is a part of me that doesn't like having a null field

Maybe set the type of the field to {{Optional<AtomicInteger>}}, and set it to {{Optional.empty}}
when not being used? Not sure I love this but it does avoid an NPE. 

bq. I don't want to throw an error at the request level. I can't validate the configuration.
And I don't want to silently not increment the counters.

I agree with these points, especially the last. I suspect not counting would be confusing
to an operator who went out of their way to enable this feature, and are expecting an output
of some kind. I don't think logging is necessary (or helpful).

wrt timeouts, you are correct. I think I was forgetting that this patch is only affecting
the write path, and I must have been thinking the read path was pulled along, as well. Either
way, this concern is not a real issue. 

I'll rereview the ticket now with these things in mind.

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

Mime
View raw message