[
https://issues.apache.org/jira/browse/CASSANDRA-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241502#comment-13241502
]
Brandon Williams commented on CASSANDRA-3911:
---------------------------------------------
First off, this is setting result limits, more than quality of service, since
we aren't [de]prioritizing anything, so I don't think QoS is the right term to
be using here.
Secondly, I don't think this patch satisfies the goal of "Limit how many
columns may be returned (if count > N) throw exception before processing" since
the server actually does the processing, then limits what it will return, which
only saves a copy in thrift. You can still request all 2B columns in a row and
OOM the server.
> 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
