cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Michalski (JIRA) <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-6768) Refresh permissions cache in ClientState periodically to avoid cache miss stampede effect
Date Tue, 25 Feb 2014 17:42:20 GMT

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

Michał Michalski edited comment on CASSANDRA-6768 at 2/25/14 5:40 PM:
----------------------------------------------------------------------

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.

As ClientState is already coupled with Authorizer, I could imagine pushing the responsibility
to create permissionsCache to IAuthorizer's implementations (actually I believe it should
be there), so the ClientState.initPermissionsCache() could only call a DatabaseDescriptor.getAuthorizer().initPermissionsCache(),
rather than handling it on its own.

Alternatively it could just be a configurable thing (two values: for expiry and refresh, where
-1 or empty value means no refresh / expiry) 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.


was (Author: michalm):
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.

As ClientState is already coupled with Authorizer, I could imagine pushing the responsibility
to create permissionsCache to IAuthorizer's implementations (actually I believe it should
be there), so the ClientState.initPermissionsCache() could only call a DatabaseDescriptor.getAuthorizer().initPermissionsCache(),
rather than handling it on its own.

Alternatively it could be just configurable thing (two values: for expiry and refresh, where
-1 or empty value means no refresh / expiry) 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)

Mime
View raw message