GoogleCloudPlatform / google-cloud-java / 2971 / 2
83%
master: 72%

LAST BUILD BRANCH: resource-manager
DEFAULT BRANCH: master
Ran
Files 379
Run time 18s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 83.153%. First build
2971.2

Pull #1554

travis-ci

web-flow 
Fix race between executor insert and advanceTime

This is a follow up to
https://github.com/GoogleCloudPlatform/google-cloud-java/pull/1552 .

The linked PR has a race condition:
If the ExtensionJobs is added to the queue after the alarm is set up,
it is possible that the alarm would fire before the jobs are added.
Fixing this is easy, just set up the alarm after.
However, doing this consistently deadlocks the tests. Why?

The tests uses a fake executor.
In tests, time does not flow naturally, but is forced to increment,
usually by the executor's `advanceTime` method.
There is a race between the test thread advancing the time and
the mock server thread inserting more tasks to the fake executor.
If the tasks get inserted first, all is well.
Otherwise, `advanceTime` doesn't see the tasks,
and they do not get executed.
The fix is to check the "current time" every time a task is inserted.
If the task is inserted "in the past", we run the task immediately.
Doing this still deadlocks the tests. Why?

The fake executor needs to lock the task queue when registering a task.
If the task is inserted in the past, it also needs to run the task.
Running the task might involve sending a requst to the mock server.
A GRPC thread on the mock server might handle the request by adding more
tasks to the executor.
The executor's queue is locked by the first thread,
resulting in a deadlock.
The fix is to lock the queue just long enough to retrieve a task,
then execute the task without the lock.
Pull Request #1554: Fix race between executor insert and advanceTime

16732 of 20122 relevant lines covered (83.15%)

161.74 hits per line

Source Files on job 2971.2