[
https://issues.apache.org/jira/browse/CASSANDRA-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977471#action_12977471
]
Jonathan Ellis commented on CASSANDRA-982:
------------------------------------------
Daniel Doubleday's review from email:
I like that both (strong and weak) reads are unified that way (looks cleaner
than 1873).
FWIW some minor remarks:
ReadResponseResolver:110
Map.remove while iterating over it is a little irritating since normal maps
don't like that
Digest Mismatches and Async Repair
StorageProxy:382 - mismatch exception can only occur when CL > ONE and data
was received from one node. It might be worth reusing the same resolver (which
would have to store the data messge instead of throwing it away in 110) and ask
only that nodes for data that received digest requests before.
Along the same line: In case of strong reads and quorum matches it would
seem more efficient to just send writes to remaining nodes that disagree
instead of doing a complete repair read. (StorageProxy:380)
For both cases: I dont know if that happens often enough to justify the
complexity. (Maybe not)
IResponseResolver.getData
I understand that method is only needed to be able to return data that
cassandra knows to be invalid in case of CL.ONE and the digest arriving before
data (ReadCallback:81). If this is the contract of CL.ONE I would break it
there :-) and do a read repair before sending the data but that's just a matter
of taste and becomes messy when the read repair fails - you still need getData
to handle that.
> read repair on quorum consistencylevel
> --------------------------------------
>
> Key: CASSANDRA-982
> URL: https://issues.apache.org/jira/browse/CASSANDRA-982
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments:
> 0001-better-digest-checking-for-ReadResponseResolver.patch,
> 0001-r-m-SP.weakRead-rename-strongRead-to-fetchRows.-read-r.txt,
> 0002-implement-read-repair-as-a-second-resolve-after-the-in.txt,
> 0002-quorum-only-read.txt,
> 0003-rename-QuorumResponseHandler-ReadCallback.txt, 982-resolve-digests-v2.txt
>
> Original Estimate: 6h
> Remaining Estimate: 6h
>
> CASSANDRA-930 made read repair "fuzzy optional," but this only helps with
> ConsistencyLevel.ONE:
> - Quorum reads always send requests to all nodes
> - only the first Quorum's worth of responses get compared
> So what we'd like to do two changes:
> - only send read requests to the closest R live nodes
> - if read repair is enabled, also compare results from the other nodes in the
> background
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
