[
https://issues.apache.org/jira/browse/CASSANDRA-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1316:
--------------------------------------
Fix Version/s: 0.6.5
(was: 0.6.4)
> Read repair does not always work correctly
> ------------------------------------------
>
> Key: CASSANDRA-1316
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1316
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.4
> Reporter: Brandon Williams
> Fix For: 0.6.5
>
> Attachments: 001_correct_responsecount_in_RRR.txt, cassandra-1.json,
> cassandra-2.json, cassandra-3.json, RRR-v2.txt
>
>
> Read repair does not always work. At the least, we allow violation of the
> CL.ALL contract. To reproduce, create a three node cluster with RF=3, and
> json2sstable one of the attached json files on each node. This creates a row
> whose key is 'test' with 9 columns, but only 3 columns are on each machine.
> If you get_count this row in quick succession at CL.ALL, sometimes you will
> receive a count of 6, sometimes 9. After the ReadRepairManager has sent the
> repairs, you will always get 9, which is the desired behavior.
> I have another data set obtained in the wild which never fully repairs for
> some reason, but it's a bit large to attach (600ish columns per machine.)
> I'm still trying to figure out why RR isn't working on this set, but I always
> get different results when reading at any CL including ALL, no matter how
> long I wait or how many reads I do.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
