cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Cohen (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
Date Mon, 05 Oct 2015 18:50:28 GMT


Daniel Cohen commented on CASSANDRA-9602:

[~oseiler]: [~stewartg] and I agree that we all want EACH_QUORUM reads.

I also agree that this was in fact never supported in Cassandra, and at the very least the
C* v2.0 documentation was a little confusing. Check out this link to the OSS C* code:;a=commitdiff;h=72199e23ec9d604449bef87733a32e1da9924437

In particular there is a comment regarding a change as of C* v1.1:

{quote}EACH_QUORUM ConsistencyLevel is only supported for writes and will now
+  throw an InvalidRequestException when used for reads.  (Previous
+      versions would silently perform a LOCAL_QUORUM read instead.){quote}

> EACH_QUORUM READ support needed
> -------------------------------
>                 Key: CASSANDRA-9602
>                 URL:
>             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 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
>  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

View raw message