cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-982) read repair on quorum consistencylevel
Date Tue, 04 Jan 2011 21:40:47 GMT

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


Mime
View raw message