[ 
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401041#comment-17401041
 ] 

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: https://issues.apache.org/jira/browse/CASSANDRA-16404
>             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
(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