{"push_id":1348793414,"size":1,"distinct_size":0,"ref":"refs/heads/upstream/stable-2.13","head":"42418b61b8b756490c18927b33a7ee63dd8d7404","before":"f246801bf4c7b76f7a60149b5ea3a0ba8efa834c","commits":[{"sha":"42418b61b8b756490c18927b33a7ee63dd8d7404","author":{"name":"Han-Wen Nienhuys","email":"0c2650fb6e30a927ac8eb10a844256bd02c8d3a8@google.com"},"message":"in WorkQueue, explicitly cancel Runnables that are Futures.\n\nIn LuceneChangeIndex, we schedule the future by calling (essentially)\n\n  MoreExecutors.listeningDecorator(threadPool).submit()\n\nthis returns a TrustedListenableFutureTask, a Future implemented by\nGuava, and we wait on this one.\n\nThe implementation passes this off to ScheduledThreadPoolExecutor for\nrunning. This interprets it as a Runnable in\nAbstractExecutorService#submit(), and a Runnable has no call surface\nfor cancellation. This means that the guava future is never canceled\nif the corresponding ScheduledFutureTask is canceled.\n\nServer#stop shuts down all thread pools. Since the pools are created\nwith\n\n    setExecuteExistingDelayedTasksAfterShutdownPolicy(false)\n\nall pending work is canceled.\n\nThe problem would trigger in the following circumstances:\n\n * For tests that schedule two or more ref updates at the end of the\n   test. Since the interactive pool has size 1, that could delay a\n   piece of work to be delayed.\n\n * Executors are shutdown in creation order, which is random. It would\n   only trigger if the interactive pool was shutdown before the batch\n   pool.\n\nThe problem could be reliably reproduced by building with Bazel,\nsetting shard_count=30 on\n//gerrit-acceptance-tests/src/test/java/com/google/gerrit/acceptance/rest/project:rest_project,\nand running shard 10 (which exhibited the problem) 50-way parallel on\na 12 HT-core system.\n\nThings to note:\n\n* If we have to use ListenableFutures, then it would be nice if we\n  could use a Executor that actually works together well with Guava.\n\n* Server#stop discards pending work. In particular, work scheduled by\n  ReindexAfterUpdate can be discarded, potentially leaving the index\n  inconsistent.\n\n* ReindexAfterUpdate runs in the batch executor, but then schedules\n  its search work on the interactive executor, which is gratuitously\n  parallel.\n\n* WorkQueue.Executor is a lot of cognitive overhead for providing a\n  list of processes. Can't administrators just run jstack?\n\n* A randomized creation order for threadpools causes randomized\n  shutdown order, making problems harder to reproduce.\n\nBug: Issue 4466\nChange-Id: I55c3b85c66433de7ee9e037fc243abe705080bbc\n(cherry picked from commit 405a8f53d30b1902bdce91a3f6fbe555b9e7f473)","distinct":false,"url":"https://api.github.com/repos/openstack-infra/gerrit/commits/42418b61b8b756490c18927b33a7ee63dd8d7404"}]}
{"actor":{"display_login":"openstack-gerrit"}}