cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelvin Kakugawa (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1985) read repair on CL.ONE regression
Date Fri, 14 Jan 2011 19:44:46 GMT


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

View raw message