[
https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945782#comment-14945782
]
Ariel Weisberg commented on CASSANDRA-9602:
-------------------------------------------
What is the doc impact here? I looked at the [2.2
docs|http://docs.datastax.com/en/cassandra/2.2/cassandra/dml/dmlConfigConsistency.html]
and it makes it seem like EACH_QUORUM for reads is already supported, but the
code makes it look like it would throw InvalidRequestException?
Do we need to have the 2.2 and earlier docs updated?
How is this tested? I looked at consistency_test.py test and I don't think it
tests combinations with EACH_QUORUM for reads. It looks like ConsistencyLevel
is unit testable, but I don't see a test for the existing code. Could you add
tests for the code that changed?
[Is dcsEndpoints something worth caching in some
way?|https://github.com/apache/cassandra/compare/trunk...carlyeks:ticket/9602#diff-6f46fd4f8a36f42512ae5f848aee033eR225]
[What is the expected load balancing behavior
here?|https://github.com/apache/cassandra/compare/trunk...carlyeks:ticket/9602#diff-6f46fd4f8a36f42512ae5f848aee033eR244]
Is it (and should it) hit the same nodes in each DC every time?
> EACH_QUORUM READ support needed
> -------------------------------
>
> Key: CASSANDRA-9602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9602
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Scott Guminy
> Assignee: Carl Yeksigian
> Labels: client-impacting, doc-impacting
> Fix For: 3.x
>
>
> EACH_QUORUM consistency for READ should be added.
> This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not
> needed ever, however I have a use case where I need it. I think the decision
> made was incorrect. Here's why...
>
> My application has two key pieces:
>
> # *End user actions* which add/modify data in the system. End users
> typically access the application from only one Data Center and only see their
> own data
> # *Scheduled business logic tasks* which run from any node in any data
> center. These tasks process data added by the end users in an asynchronous
> way
>
> *End user actions must have the highest degree of availability.* Users must
> always be able to add data to the system. The data will be processed later.
> To support this, end user actions will use *LOCAL_QUORUM Read and Write
> Consistency*.
>
> Scheduled tasks don't need to have a high degree of availability but MUST
> operate on the most up to date data. *The tasks will run with EACH_QUORUM*
> to ensure that no matter how many data centers we have, we always READ the
> latest data. This approach allows us some amount of fault tolerance.
>
> The problem is that EACH_QUORUM is not a valid READ consistency level. This
> mean I have no alternative but to use ALL. ALL will work, but is not the
> best since it offers support for ZERO failures. I would prefer EACH_QUORUM
> since it can support some failures in each data center.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
