cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harish Doddi (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3911) Basic QoS support for helping reduce OOMing cluster
Date Thu, 29 Mar 2012 19:30:22 GMT


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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message