Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 29 Mar 2012 19:30:22 +0000 (UTC)
From: "Harish Doddi (Commented) (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1037913471.34376.1333049422327.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1468262105.38882.1329267839402.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-3911) Basic QoS support for helping
 reduce OOMing cluster
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Harish Doddi commented on CASSANDRA-3911:
-----------------------------------------

Comments from brandon through IRC 
==================================

1. Move all the qos validations to Thrift validator class possibly.

2. Have validation on cql side (QP validation)

3. Possible renaming of "QoS" to something else.
                
> Basic QoS support for helping reduce OOMing cluster
> ---------------------------------------------------
>
>                 Key: CASSANDRA-3911
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3911
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Chris Goffinet
>            Assignee: Harish Doddi
>            Priority: Minor
>             Fix For: 1.2
>
>         Attachments: CASSANDRA-3911-trunk.txt
>
>
> We'd like to propose adding some basic QoS features to Cassandra. There can be a lot to be done here but for v1 to keep things less invasive, and still provide basics we would like to contribute the following features and see if the community thinks this is OK.
> We would set these on server (cassandra.yaml). If threshold is crossed, we throw an exception up to the client.
> 1) Limit how many rows a client can fetch over RPC through multi-get.
> 2) Limit how many columns may be returned (if count > N) throw exception before processing.
> 3) Limit how many rows and columns a client can try to batch mutate.
> This can be added in our Thrift logic, before any processing can be done. The big reason why we want to do this, is so that customers don't shoot themselves in the foot, by making mistakes or not knowing how many columns they might have returned.
> We can build logic like this into a basic client, but I propose one of the features we might want in Cassandra is support for not being able to OOM a node. We've done lots of work around memtable flushing, dropping messages, etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira