[jwrosewell]

For #72

This pull request is based on #71's branch (fix/data-update-schedule-race) because both change DataUpdateServiceDefault.java. It must be retargeted to rc if #71 merges first.

Problem

When a data file says when its next update is available, the data update service schedules the next check for that time plus a random delay of up to MaxRandomisationSeconds seconds (default 600). applyIntervalRandomisation added the random seconds to the interval in whatever unit it was given. getInterval passed seconds and multiplied by 1000, which was right. registerDataFile passed the milliseconds until the update is available, so the random seconds were added as milliseconds and the checks spread over under 0.6 seconds instead of 10 minutes.

Change

applyIntervalRandomisation is now applyIntervalRandomisationMillis. It takes and returns milliseconds and converts the random seconds itself. getInterval is now getIntervalMillis and returns milliseconds without a second conversion. The variable passed to the scheduler is delayMillis, and the javadoc of getIntervalMillis now describes what it returns. Its second caller, the reschedule inside checkForUpdate, already used milliseconds and is unchanged in behaviour.

Verification

New test DataUpdateService_Register_UpdateAvailableRandomDelayInSeconds registers 50 data files whose update is available in one hour, with randomisation of 600 seconds. It checks no delay exceeds the available time by more than the maximum and that the largest exceeds it by more than one second.

• Red, on Store a data file's future before its check can read it #71's code with only the test added: run 42505991323. The test failed on Ubuntu and Windows, "Largest random delay was 587 millis" (595 on the other parameter set).
• Green, with the fix: run 42507036046. DataUpdateServiceTests passed on Ubuntu, and pipeline.engines with the modules it needs (141 tests) passed on Ubuntu and Windows.
• Full pull request build: FULLBUILD

Release note

The random delay before checking for an available update is now spread over up to MaxRandomisationSeconds seconds, as configured.

Outstanding

Whether .NET has the same mismatch has not been checked.