Make the indexing operation fail upon StorageException(s)

Change 270450 caused the blanking of the Lucene document
upon reindexing if any field caused a StorageException.

Whilst the overall intention was good, the implementation
caused the Lucene index replace operation to continue with
a Document without any fields instead of making the whole
operation fail.

StorageExceptions are thrown when the underlying storage,
being a filesystem or anything else, returns some errors.
Whether the failure is permanent or temporary (e.g. concurrent
GCs, repacking or pruning may cause sporadic StorageException(s))
returning a blank Lucene document was incorrect because, instead
of failing the operation, it was causing the change entry to be
completely removed from the index.

Let the StorageException fail the indexing operation, so that
existing entries may continue to exist, allowing the caller
to retry the operation.

The previous implementation, returning an empty Document, did
not allow any retry, because once the change entry was removed
from the index, it could not be discovered and reindexed anymore
for example by a `gerrit index changes <changenum>`.

Tested manually, applying a randomic StorageException thrown
during the fetching of the ChangeField extensions:

public static Set<String> getExtensions(ChangeData cd) {
  if (new Random().nextBoolean()) {
    throw new StorageException("Simulated storage exception");
  }
  return extensions(cd).collect(toSet());
}

Before this change, every time one change indexing throws a
StorageException, it disappears from the index. Eventually,
all changes will be eliminated and only an off-line reindex
or the reindex of all changes in the project would allow to
recover them.

After this change, some of the indexing operations are
successful and other fails. However, retrying the reindexing
operation would allow to reindex all of them.

Even if the above test case looks strange at first sight,
it simulates a real-life scenario where a low percentage
of indexing operation (0.1%) may fail because of sporadic
StorageExceptions. Before this change, some index entries
were missing on a daily basis (5 to 10 changes per day),
whilst after this change all indexing operation can be
retried and do not result in any indexing entry loss.

Bug: Issue 314113030
Release-Notes: Fail the change reindex operation upon StorageException(s)
Change-Id: Ia121f47f7a68c290849a22dea657804743a26b0d
1 file changed
tree: 107a211651ef2ff625b50926de4005adb93d2376
  1. .settings/
  2. antlr3/
  3. contrib/
  4. Documentation/
  5. e2e-tests/
  6. java/
  7. javatests/
  8. lib/
  9. modules/
  10. plugins/
  11. polygerrit-ui/
  12. prolog/
  13. prologtests/
  14. proto/
  15. resources/
  16. tools/
  17. webapp/
  18. .bazelignore
  19. .bazelproject
  20. .bazelrc
  21. .bazelversion
  22. .editorconfig
  23. .git-blame-ignore-revs
  24. .gitignore
  25. .gitmodules
  26. .gitreview
  27. .mailmap
  28. .pydevproject
  29. .zuul.yaml
  30. BUILD
  31. COPYING
  32. INSTALL
  33. Jenkinsfile
  34. package.json
  35. README.md
  36. rules_nodejs-1.5.patch
  37. SUBMITTING_PATCHES
  38. version.bzl
  39. WORKSPACE
  40. yarn.lock
README.md

Gerrit Code Review

Gerrit is a code review and project management tool for Git based projects.

Build Status

Objective

Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.

Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer.

Documentation

For information about how to install and use Gerrit, refer to the documentation.

Source

Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.

Reporting bugs

Please report bugs on the issue tracker.

Contribute

Gerrit is the work of hundreds of contributors. We appreciate your help!

Please read the contribution guidelines.

Note that we do not accept Pull Requests via the Github mirror.

Getting in contact

The Developer Mailing list is repo-discuss on Google Groups.

License

Gerrit is provided under the Apache License 2.0.

Build

Install Bazel and run the following:

    git clone --recurse-submodules https://gerrit.googlesource.com/gerrit
    cd gerrit && bazel build release

Install binary packages (Deb/Rpm)

The instruction how to configure GerritForge/BinTray repositories is here

On Debian/Ubuntu run:

    apt-get update & apt-get install gerrit=<version>-<release>

NOTE: release is a counter that starts with 1 and indicates the number of packages that have been released with the same version of the software.

On CentOS/RedHat run:

    yum clean all && yum install gerrit-<version>[-<release>]

On Fedora run:

    dnf clean all && dnf install gerrit-<version>[-<release>]

Use pre-built Gerrit images on Docker

Docker images of Gerrit are available on DockerHub

To run a CentOS 7 based Gerrit image:

    docker run -p 8080:8080 gerritforge/gerrit-centos7[:version]

To run a Ubuntu 15.04 based Gerrit image:

    docker run -p 8080:8080 gerritforge/gerrit-ubuntu15.04[:version]

NOTE: release is optional. Last released package of the version is installed if the release number is omitted.