You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2010/01/12 00:26:54 UTC

[jira] Created: (CASSANDRA-687) Add ConsistencyLevel.ANY

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: Jonathan Ellis
            Priority: Minor
             Fix For: 0.9


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.


[jira] Commented: (CASSANDRA-687) Add ConsistencyLevel.ANY

Posted by "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 commented on CASSANDRA-687:
------------------------------------------

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.


[jira] Commented: (CASSANDRA-687) Add ConsistencyLevel.ANY

Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CASSANDRA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803734#action_12803734 ] 

Jonathan Ellis commented on CASSANDRA-687:
------------------------------------------

+                        // (hints are part of the callback and count towards consistency only under CL.ANY
+                        if (consistency_level == ConsistencyLevel.ANY)
+                            MessagingService.instance.addCallback(responseHandler, hintedMessage.getMessageId());

excellent, I like that solution.

+1

> 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.


[jira] Updated: (CASSANDRA-687) Add ConsistencyLevel.ANY

Posted by "Gary Dusbabek (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CASSANDRA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Dusbabek updated CASSANDRA-687:
------------------------------------

    Attachment: 0001-thrift-changes.patch
                0002-add-ConsistencyLevel.ANY-for-writes.patch

Patches have been updated according to the review comments.

> 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.


[jira] Updated: (CASSANDRA-687) Add ConsistencyLevel.ANY

Posted by "Gary Dusbabek (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CASSANDRA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Dusbabek updated CASSANDRA-687:
------------------------------------

    Attachment: 0002-add-ConsistencyLevel.ANY-for-writes.patch
                0001-thrift-changes.patch

> 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.


[jira] Commented: (CASSANDRA-687) Add ConsistencyLevel.ANY

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CASSANDRA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804076#action_12804076 ] 

Hudson commented on CASSANDRA-687:
----------------------------------

Integrated in Cassandra #332 (See [http://hudson.zones.apache.org/hudson/job/Cassandra/332/])
    Add ConsistencyLevel.ANY for writes. Patch by Gary Dusbabek, reviewed by Jonathan Ellis. 


> 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.


[jira] Updated: (CASSANDRA-687) Add ConsistencyLevel.ANY

Posted by "Gary Dusbabek (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CASSANDRA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Dusbabek updated CASSANDRA-687:
------------------------------------

    Attachment:     (was: 0001-thrift-changes.patch)

> 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.


[jira] Assigned: (CASSANDRA-687) Add ConsistencyLevel.ANY

Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CASSANDRA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis reassigned CASSANDRA-687:
----------------------------------------

    Assignee: Gary Dusbabek  (was: Jonathan Ellis)

> 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
>
>
> 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.


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

Posted by "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.


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

Posted by "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: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.


[jira] Updated: (CASSANDRA-687) Add ConsistencyLevel.ANY

Posted by "Gary Dusbabek (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CASSANDRA-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Dusbabek updated CASSANDRA-687:
------------------------------------

    Attachment:     (was: 0002-add-ConsistencyLevel.ANY-for-writes.patch)

> 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.