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


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

Reply via email to