opendev/gerrit
Code Issues Proposed changes

Use expireAfterAccess with a larger cache size for ExternalIdCache

Browse Source 
Change-Id: If299a5cc8746cf9e7d59c8e4acf03cb9a29cf02d
This commit is contained in:
Dave Borowitz
2018-06-05 13:30:48 -04:00
parent 6f7fa0a0da
commit 70dfbd6980
2 changed files with 12 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
java/com/google/gerrit/server/account/externalids/ExternalIdModule.java
View File

@@ -18,6 +18,7 @@ import com.google.gerrit.server.account.externalids.ExternalIdCacheImpl.AllExter
import com.google.gerrit.server.account.externalids.ExternalIdCacheImpl.Loader;
import com.google.gerrit.server.cache.CacheModule;
import com.google.inject.TypeLiteral;
import java.time.Duration;
import org.eclipse.jgit.lib.ObjectId;
public class ExternalIdModule extends CacheModule {
@@ -25,21 +26,13 @@ public class ExternalIdModule extends CacheModule {
protected void configure() {
cache(ExternalIdCacheImpl.CACHE_NAME, ObjectId.class, new TypeLiteral<AllExternalIds>() {})
// The cached data is potentially pretty large and we are always only interested
// in the latest value, hence the maximum cache weight is set to 1.
// This can lead to extra cache loads in case of the following race:
// 1. thread 1 reads the notes ref at revision A
// 2. thread 2 updates the notes ref to revision B and stores the derived value
// for B in the cache
// 3. thread 1 attempts to read the data for revision A from the cache, and misses
// 4. later threads attempt to read at B
// In this race unneeded reloads are done in step 3 (reload from revision A) and
// step 4 (reload from revision B, because the value for revision B was lost when the
// reload from revision A was done, since the cache can hold only one entry).
// These reloads could be avoided by increasing the cache size to 2. However the race
// window between reading the ref and looking it up in the cache is small so that
// it's rare that this race happens. Therefore it's not worth to double the memory
// usage of this cache, just to avoid this.
.maximumWeight(1)
// in the latest value. However, due to a race condition, it is possible for different
// threads to observe different values of the meta ref, and hence request different keys
// from the cache. Extend the cache size by 1 to cover this case, but expire the extra
// object after a short period of time, since it may be a potentially large amount of
// memory.
.maximumWeight(2)
.expireFromMemoryAfterAccess(Duration.ofMinutes(1))
.loader(Loader.class);
bind(ExternalIdCacheImpl.class);