cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Michalski (JIRA) <>
Subject [jira] [Comment Edited] (CASSANDRA-6768) Refresh permissions cache in ClientState periodically to avoid cache miss stampede effect
Date Wed, 26 Feb 2014 16:25:30 GMT


Michał Michalski edited comment on CASSANDRA-6768 at 2/26/14 4:24 PM:

(I spent some time looking at the Guava's LocalCache code and this comment is not relevant
anymore - the cache works as I initially expected)

was (Author: michalm):
It seems that this simple change is not solving our problem. I was basing on the API reference
before, but after reading this:
it seems that it still not what we're looking for:

bq. refreshAfterWrite will make a key eligible for refresh after the specified duration, but
a refresh will only be actually initiated when the entry is queried

So it seems that it still may cause a number of simultaneous refreshes to be run at a time.
I'll have to take a look at the source code to verify it (maybe there's a lock?), but that's
my guess for now. That would be bad :-(

Edit: actually the javadoc for refresh() says: 

bq. Refreshes the value associated with key, unless another thread is already doing so.

So it should be OK. I believe the rest of the requests will still "see" the old value, as
it didn't expired - it's just "marked" to be refreshed. Still need to verify with the code

> Refresh permissions cache in ClientState periodically to avoid cache miss stampede effect
> -----------------------------------------------------------------------------------------
>                 Key: CASSANDRA-6768
>                 URL:
>             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

View raw message