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] [Updated] (CASSANDRA-6768) Refresh permissions cache in ClientState periodically to avoid cache miss stampede effect
Date Wed, 26 Feb 2014 16:53:19 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michał Michalski updated CASSANDRA-6768:
----------------------------------------

    Description: 
h2. 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.

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  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.

h2. 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 two solutions (updated after comments from [~jjordan]
and [~iamaleksey]):

h3. Make the ClientState's permissionsCache configurable. 

Let's define additional configurable variable called refreshPeriod and make 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 cache 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 its 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 bigger change, it breaks the existing interface, but from my
point of view it's the better choice. 

Of course there's no problem to combine these two options and make the per-Authorizer cache
configurable.

  was:
h2. 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.

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  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.

h2. 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 two solutions (updated after comments from [~jjordan]
and [~iamaleksey]):

h3. Make the ClientState's permissionsCache configurable. 

Let's define additional configurable variable called refreshPeriod and make 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 cache when someone
needs it. Any cons?

h3. Make Authorizer responsible for its own cache

It changes the IAuthorizer


> 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
>
> h2. 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.
> 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  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.
> h2. 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 two solutions (updated after comments from [~jjordan]
and [~iamaleksey]):
> h3. Make the ClientState's permissionsCache configurable. 
> Let's define additional configurable variable called refreshPeriod and make 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 cache 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 its 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 bigger change, it breaks the existing interface, but from
my point of view it's the better choice. 
> Of course there's no problem to combine these two options and make the per-Authorizer
cache configurable.



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

Mime
View raw message