[
https://issues.apache.org/jira/browse/CASSANDRA-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419811#comment-17419811
]
Sumanth Pasupuleti edited comment on CASSANDRA-12106 at 9/24/21, 2:36 PM:
--------------------------------------------------------------------------
[~jmckenzie] did a deeper pass, and I have following questions/suggestions
1. It maybe useful to add a documentation file around denylisting partitions
(maybe along the lines of
https://github.com/apache/cassandra/compare/trunk...sumanth-pasupuleti:feature/12106#diff-4264f2ac97017f73e4f6fff8f1cbef3082212b2edc531b57f6e8f064d3ab3e49)
2. -With regards to limiting the amount of memory we would allow the denylisted
partitions to take, we could potentially limit/throw warning based on memory as
an alternate approach to limiting based on number of partition keys. Not a
strong opinion here since we expect operators (and not end users) to use this
feature and it should be safe either ways, given we expect operators to be
informed.-
[EDIT] As I think through further, and as mentioned in CEP, it is probably best
to log a warning if denylisted partitions exceed in either number or memory
usage vs "limiting" them, in order to maintain consistency across all the
nodes' caches in terms of what partitions are denylisted.
3. We could as an alternative, allow configuring denylisting specific
operations (read vs write) per node per partition vs per node - I feel the way
it is currently implemented (per node and not per node per partition) is less
complex and easy to use and we should probably stick to that. We can revisit in
the future if needed.
4. Curious on the choice of exposing consistency level for querying denylisting
partitions. What do you think of a simpler approach doing "local execution" by
each node when querying partitions_denylisted table. The benefit would be it
can make it less complicated in terms of number of options we expose and not
needing to check if we have enough nodes for the chosen consistency level.
5. Curious on why we disable denylisting range reads by default
6. Regarding the datatype for "key" in "system_distributed.partition_denylist",
what do you think of choosing text (vs blob). Advantage would be readability of
the key, and on cache refresh, we would convert it into ByteBuffer
7. What do you think about adding nodetool commands for
a) refreshing denylist
b) adding a partition to denylist
c) removing a partition from denylist
Happy to contribute to any of these, if decide to make any related changes
was (Author: sumanth.pasupuleti):
[~jmckenzie] did a deeper pass, and I have following questions/suggestions
1. It maybe useful to add a documentation file around denylisting partitions
(maybe along the lines of
https://github.com/apache/cassandra/compare/trunk...sumanth-pasupuleti:feature/12106#diff-4264f2ac97017f73e4f6fff8f1cbef3082212b2edc531b57f6e8f064d3ab3e49)
2. With regards to limiting the amount of memory we would allow the denylisted
partitions to take, we could potentially limit/throw warning based on memory as
an alternate approach to limiting based on number of partition keys. Not a
strong opinion here since we expect operators (and not end users) to use this
feature and it should be safe either ways, given we expect operators to be
informed.
[EDIT] As I think through further, and as mentioned in CEP, it is probably best
to log a warning if denylisted partitions exceed in either number of memory
usage vs "limiting" them, in order to maintain consistency across all the
nodes' caches in terms of what partitions are denylisted.
3. We could as an alternative, allow configuring denylisting specific
operations (read vs write) per node per partition vs per node - I feel the way
it is currently implemented (per node and not per node per partition) is less
complex and easy to use and we should probably stick to that. We can revisit in
the future if needed.
4. Curious on the choice of exposing consistency level for querying denylisting
partitions. What do you think of a simpler approach doing "local execution" by
each node when querying partitions_denylisted table. The benefit would be it
can make it less complicated in terms of number of options we expose and not
needing to check if we have enough nodes for the chosen consistency level.
5. Curious on why we disable denylisting range reads by default
6. Regarding the datatype for "key" in "system_distributed.partition_denylist",
what do you think of choosing text (vs blob). Advantage would be readability of
the key, and on cache refresh, we would convert it into ByteBuffer
7. What do you think about adding nodetool commands for
a) refreshing denylist
b) adding a partition to denylist
c) removing a partition from denylist
Happy to contribute to any of these, if decide to make any related changes
> Add ability to blocklist / denylist 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
> Components: Legacy/Local Write-Read Paths, Local/Config
> Reporter: Geoffrey Yu
> Assignee: Sumanth Pasupuleti
> Priority: Low
> 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 blocklist / denylist
> such partitions so all read and write requests to them are rejected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
