[
https://issues.apache.org/jira/browse/CASSANDRA-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3911.
---------------------------------------
Resolution: Won't Fix
Fix Version/s: (was: 2.0)
Assignee: (was: Harish Doddi)
WontFixing for lack of progress. (And modern efforts here should focus on
CQL3/binary protocol IMO.)
> 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
> Priority: Minor
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
