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