Frequent connection problems between Gradle main and Gradle worker on CI server


(Björn Harmen Gerth) #1

Hello,

we have several multi-project builds which are executed on a Jenkins CI server. Several weeks ago we updated our outdated Gradle 1.1 to 1.11. Since then, every 20th build or so fails because of > Execution failed for task ‘…:test’. > Timeout after waiting 120,0 seconds for Gradle Worker nnn (STARTED, running: true) to connect.

I have pasted an exemplary build output + stacktrace at http://pastebin.com/MMS8TpMv

The error mainly occurs within the test task of a sub project (not always the same sub project), but rarely I noticed failures in compileTestGroovy

Could you give an advice how to analyze this problem further?

Thanks, Björn

P.S.: Out put of gradle -v at Jenkins server: > Gradle 1.11 > Build time:

2014-02-11 11:34:39 UTC > Build number: none > Revision:

a831fa866d46cbee94e61a09af15f9dd95987421 > Groovy:

1.8.6 > Ant:

Apache Ant™ version 1.9.2 compiled on July 8 2013 > Ivy:

2.2.0 > JVM:

1.6.0_34 (Sun Microsystems Inc. 20.9-b04) > OS:

Windows 2003 5.2 amd64


(x1000) #2

We run gradle 1.7 on TeamCity and use the following settings (gradle.properties):

org.gradle.daemon=false
org.gradle.parallel=false
org.gradle.configureondemand=true

and additionally specifying ‘–refresh-dependencies’.

We had problems on CI when using daemon=true, but these are gone.

The only problems we currently have are hardware failures (reboot). If these are happening during a gradle build we observe test and compile failures afterwards (probably some cache corruption).


(Björn Harmen Gerth) #3

Hello steveb and everybody,

I immediately tried the proposed properties, but it didn’t help.

However, our admin noted that a Windows server should be rebooted from time to time (it had already run for 8 months). That we did and the problem appeared only once since then.

Best regards, Björn


(x1000) #4

We reboot our build machines every night and clean all caches (including gradle’s) during this maintenance task (reboot was needed due to problems with old Visual Studio Versions getting slower and slower)…but I don’t get why this makes a difference when the gradle daemon is disabled.