cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CASSANDRA-687) Add ConsistencyLevel.ANY
Date Thu, 21 Jan 2010 15:57:54 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803343#action_12803343
] 

Jonathan Ellis edited comment on CASSANDRA-687 at 1/21/10 3:57 PM:
-------------------------------------------------------------------

Comments:

(1) IMO we should reject a read command with ANY like we do with ZERO to make clear to users
the difference between ANY and ONE (vis: a write with ANY may not be readable until later),
this is a source of much confusion (most people seem to assume that the existing ONE behaves
like ANY)
(2) ANY should be added at the end of the enum to avoid breaking older clients unnecessarily
(3) Can we move the hint_ack tracking into the coordinator code instead of modifying RM and
RMVH?  We already have endpointMap that tells us which writes are hinted, seems like we shouldn't
need the reply to specify that redundantly.

      was (Author: jbellis):
    Comments:

(1) IMO we should reject a read command with ANY like we do with ZERO to make clear to users
the difference between ANY and ONE (vis: a write with ANY may not be readable until later),
this is a source of much confusion (most people seem to assume that the existing ONE behaves
like ANY)
(2) ANY should be added at the end of the enum to avoid breaking older clients unnecessarily
(3) Can we move the hint_ack tracking into the coordinator code instead of modifying RM and
RMVH?  We already have endpointMap that tells us which writes, seems like we shouldn't need
the reply to specify that redundantly.
  
> Add ConsistencyLevel.ANY
> ------------------------
>
>                 Key: CASSANDRA-687
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-687
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Gary Dusbabek
>            Priority: Minor
>             Fix For: 0.6
>
>         Attachments: 0001-thrift-changes.patch, 0002-add-ConsistencyLevel.ANY-for-writes.patch
>
>
> after CASSANDRA-685, control nodes will throw data away and raise a TimeoutException
to backpressure clients that are overwhelming the cluster.  This means we need a ConsistencyLevel
"between" ZERO and ONE, meaning that Cassandra will block until the data is written *somewhere*,
possibly to a HH target.  (and really we needed this already, judging from people dissatisfied
with the existing options)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message