[ https://issues.apache.org/jira/browse/CASSANDRA-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
C. Scott Andreas updated CASSANDRA-6768: ---------------------------------------- Component/s: Auth > 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 > Components: Auth > Reporter: Michał Michalski > Assignee: Michał Michalski > Priority: Major > 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 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 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 defining 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 (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org