commit f5c89c1a6f01aee6295717fb785a4bfbacb8ce86
author Patrick Hiesel <hiesel@google.com> Wed Jan 09 13:45:52 2019 +0100
committer Patrick Hiesel <hiesel@google.com> Thu Jan 10 16:25:31 2019 +0100
tree 7ad9f05775ccf0d9b0a384278eac029c6a698d2e
parent 572f4e3804bd870ed2a4727b161ae47bae5d15ee

Rework SearchingChangeCacheImpl

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