[
https://issues.apache.org/jira/browse/CASSANDRA-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17422226#comment-17422226
]
Josh McKenzie edited comment on CASSANDRA-12106 at 9/29/21, 4:11 PM:
---------------------------------------------------------------------
Pushed up four commits with quite a few changes - some of those target what
you've spoken about [~sumanth.pasupuleti], and your points on the PR have been
addressed (I think) [~azotcsit].
{quote}It maybe useful to add a documentation
{quote}
Definitely will do once API's and guarantees are settled in the implementation.
Good call!
{quote}it is probably best to log a warning if denylisted partitions exceed in
either number or memory usage
{quote}
Agree 100%. Will add this. (edit: actually does after the recent commits since
we refresh the denylist data on a per-table basis after we process the CQL for
addition or removal; the code-paths warn if you're above either the global or
per-table level)
{quote}Curious on the choice of exposing consistency level for querying
denylisting partitions
{quote}
I commented the reasoning around why it defaults to CL.QUORUM in one of those
commits (adding the params to the .yaml), but I'm receptive to an argument that
we shouldn't even have that as a configurable at all to the end user and just
twiddle with it in tests. I can see the idea of users being able to up it to
CL.ALL, or perhaps applying that CL to just writes to the denylist at ALL and
read at QUORUM, but then we're talking about more configurables for diminishing
returns.
{quote}Curious on why we disable denylisting range reads by default
{quote}
All three types are enabled in the .yaml but commented out now.
{quote}what do you think of choosing text (vs blob). Advantage would be
readability of the key
{quote}
I wasn't original author on this but here's my take thinking about it for a
bit. We can either a) make things more readable in the table at the expense of
having a different data type in the DB than is cached in memory and used in the
read / write path, or b) keep the data type the same up and down the entire
stack and push the cost to the end user to convert during their query. I lean
towards b just because this is part of the hot path and I tend to dislike risk
(even the minimal risk of differing data types in memory vs. table and
conversion on load); we can document this (including the CQL to query and
convert to human readable) to work around that little usability friction. wdyt?
{quote}What do you think about adding nodetool commands...
{quote}
Sounds great! I'd prefer we do that work on a followup ticket though as in my
opinion the CQL + JMX combined interface for this should be adequate for
operators on a first implementation.
Thanks for the feedback!
was (Author: jmckenzie):
Pushed up four commits with quite a few changes - some of those target what
you've spoken about [~sumanth.pasupuleti], and your points on the PR have been
addressed (I think) [~azotcsit].
{quote}It maybe useful to add a documentation
{quote}
Definitely will do once API's and guarantees are settled in the implementation.
Good call!
{quote}it is probably best to log a warning if denylisted partitions exceed in
either number or memory usage
{quote}
Agree 100%. Will add this.
{quote}Curious on the choice of exposing consistency level for querying
denylisting partitions
{quote}
I commented the reasoning around why it defaults to CL.QUORUM in one of those
commits (adding the params to the .yaml), but I'm receptive to an argument that
we shouldn't even have that as a configurable at all to the end user and just
twiddle with it in tests. I can see the idea of users being able to up it to
CL.ALL, or perhaps applying that CL to just writes to the denylist at ALL and
read at QUORUM, but then we're talking about more configurables for diminishing
returns.
{quote}Curious on why we disable denylisting range reads by default
{quote}
All three types are enabled in the .yaml but commented out now.
{quote}what do you think of choosing text (vs blob). Advantage would be
readability of the key
{quote}
I wasn't original author on this but here's my take thinking about it for a
bit. We can either a) make things more readable in the table at the expense of
having a different data type in the DB than is cached in memory and used in the
read / write path, or b) keep the data type the same up and down the entire
stack and push the cost to the end user to convert during their query. I lean
towards b just because this is part of the hot path and I tend to dislike risk
(even the minimal risk of differing data types in memory vs. table and
conversion on load); we can document this (including the CQL to query and
convert to human readable) to work around that little usability friction. wdyt?
{quote}What do you think about adding nodetool commands...
{quote}
Sounds great! I'd prefer we do that work on a followup ticket though as in my
opinion the CQL + JMX combined interface for this should be adequate for
operators on a first implementation.
Thanks for the feedback!
> 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: Josh McKenzie
> 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: [email protected]
For additional commands, e-mail: [email protected]
