[ 
https://issues.apache.org/jira/browse/CASSANDRA-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

C. Scott Andreas updated CASSANDRA-6768:
----------------------------------------
    Component/s: Auth

> Refresh permissions cache in ClientState periodically to avoid cache miss 
> stampede effect
> -----------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6768
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6768
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Auth
>            Reporter: Michał Michalski
>            Assignee: Michał Michalski
>            Priority: Major
>              Labels: authentication
>
> h2. Background
> We want to password-protect Cassandra by using the built-in 
> PasswordAuthenticator and PasswordAuthorizer. In general we are happy with 
> this solution, but after reviewing the code we're a bit afraid of default  
> permissionsCache behaviour in org.apache.cassandra.service.ClientState.
> h2. Problem
> From what I understand, at the moment cache expires every N seconds (2 by 
> default) and it gets repopulated when permissionsCache.get() is being  
> called. However, as we're talking about at least a few hundreds requests to 
> Cassandra per second, we're afraid of the "stampede" effect once the cache 
> expires and a number of queries will "trigger" its reload simultaneously 
> during the short period of time when it will be empty.
> h2. Proposed Solutions
> Therefore, instead of the current solution, we'd prefer this cache to be 
> reloaded "in background" every N seconds, so it's only a single request every 
> N seconds, rather than tens (hundreds?) of them just after the cache expires 
> during the period when it's empty.
> In other words, we're thinking about two solutions (updated after comments 
> from [~jjordan] and [~iamaleksey]):
> h3. Make the ClientState's permissionsCache configurable. 
> Let's define additional configurable variable called refreshPeriod and make 
> it 0 by default (0 means no refresh - nothing changes in current code). If 
> it's > 0, add the refreshAfterWrite to the existing code.
> This way we keep the defaults "safe", but add possibility to "tune" the cache 
> when someone needs it. Any cons?
> h3. Make Authorizer responsible for its own cache
> As I said, I believe that Authorizer should be responsible for defining its 
> cache, so I'd prefer to add a getPermissionsCache method to IAuthorizer and 
> get rid of the cache creating code in ClientState. Of course it's a bigger 
> change, it breaks the existing interface, but from my point of view it's the 
> better choice. 
> Of course there's no problem to combine these two options and make the 
> per-Authorizer cache configurable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to