[
https://issues.apache.org/jira/browse/CASSANDRA-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642031#comment-14642031
]
Paulo Motta commented on CASSANDRA-9753:
----------------------------------------
What is the {{read_repair_chance}} (*NOT* {{dc_local_read_repair}}) ? If > 0,
then maybe that's a duplicate of
[8479|https://issues.apache.org/jira/browse/CASSANDRA-8479], because currently
the {{read_repair_chance}} is orthogonal to consistency level and may cross DC
boundaries even if CL is LOCAL_*. You may be interested in the discussion of
[CASSANDRA-6887|https://issues.apache.org/jira/browse/CASSANDRA-6887] to change
that behavior.
> LOCAL_QUORUM reads can block cross-DC if there is a digest mismatch
> -------------------------------------------------------------------
>
> Key: CASSANDRA-9753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9753
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Richard Low
>
> When there is a digest mismatch during the initial read, a data read request
> is sent to all replicas involved in the initial read. This can be more than
> the initial blockFor if read repair was done and if speculative retry kicked
> in. E.g. for RF 3 in two DCs, the number of reads could be 4: 2 for
> LOCAL_QUORUM, 1 for read repair and 1 for speculative read if one replica was
> slow. If there is then a digest mismatch, Cassandra will issue the data read
> to all 4 and set blockFor=4. Now the read query is blocked on cross-DC
> latency. The digest mismatch read blockFor should be capped at RF for the
> local DC when using CL.LOCAL_*.
> You can reproduce this behaviour by creating a keyspace with
> NetworkTopologyStrategy, RF 3 per DC, dc_local_read_repair=1.0 and ALWAYS for
> speculative read. If you force a digest mismatch (e.g. by deleting a replicas
> SSTables and restarting) you can see in tracing that it is blocking for 4
> responses.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
