cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12252) Support RR and Speculative Retry for EACH_QUORUM reads
Date Fri, 14 Oct 2016 14:05:20 GMT


Carl Yeksigian commented on CASSANDRA-12252:

Since EACH_QUORUM is not a typical consistency level for users, I think it makes sense to
try to continue to use the simple ReadCallback that we currently have which does not need
to track each DC independently, only the number of responses, for all other consistency levels,
and only add the complexity of a DC aware counter if we are using a DC-aware consistency level
(possibly adding this support for LOCAL_* consistency levels as well).

For speculative retry, we can't select a single node to retry before we send the first set
of requests - we need to know which DCs have failed to responded before we can properly choose
the next node to try. In this case, we will need the information from the read callback to
determine which DC hasn't responded yet, and then can choose the next replica to which to
send an additional request. This can be done with a new SpeculativeRetry type since this will
not be the usual case.

> Support RR and Speculative Retry for EACH_QUORUM reads
> ------------------------------------------------------
>                 Key: CASSANDRA-12252
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Carl Yeksigian
>            Priority: Minor
> We should properly support read repair and speculative retry for EACH_QUORUM reads.
> To support these, we need to make sure that we count responses for each DC separately,
so that we can properly monitor the number of responses from each. For speculative retry,
we should try to replace each host that we are retrying with one in the same DC; that will
make sure that we actually have the correct responses at the end if the speculative retries
are successful.

This message was sent by Atlassian JIRA

View raw message