[
https://issues.apache.org/jira/browse/CASSANDRA-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478510#comment-13478510
]
Robert Coli commented on CASSANDRA-4792:
----------------------------------------
Is this bug's practical effect summarizable as :
"Because read repair didn't actually wait around for repair writes to ack,
there was a non-zero chance of multiple concurrent read requests to a
needing-repair key triggering multiple repair writes?"
> Digest mismatch doesn't wait for writes as intended
> ---------------------------------------------------
>
> Key: CASSANDRA-4792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4792
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 1.1.6, 1.2.0 beta 2
>
> Attachments: 4792.txt
>
>
> As reported by Niklas Ekström on the dev list:
> I’m looking in the file StorageProxy.java (Cassandra 1.1.5), and line 766
> seems odd to me.
> FBUtilities.waitOnFutures() is called with the repairResults from the
> RowRepairResolver resolver.
> The problem though is that repairResults is only assigned when the object is
> created at line 737 in StorageProxy.java, and there it is assigned to
> Collections.emptyList(), and in the resolve() method in RowRepairResolver,
> which is indirectly called from line 771 in StorageProxy.java, that is, after
> the call to FBUtilities.waitOnFutures().
> So the effect is that line 766 in StorageProxy.java is essentially a no-op.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
