Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 26 Feb 2014 17:01:23 +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.109791.1393434083567@arcas>
In-Reply-To: <JIRA.12697144.1393346656221@arcas>
References: <JIRA.12697144.1393346656221@arcas>
Subject: [jira] [Assigned] (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.atla=
ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Micha=C5=82 Michalski reassigned CASSANDRA-6768:
-------------------------------------------

    Assignee: Micha=C5=82 Michalski  (was: Aleksey Yeschenko)

> 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: Micha=C5=82 Michalski
>              Labels: authentication
>
> h2. 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.
> 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  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.
> 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 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 two solutions (updated after comment=
s from [~jjordan] and [~iamaleksey]):
> h3. Make the ClientState's permissionsCache configurable.=20
> Let's define additional configurable variable called refreshPeriod and ma=
ke 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 c=
ache 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 i=
ts 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 big=
ger change, it breaks the existing interface, but from my point of view it'=
s the better choice.=20
> Of course there's no problem to combine these two options and make the pe=
r-Authorizer cache configurable.


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