[
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
