Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 21 Jul 2016 09:21:20 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12984540.1467156590000.93693.1469092880548@Atlassian.JIRA>
In-Reply-To: <JIRA.12984540.1467156590000@Atlassian.JIRA>
References: <JIRA.12984540.1467156590000@Atlassian.JIRA> <JIRA.12984540.1467156590733@arcas>
Subject: [jira] [Commented] (CASSANDRA-12106) Add ability to blacklist a CQL
 partition so all requests are ignored
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 21 Jul 2016 09:21:22 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387421#comment-15387421 ] 

Sylvain Lebresne commented on CASSANDRA-12106:
----------------------------------------------

bq. There are cases in which there are large partitions due to spammers, etc

We've always conscientiously say that it is not Cassandra's job to protect against malicious clients. You should not expose C* to the wild and spammers is something you should deal with at the application level.

More generally though, and to repeat myself a bit, we shouldn't feature creep C* so any new feature should have decently general usefulness and justification. And it's also a pretty big patch (lots of code to maintain) which multiply the requirement on general usefulness. Personally, I'm not convinced of that general usefulness and arguments like "Sometimes reads/writes to a given partition may cause problems due to the data present", "There are cases" or "this could be very common based on the app" are a bit too hand-wavy to my taste.

I welcome other devs and user input on this, and I could revise my judgment if it becomes clear that getting this feature is important to a large enough amount of users that the maintenance cost becomes justified, but I'm currently -1 on this particular patch.

I want to insist that I'm not so much against the idea of the ticket in general (though I do am not entirely fan of it as I'd rather deal with the source of problems leading to wanting to blacklist of partition) than I am put off by my perceived mismatch between the relatively minor usefulness and the large complexity involved by the patch (things like having to deal with cache consistency on topology changes for instance).

However, if we were to consider the much (much) simpler approach of, say, add a {{blacklisted_partitions}} (schema) property to tables and simply reject queries that cover any of the key in that set on the coordinator, then I'd be much more receptive to that.


> Add ability to blacklist a CQL partition so all requests are ignored
> --------------------------------------------------------------------
>
>                 Key: CASSANDRA-12106
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12106
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Geoffrey Yu
>            Assignee: Geoffrey Yu
>            Priority: Minor
>             Fix For: 4.x
>
>         Attachments: 12106-trunk.txt
>
>
> Sometimes reads/writes to a given partition may cause problems due to the data present. It would be useful to have a manual way to blacklist such partitions so all read and write requests to them are rejected.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)