Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 10 Jan 2013 18:48:15 +0000 (UTC)
From: =?utf-8?Q?Andr=C3=A9_Cruz_=28JIRA=29?= <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12627001.1357843661871.114730.1357843695990@arcas>
In-Reply-To: <JIRA.12627001.1357843661871@arcas>
References: <JIRA.12627001.1357843661871@arcas>
Subject: [jira] [Created] (CASSANDRA-5143) Safety valve on number of
 tombstones skipped on read path too prevent a full heap
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Andr=C3=A9 Cruz created CASSANDRA-5143:
-------------------------------------

             Summary: Safety valve on number of tombstones skipped on read =
path too prevent a full heap
                 Key: CASSANDRA-5143
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5143
             Project: Cassandra
          Issue Type: Improvement
          Components: Core
    Affects Versions: 1.1.5
         Environment: Debian Linux, 3 node cluster with RF 3, 8GB heap on 3=
2GB machines
            Reporter: Andr=C3=A9 Cruz


When doing a range query on a row with a lot of tombstones, these can quick=
ly 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 s=
ide it can do nothing to prevent this from happening since there is no limi=
t 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 t=
ake better care of himself so as to prevent a DoS. I can imagine a lot of u=
se 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 ask=
ed me for X nodes, I've already collected X^Y nodes and still have not foun=
d X live nodes, I should just give up". The Y would be the configurable par=
ameter. Time taken per query or memory used could also be factors to take i=
nto consideration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira