cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C. Scott Andreas (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-6768) Refresh permissions cache in ClientState periodically to avoid cache miss stampede effect
Date Mon, 19 Nov 2018 06:07:02 GMT


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

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

View raw message