This change is fixing "All Java build rules should be loaded from
Starlark" warning flagged by latest buildifier version: [1]. Python
rules are now also loaded from the Starlark.
Also extract codemirror library import to BUILD file. This is needed to
avoid cycle in the workspace file, after importing java rules from
Starlark.
[1] https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#native-java
Change-Id: I36192c9465d988b25cf09c250e110f15850910cd
This reverts commit 00fc15ac0073b86270e7c0f40d386f95dfe31e86.
With Caffeine, accessing the cache from the cache loader is causing an
infinite loop [1]. Merging that change up to stable-2.15 exposed that
there is still at least one cache loader (PatchListLoader) accessing its
cache (PatchListCacheImpl).
The test going into an infinite loop on stable-2.15 is
RevisionDiffIT.rebaseHunksOneLineApartFromRegularHunkAreIdentified.
Revert the change until circular dependency is removed or a solution is
found to access the cache from the cache loader.
[1]https://github.com/ben-manes/caffeine/issues/89
Bug: Issue 8464
Change-Id: If65560b4a9bfcf0a03decaedd83ad000c6b28f4f
This deadlock is not the typical deadlock where 2 threads locked a
resource and each one is waiting to lock a second resource already
locked by the other thread. The thread owning the account cache lock is
parked, which tell us that the locked was not released. I could not
determine the exact sequence of events leading to this deadlock making
it really hard to report/fix the problem.
While investigating, I realized that there quite a few reported issues
in Guava that could be major for Gerrit:
Our deadlock happening in account cache
https://bugs.chromium.org/p/gerrit/issues/detail?id=7645
Other deadlock
https://github.com/google/guava/issues/2976https://github.com/google/guava/issues/2863
Performance
https://github.com/google/guava/issues/2063
Race condition
https://github.com/google/guava/issues/2971
Because I could not reproduce the deadlock in a dev environment or in
a unit test making it almost impossible to fix, I considered other
options such as replacing Guava by something else.
The maintainer of Caffeine[1] cache claims that Caffeine is a high
performance[2], near optimal caching library designed/implemented base
on the experience of designing Guava's cache and ConcurrentLinkedHashMap.
I also did some benchmarks about spawning a lot of threads reading/writing
values from the caches. I ran those benchmarks on both Guava and Caffeine
and Guava was always taking at least double the time than Caffeine to
complete all operations.
Migrating to Caffeine is almost a drop-in replacement. Caffeine
interface are very similar to Guava cache and there is an adapter to
migrate to Caffeine and keep using Guava's interfaces. After migrating
to Caffeine, we saw that deadlock occurrence was reduced from once a day
to once every 2 weeks in our production server.
The maintainer of Caffeine, Ben Manes pointed us to the possible
cause[3] of this issue, a bug[4] in the kernel and its fix[5]. Our
kernel version is supposed to have the fix but we will try another OS
and kernel version.
Replacing Guava caches by Caffeine brings 2 things, it reduces the
chances of having the deadlock most likely caused by a kernel bug and
improve the cache performance.
[1]https://github.com/ben-manes/caffeine
[2]https://github.com/ben-manes/caffeine/wiki/Benchmarks
[3]https://groups.google.com/forum/#!topic/mechanical-sympathy/QbmpZxp6C64
[4]b0c29f79ec
[5]76835b0ebf
Bug: Issue 7645
Change-Id: I8d2b17a94d0e9daf9fa9cdda563316c5768b29ae
Reformat the Bazel build files with the buildifier tool [1].
The style is different for Bazel files. Most notably, indentation level
is 4 spaces instead of 2, and " is used instead of '.
[1] https://github.com/bazelbuild/buildifier
Change-Id: I95c0c6f11b6d76572797853b4ebb5cee5ebd3c98
To run the tests:
bazel test //...
To build the Gerrit plugin API, run:
bazel build gerrit-plugin-api:plugin-api_deploy.jar
To build the Gerrit extension API, run:
bazel build gerrit-extension-api:extension-api_deploy.jar
TODOs:
Licenses
Reduce visibility (all public for now)
Generate HTML Documentation
Core plugins
gerrit_plugin() rule to build plugins in tree and standalone modes
GWT UI (only gwt_module() skylark rule is provided, no gwt_binary())
PolyGerrit UI
WAR
Publish artifacts to Maven Central
Ask Bazel team to add Gerrit to their CI on ci.bazel.io
Contributed-By: Han-Wen Nienhuys <hanwen@google.com>
Change-Id: I9a86e670882a44a5c966579cdeb8ed79b1590de3