[
https://issues.apache.org/jira/browse/CASSANDRA-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911738#comment-13911738
]
Michał Michalski commented on CASSANDRA-6768:
---------------------------------------------
bq. Fetching permissions is potentially an expensive operation - you can't
really rely on authenticator/authorizer being set to
PasswordAuthenticator/CassandraAuthorizer.
OK, that's a good point, but this convinces me even more that the permission
caching strategy should depend on the Authorizer instead of being a bit
"hardcoded" in the ClientState itself.
Alternatively it could be just configurable thing with "safe" defaults...
bq. Even if you could, it's possible to have a huge number of
users/permissions, but only a few active ones, for example.
Yes and that's the case I'm afraid of even more, so this is why I want to have
a single "refresh" in background, rather than a stampede effect on cache
expiry. The larger the permissions number is, the more problem it is to me and
the more I need the "background" refresh.
> 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
> Reporter: Michał Michalski
> Assignee: Aleksey Yeschenko
> Labels: authentication
>
> h3. 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.
> h3. 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.
> h3. Proposed Solution
> 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 replacing this:
> {code}expireAfterWrite(validityPeriod, TimeUnit.MILLISECONDS){code}
> with:
> {code}refreshAfterWrite(refreshPeriod, TimeUnit.MILLISECONDS){code}
> Default refreshPeriod could be the same as the validityPeriod, for example.
> Are there any reasons that make this idea a bad one ("you misunderstood
> Guava's Cache" counts too!)?
> [~iamaleksey], I've let myself to assign this issue directly to you, as
> you're the author of current solution.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
