23

While trying to improve performance of my Gradle Android builds, I stumbled across the Gradle Daemon, and have been using it with great success for local builds.

However, when running under Jenkins on Ubuntu 14.04, builds are intermittently failing with:

Starting process 'Gradle Test Executor 2'. Working directory: /tmp/myproject/android/example Command: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Djava.security.manager=worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -ea -cp /data/var/lib/jenkins/.gradle/caches/2.14.1/workerMain/gradle-worker.jar worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 2'
Successfully started process 'Gradle Test Executor 2'
Daemon vm is shutting down... The daemon has exited normally or was terminated in response to a user interrupt.
Starting process 'Gradle Test Executor 3'. Working directory: /tmp/myproject/android/example Command: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Djava.security.manager=worker.org.gradle.process.internal.worker.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -ea -cp /[...]/.gradle/caches/2.14.1/workerMain/gradle-worker.jar worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 3'
----- End of the daemon log -----


FAILURE: Build failed with an exception.

* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.
Error: Failed to run test (./gradlew --console=plain --info test -p myproject).

    FAILURE: Build failed with an exception.

Multiple builds may be running in parallel. If I run a build manually when no other builds are running, I haven't been able to reproduce it. Someone else had this problem, but the recommended solution was just to disable the Gradle Daemon, which I don't want to do. I would think that a large, concurrent build environment would be exactly what Gradle Daemon was intended to optimize.

Or, if I can't make the Gradle Daemon work reliably under Jenkins, why not? Thanks!

Graham
  • 7,431
  • 18
  • 59
  • 84
Will
  • 24,082
  • 14
  • 97
  • 108
  • 1
    Great question, I'm in the exact same boat configuration-wise. I will attempt to reproduce the problem locally and see if I can provide a solution. – Rob Kielty Aug 30 '16 at 13:59
  • Hmm, https://docs.gradle.org/current/userguide/gradle_daemon.html#when_should_i_not_use_the_gradle_daemon – Rob Kielty Aug 30 '16 at 15:31
  • I have the same problem and I can't seem to fix it. I disabled the daemon in all possible ways (flag, environment variable etc.), different Gradle versions, different VM settings ranging from 64m max to 2gb memory. I also tried 2 completely new installations, one on Ubuntu 16.04 and one on Ubuntu 14.04. I finally tried using different Java versions both 7 and 8 (although I really need 8) and both OpenJDK's and Oracle's VMs. Unfortunately nothing works. I would really appreciate a solution for this problem. On a Windows 7 and 10 machine everything runs fine. – Rolf ツ Oct 25 '16 at 21:05

1 Answers1

19

The Gradle Daemon is enabled by default since version 3.0. However, the official documentation until 4.2.1 stated that you shouldn't use the daemon in continuous integration servers.

It is recommended that the Daemon is used in all developer environments. It is recommend to disable the Daemon for Continuous Integration and build server environments.

The Daemon enables faster builds, which is particularly important when a human is sitting in front of the build. For CI builds, stability and predictability is of utmost importance. Using a fresh runtime (i.e. process) for each build is more reliable as the runtime is completely isolated from previous builds.

This recommendations has changed since then, see Disabling the Daemon

Since Gradle 3.0, we enable Daemon by default and recommend using it for both developers' machines and Continuous Integration servers. However, if you suspect that Daemon makes your CI builds unstable, you can disable it to use a fresh runtime for each build since the runtime is completely isolated from any previous builds.

thokuest
  • 5,800
  • 24
  • 36