cassandra-commits mailing list archives

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


Jonathan Ellis commented on CASSANDRA-3911:

I'm not a huge fan of this approach in general, but we're already doing something similar
with thrift frame size.  So I guess I'm okay with it.

We should probably stick to just the read side though, since the write side *is* already covered
by said frame size.  (I suppose you could make that a double, if MB is not granular enough.)

Finally, would prefer to just see settings for read_rows and read_columns (read_columns_per_row?),
rather than a two-tier system of Master Switch *and* individual settings.
> 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