[
https://issues.apache.org/jira/browse/CASSANDRA-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973885#action_12973885
]
Hudson commented on CASSANDRA-1873:
-----------------------------------
Integrated in Cassandra-0.6 #31 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.6/31/])
manage read repair in coordinator instead of data source, to provide
latency information to dynamic snitch
patch by jbellis; reviewed by brandonwilliams for CASSANDRA-1873
> Read Repair behavior thwarts DynamicEndpointSnitch at CL.ONE
> ------------------------------------------------------------
>
> Key: CASSANDRA-1873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1873
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.6.9, 0.7.1
>
> Attachments: 1873.txt
>
>
> When doing a CL.ONE read, the coordinator node selects the data node from the
> list of replicas via snitch sortByProximity. The data node (_not_ the
> coordinator) then sends digest requests to the remaining replicas, and
> compares their answers to its own (in ConsistencyChecker).
> This means that, in a multi-datacenter situation, for any given range R with
> replicas X in dc1 and Y in dc2, the only node with latency information for Y
> will be X. Since DES falls back to subsnitch (static) order when latency
> information is missing for any replica it is asked to sort, DES will be
> unable to direct requests to Y no matter how overwhelmed X becomes.
> To fix this, we should move the digest-checking code into the coordinator
> node (probably starting with the 0.7 ConsistencyChecker, which represents a
> cleanup of the 0.6 one).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
