[jira] Issue Comment Edited: (CASSANDRA-687) Add ConsistencyLevel.ANY

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ 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:56 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, 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, 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.