When filtering refs, we previously had two mechanisms for getting change
information somewhat efficiently. If the instance is running as a
master, we used SearchingChangeCacheImpl to get all change information
from the change index. We parsed this and used if for permission
filtering.
In slaves, we scanned the repo and parsed the changes from disk. There
are two reasons for this: (1) we don't have a change index
available in slaves. (2) There was no cross-machine eviction.
In the master, SearchingChangeCacheImpl was disabled by default, so
without manual configuration, we issued one index call for each
list-refs call.
In addition, we accepted potential staleness of the index. If a change
was moved (= the target branch changed) or marked as private and we
missed the change index update, it would still be available in Git.
This commit reworks the way how we retrieve and store change data for
ref filtering:
We remove SearchingChangeCacheImpl and replace it with ChangeRefCache.
ChangeRefCache has a different caching mechanism. The key contains
project, changeId and the SHA1 of the meta ref. This makes it so that we
can spare any custom eviction logic and have the Guava cache do it's
internal eviction purely based on cache size.
This makes the cache suitable for Gerrit slaves as well.
In addition, we adapt the way how we load change information: If the
change index is available, we bootstrap the cache once per JVM for each
project using the index. All subsequent updates are done incrementally
using the persisted ChangeNotesCache. This drastically cuts down on the
number of index calls we do (one per project per instance vs one per
request) while not sacrificing on the benefits. Due to the (comparably)
low number of change updates per instance and the (comparably) high number
of list ref calls, we will do a very small amount of incremental updates
of the cache for any given list ref call.
For slaves that don't have a change index available, we don't do any
bootstrapping for now and will use the ChangeNotesCache as requests come
in. In case this is too slow, we can easily bootstrap the cache in a
slave using a lifecycle listener. This will be added in the future if
there is a need.
Why do we need this cache at all now that we have a ChangeNotesCache?
To efficiently filter change refs, all (or nearly all) of the
information needs to be in-memory. The ChangeNotesCache is rather large
and on googlesource.com we can't hold all of it in memory.
ChangeRefCache has a small enough footprint that we can. This might
very well be true for other Gerrit instances as well. In case it is not,
administrators can choose to disable ChangeRefCache and have their ref
filtering be backed by ChangeNotesCache.
With this commit, we add integration tests for the new cache and remove
complexity from DefaultRefFilter.
Change-Id: I5eda9d411e97925e3e8b450fe32693a936164f96
f5c89c1a6f