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

Xiaolong Jiang commented on CASSANDRA-10726:
--------------------------------------------

1. I will change isQuorum to satisfiesQuorumFor and add unit tests. Not sure 
about your suggestion "satisfiedQuorumFor(int quorum)" though. I will mock 
keyspace and do the unit test
2. I will remove FBUtilities#waitOnFuturesNanos
3. I will make changes to wait maximum timeToWaitNanos for all responses 
instead of for each one
4. I do have tests to cover read repair response from second node which is  
testResolveOneReadRepairRetry in DataResolverTest. It's not directly checking 
the response, it's making sure the correct data is sent to peer4. (the response 
is actually mocked by calling resolver.preprocess which is meanless, we only 
need to make sure correct data is retried to peer4)
5. hum, it's building in my personal CASSANDRA-10726 branch. I will remove the 
"final" keyword. 

> Read repair inserts should not be blocking
> ------------------------------------------
>
>                 Key: CASSANDRA-10726
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10726
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Coordination
>            Reporter: Richard Low
>            Assignee: Xiaolong Jiang
>             Fix For: 3.0.x
>
>
> Today, if there’s a digest mismatch in a foreground read repair, the insert 
> to update out of date replicas is blocking. This means, if it fails, the read 
> fails with a timeout. If a node is dropping writes (maybe it is overloaded or 
> the mutation stage is backed up for some other reason), all reads to a 
> replica set could fail. Further, replicas dropping writes get more out of 
> sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any 
> replica that's
> // behind on writes in case the out-of-sync row is read multiple times in 
> quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not 
> be blocking or we should return success for the read even if the write times 
> out.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to