[ https://issues.apache.org/jira/browse/CASSANDRA-14635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589392#comment-16589392 ]
Aleksey Yeschenko commented on CASSANDRA-14635: ----------------------------------------------- Looks like a relatively straightforward small, correct change, so I don't have a lot of feedback here. 1. I'd like the get-repair-strategy-from-row logic to be moved inline in {{SchemaKeyspace}} - with a comment. Such logic historically belongs to {{SchemaKeyspace}} or its old equivalent. 2. {{cqlsh}} should be altered to add the new param for completion - it's relatively straightforward 3. There is a single-iteration (at most) loop in {{AbstractReadRepair.maybeSendAdditionalReads()}} that should probably be rewritten using {{Iterables.find()}} or {{Iterables.tryFind()}} 4. {{ReconcileRead}} as the metric name for what it is; we should come up with something better, though I myself am out of ideas right now Outside of those three points, some general thoughts that don't need to be addressed: - I'm not convinced that {{ASYNC}} is an option that will be used by folks, and also am concerned with complete lack of backpressure there. With {{BLOCKING}} we at least have effective pressure via reads being blocked, here it might be dangerous, like the old replicate on write stage for counters - Not a fan of {{ReadOnlyReadRepair}} name. I know you aren't either, and I don't have better ideas > Support table level configuration of monotonic reads > ---------------------------------------------------- > > Key: CASSANDRA-14635 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14635 > Project: Cassandra > Issue Type: Improvement > Components: Coordination > Reporter: Ariel Weisberg > Assignee: Blake Eggleston > Priority: Major > Fix For: 4.0 > > > In CASSANDRA-10726 it was discussed that allowing expert users to forgo > monotonic reads might be desirable. It is practical to control monotonicity > of reads at a fine grained level because it involves changing the behavior of > read repair on a per read basis. > Per CASSANDRA-14593 we already don't preserve update atomicity down to the > column level. You could read the key out of a row and read repair the key, > pass the key to another process which attempts to read the value, but finds > the value is null because read repair only repairs the data (including > columns) that is part of the read. IMO it's a stretch to say that reads are > monotonic. It is technically correct, the best kind of correct, but far from > as useful as it should be. > An initial implementation could make read repair asynchronous or forgo read > repair entirely. This would improve the throughput and latency of reads. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org