0916cc3605
Now that mergeability is checked lazily using a cache upon reindexing, we can ditch the specific mergeability-rechecking codepath and just depend on the cache to load properly. This reduces complexity of background merge checking in a number of pleasant ways: - We don't have to maintain two sets of background threadpools. - Since the cache loader looks at project configuration and runs submit rules, we don't need to guess in the ref update listener whether submit rules might have changed in a way that affects mergeability. If the cache key is the same, it's a hit; if not, it isn't. - No more --recheck-mergeable flag to reindex; checks only happen for those changes that are actually outdated. (We might need to trigger a full mergeability recheck at some point in the future, but we can do that by simply flushing the persistent cache.) - The check interface is pared down; we never actually used arbitrary lists of projects/branches/changes. - The ref updated listener can always use background priority, while callers indexing a single change naturally always use interactive priority. - No manual locking to avoid duplicate work; LoadingCache takes care of that for us. - Mergeable is not used by the reindexing path, so we don't need to explicitly turn off reindexing in that handler. The configuration values for mergeability check threadpool sizes are now used as fallbacks when the index threadpool sizes are not configured. Change-Id: I88ae7f4ad417fcba5495b2a5e4b94adf11e2a21b |
||
|---|---|---|
| .. | ||
| src/test/java/com/google/gerrit/acceptance | ||
| BUCK | ||
| tests.defs | ||