2e1cb2b849
Instead of using Ehcache for in-memory caches, use Guava. The Guava cache code has been more completely tested by Google in high load production environments, and it tends to have fewer bugs. It enables caches to be built at any time, rather than only at server startup. By creating a Guava cache as soon as it is declared, rather than during the LifecycleListener.start() for the CachePool, we can promise any downstream consumer of the cache that the cache is ready to execute requests the moment it is supplied by Guice. This fixes a startup ordering problem in the GroupCache and the ProjectCache, where code wants to use one of these caches during startup to resolve a group or project by name. Tracking the Gauva backend caches with a DynamicMap makes it possible for plugins to define their own in-memory caches using CacheModule's cache() function to declare the cache. It allows the core server to make the cache available to administrators over SSH with the gerrit show-caches and gerrit flush-caches commands. Persistent caches store in a private H2 database per cache, with a simple one-table schema that stores each entry in a table row as a pair of serialized objects (key and value). Database reads are gated by a BloomFilter, to reduce the number of calls made to H2 during cache misses. In theory less than 3% of cache misses will reach H2 and find nothing. Stores happen on a background thread quickly after the put is made to the cache, reducing the risk that a diff or web_session record is lost during an ungraceful shutdown. Cache databases are capped around 128M worth of stored data by running a prune cycle each day at 1 AM local server time. Records are removed from the database by ordering on the last access time, where last accessed is the last time the record was moved from disk to memory. Change-Id: Ia82d056796b5af9bcb1f219fe06d905c9c0fbc84
56 lines
2.6 KiB
Plaintext
56 lines
2.6 KiB
Plaintext
Release notes for Gerrit 2.5
|
|
============================
|
|
|
|
Gerrit 2.5 is now available:
|
|
|
|
link:http://code.google.com/p/gerrit/downloads/detail?name=gerrit-2.5.war[http://code.google.com/p/gerrit/downloads/detail?name=gerrit-2.5.war]
|
|
|
|
Upgrade Warnings
|
|
----------------
|
|
|
|
Replication
|
|
~~~~~~~~~~~
|
|
|
|
Gerrit 2.5 no longer includes replication support out of the box.
|
|
Servers that reply upon `replication.config` to copy Git repository
|
|
data to other locations must also install the replication plugin.
|
|
|
|
Cache Configuration
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
Disk caches are now backed by individual H2 databases, rather than
|
|
Ehcache's own private format. Administrators are encouraged to clear
|
|
the `'$site_path'/cache` directory before starting the new server.
|
|
|
|
The `cache.NAME.diskLimit` configuration variable is now expressed in
|
|
bytes of disk used. This is a change from previous versions of Gerrit,
|
|
which expressed the limit as the number of entries rather than bytes.
|
|
Bytes of disk is a more accurate way to size what is held. Admins that
|
|
set this variable must update their configurations, as the old values
|
|
are too small. For example a setting of `diskLimit = 65535` will only
|
|
store 64 KiB worth of data on disk and can no longer hold 65,000 patch
|
|
sets. It is recommended to delete the diskLimit variable (if set) and
|
|
rely on the built-in default of `128m`.
|
|
|
|
The `cache.diff.memoryLimit` and `cache.diff_intraline.memoryLimit`
|
|
configuration variables are now expressed in bytes of memory used,
|
|
rather than number of entries in the cache. This is a change from
|
|
previous versions of Gerrit and gives administrators more control over
|
|
how memory is partioned within a server. Admins that set this variable
|
|
must update their configurations, as the old values are too small.
|
|
For example a setting of `memoryLimit = 1024` now means only 1 KiB of
|
|
data (which may not even hold 1 patch set), not 1024 patch sets. It
|
|
is recommended to set these to `10m` for 10 MiB of memory, and
|
|
increase as necessary.
|
|
|
|
The `cache.NAME.maxAge` variable now means the maximum amount of time
|
|
that can elapse between reads of the source data into the cache, no
|
|
matter how often it is being accessed. In prior versions it meant how
|
|
long an item could be held without being requested by a client before
|
|
it was discarded. The new meaning of elapsed time before consulting
|
|
the source data is more useful, as it enables a strict bound on how
|
|
stale the cached data can be. This is especially useful for slave
|
|
servers account and permission data, or the `ldap_groups` cache, where
|
|
updates are often made to the source without telling Gerrit to reload
|
|
the cache.
|