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

Kelvin Kakugawa commented on CASSANDRA-1985:
--------------------------------------------

Yes, that's correct for read CL > ONE.  A quorum / all read goes through that 
path.  However, the CL.ONE case does not go through that code path.

The branch in the code is in fetchRows(...) when it checks for 
randomlyReadRepair(...).  If the targets > handler.blockfor, it does a 
background repair via RepairRunner in service.StorageProxy.  i.e. it won't go 
through the block of code you pasted, because a DigestMismatchException won't 
be thrown for CL.ONE.

Now, let's look at RepairRunner : runMayThrow.  It calls repair(command, 
endpoints), but the RepairCallback<row> that is returned by repair(...) is 
dropped on the floor.  So, resolve is never called on that RepairCallback's 
ReadResponseResolver.

The above error was found via my own set of distributed tests.

> read repair on CL.ONE regression
> --------------------------------
>
>                 Key: CASSANDRA-1985
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1985
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.0, 0.7.1, 0.8
>            Reporter: Kelvin Kakugawa
>            Assignee: Kelvin Kakugawa
>             Fix For: 0.7.1, 0.8
>
>         Attachments: 
> CASSANDRA-1985-0001-fix-CL.ONE-read-repair-regression.patch
>
>
> read repair w/ CL.ONE had a regression.
> The RepairCallback was dropped (in the background for CL.ONE), so 
> ReadResponseResolver : resolve() was never called.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to