cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (Jira)" <>
Subject [jira] [Commented] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches
Date Wed, 18 Aug 2021 13:06:00 GMT


Sam Tunnicliffe commented on CASSANDRA-16404:

bq. I see 4 failures, but they do not seem to be related to these changes.

Yep, LGTM too. Good stuff!

bq. Am I right that currently there are no dtests for JMXPermissionsCache/JmxPermissionsCache
MBeans? Shall I try to come up with a test for that (basically I'd like to get familiar with
dtests)? Can I use this ticket or need to create another one?

Yes, you are correct there, so feel free to use this as an opportunity to get comfortable
with dtests. Seeing as this isn't an urgent issue, I'd say it's fine to take our time adding
new tests here rather than opening another Jira. If you create a dtest branch based off mine,
just open a PR against trunk with it when you're ready and I'll review/merge there. If you
have any questions, just ask.

bq. It needs to be renamed to match the class name.

d'oh, good catch. Fixed in my branch. 

> Provide a nodetool way of invalidating auth caches
> --------------------------------------------------
>                 Key: CASSANDRA-16404
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Feature/Authorization
>            Reporter: Sumanth Pasupuleti
>            Assignee: Aleksei Zotov
>            Priority: Normal
>             Fix For: 4.x
>          Time Spent: 50m
>  Remaining Estimate: 0h
> We currently have nodetool commands to invalidate certain caches like KeyCache, RowCache
and CounterCache. 
> Being able to invalidate auth caches as well can come in handy in situations where, critical
backend auth changes may need to be in effect right away for all the connections, especially
in configurations where cache validity is chosen to be for a longer duration. An example can
be that an authenticated user "User1" is no longer authorized to access a table resource "table1"
and it is vital that this change is reflected right away, without having to wait for cache
expiry/refresh to trigger.

This message was sent by Atlassian Jira

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message