cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Resolved] (CASSANDRA-5143) Safety valve on number of tombstones skipped on read path to prevent a full heap
Date Tue, 01 Oct 2013 14:35:26 GMT


Jonathan Ellis resolved CASSANDRA-5143.

    Resolution: Duplicate

> Safety valve on number of tombstones skipped on read path to prevent a full heap
> --------------------------------------------------------------------------------
>                 Key: CASSANDRA-5143
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1.5
>         Environment: Debian Linux, 3 node cluster with RF 3, 8GB heap on 32GB machines
>            Reporter: André Cruz
> When doing a range query on a row with a lot of tombstones, these can quickly add up
and use too much heap, even if we specify a column count of 2 as the tombstones can be between
those two live columns. From the client API side it can do nothing to prevent this from happening
since there is no limit that can be specified for the number of tombstones being collected.
> I know that this looks like the "I'm using a row as a queue and building up a ton of
tombstones" anti-pattern, but still Cassandra should be able to take better care of himself
so as to prevent a DoS. I can imagine a lot of use cases that let users create and delete
columns on a row.
> I propose a simple safety valve that can act like this: "The client has asked me for
X nodes, I've already collected X^Y nodes and still have not found X live nodes, I should
just give up and return an exception". The Y would be the configurable parameter. Time taken
per query or memory used could also be factors to take into consideration.

This message was sent by Atlassian JIRA

View raw message