[jira] [Commented] (CASSANDRA-12106) Add ability to blacklist a CQL partition so all requests are ignored

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

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

I'm going to play bad cop here (again?), but while I haven't looked at the detail, it's not immediately clear to me that the usefulness justifies the added complexity (it's a 109kb patch (with 0 tests), and it looks mostly additive).

I get that you can have problems with a partition, but as far as I can say it's mostly either:
# some data is corrupted for the partition. We already kind of handle that through our failure policies/sstable blacklisting.
# the partition has grown too large. The main issue I know of in that case is the big index to deserialize, but that's been partly addressed in CASSANDRA-11206, and we have further ongoing improvement plans with CASSANDRA-9754.
# the partition has too many tombstones. We already have tombstone thresholds for that. Granted, blacklisting the partition would avoid the work that is uselessly done before the {{TombstoneOverwhelmingException}} is thrown, but I'm not sure it's such a meaningful difference that it justify a big patch, or even the feature creeping in general.

A priori, I feel that, given the other mechanism we already have in place, the feature is a bit niche (and there is such a thing as feature creeping).

I'm also not that sure it's the best way to handle a problem with a partition. I mean, you have a problem with a partition and you decide to manually blacklist it. And then what? Surely the next step should be to fix whatever problem you have to restore service on that partition, but it feels harder to do when you have prevented all access to that partition.

Anyway, even if we do decide it's sufficiently useful to add, I'm even less convinced it warrants that level of complexity. Surely, having a partition get so bad you have to blacklist is a pretty rare occurrence (otherwise, you're doing something really wrong and that should have been caught in testing), and a temporary one (one would hope you'd take action to fix whatever the issue is, which as said above, is unclear to me how you do that). So that it should be fine to have just a single list of blacklisted keys (per table) shared by all nodes. Doing so should drastically simply this.

I'll note that I'm sorry to come so negative when you have obviously put a lot of effort into this, but this is really why we should always at least sketch some design on tickets and discuss them before implementing.

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