More observations: I've tried this today with my Windows and it seems that there is a big difference between maxParallelForks 3 and 4. The test consistently passes with 3 is lower value on my VMWare box with 6GB RAM and 2 CPUs. It also consistently fails with maxParallelForks=4. I know that our Windows machines and much better hardware but it seems that especially :launcher:integTest starts a lot of processes and probably hits some I/O threshold where things get noticeably slower. Reducing the throughput at this level seems better/more reliable to me than increasing various timeouts.
My suggestion is to reduce maxParallelForks to 3. Possibly we can do it only for :launcher (and perhaps :toolingApi) where we have these tests that run multiple child processes per test. Other subprojects can live with current settings at the moment. Opinions? -Radim On Sun, Jul 20, 2014 at 9:29 PM, Radim Kubacki <radim.kuba...@gradleware.com > wrote: > We have a few tests that are failing sporadically due to some timeouts: > ToolingApiLoggingCrossVersionSpec."logging is live" is one of them. > CancellingDaemonIntegrationSpec."cancels correct build" seem to fall into > this category too. > > They fail more often on our Windows CI box and the failure are usual when > there is higher CPU load. I added debug logging to see where the time is > spent and here are some numbers (based on > http://builds.gradle.org/viewLog.html?buildId=112016&tab=buildResultsDiv&buildTypeId=Gradle_Master_Coverage_WindowsJava18#testNameId1103271250747874825 > ) > > Output starts at 22:05:08.897 and there will be some time before to spawn > the process. > Daemon setup ends at with '22:05:10.892 [INFO] [ > org.gradle.launcher.daemon.server.exec.ExecuteBuild] Executing build with > daemon context...' > Then there is a gap 1.5s before '22:05:12.333 [INFO] > [org.gradle.BuildLogger] Starting Build' > > Next chunk is '22:05:13.051 [DEBUG] > [org.gradle.initialization.ScriptEvaluatingSettingsProcessor] Timing: > Processing settings took: 0.669 secs' > > Another 1+s to get lock and write build script to a cache - 22:05:14.344 > [DEBUG] > [org.gradle.groovy.scripts.internal.DefaultScriptCompilationHandler] > Timing: Writing script to cache at > C:\tcagent2\work\2d33fa4c6d642769\intTestHomeDir\worker-1\caches\2.1-20140719192339+0000\scripts\build_td6v684jmvp2dj2md0b4vs8dr\ProjectScript\buildscript\classes > took: 0.48 secs > > 3.5s to compile the build script is a biggest part - 22:05:17.864 [DEBUG] > [org.gradle.groovy.scripts.internal.DefaultScriptCompilationHandler] > Timing: Writing script to cache at > C:\tcagent2\work\2d33fa4c6d642769\intTestHomeDir\worker-1\caches\2.1-20140719192339+0000\scripts\build_td6v684jmvp2dj2md0b4vs8dr\ProjectScript\no_buildscript\classes > took: 3.482 secs > > Task is executed soon after (22:05:18.253 [DEBUG] > [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] > Executing actions for task ':t1'.) but it is too late for the test that has > 10secs timeout to read output from the test. > > My questions: > Can we make the test faster? Like adding empty settings.gradle? Can we > speed up script compilation? Do we know what is happening before > '[org.gradle.BuildLogger] Starting Build'? > > Of course I can increase the timeout but before that I'd like to see why > it is not sufficient in some cases. > > -Radim > > > >
