Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 26 Feb 2014 16:25:30 +0000 (UTC)
From: =?utf-8?Q?Micha=C5=82_Michalski_=28JIRA=29?= <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12697144.1393346656221.109500.1393431930903@arcas>
In-Reply-To: <JIRA.12697144.1393346656221@arcas>
References: <JIRA.12697144.1393346656221@arcas>
Subject: [jira] [Comment Edited] (CASSANDRA-6768) Refresh permissions cache
 in ClientState periodically to avoid cache miss stampede effect
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-6768?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
13911858#comment-13911858 ]=20

Micha=C5=82 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 o=
n the API reference before, but after reading this: https://code.google.com=
/p/guava-libraries/wiki/CachesExplained it seems that it still not what we'=
re looking for:

bq. refreshAfterWrite will make a key eligible for refresh after the specif=
ied 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 b=
e 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:=20

bq. Refreshes the value associated with key, unless another thread is alrea=
dy 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. Stil=
l need to verify with the code though.


> 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=C5=82 Michalski
>            Assignee: Aleksey Yeschenko
>              Labels: authentication
>
> h3. Background
> We want to password-protect Cassandra by using the built-in PasswordAuthe=
nticator and PasswordAuthorizer. In general we are happy with this solution=
, but after reviewing the code we're a bit afraid of default  permissionsCa=
che 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  cal=
led. However, as we're talking about at least a few hundreds requests to Ca=
ssandra per second, we're afraid of the "stampede" effect once the cache ex=
pires and a number of queries will "trigger" its reload simultaneously duri=
ng 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 eve=
ry N seconds, rather than tens (hundreds?) of them just after the cache exp=
ires 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 exampl=
e.
> Are there any reasons that make this idea a bad one ("you misunderstood G=
uava's Cache" counts too!)?
> [~iamaleksey], I've let myself to assign this issue directly to you, as y=
ou're the author of current solution.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)