cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-12106) Add ability to blacklist a CQL partition so all requests are ignored
Date Thu, 21 Jul 2016 09:21:20 GMT

    [ 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)

Mime
View raw message