Gradle locks the global script cache during the entire build, causing subsequent builds to fail if scripts change


(VladP) #1

For scripts included with “apply from” gradle uses the cache in user’s home to keep compiled classes. Probably to ensure the same script content is applied throughout the build, a shared lock is kept on this cache for the time it runs. If a build detects the script has changed, it acquires an exclusive lock, updates the cache and goes back to a shared lock. However if there was another build running under the same user, it will fail after the default 1 minute timeout, due to the other build’s shared lock.

In practice this means a change to a shared script will cause all following builds to fail for a user, until all builds that were running during the change have finished.

I can think of a couple of solutions: 1. make the script’s key in the cache a combination of path and file hash/date. A script will have multiple versions in the cache and each build will use the one it needs. 2. copy the cached class(es) to the .gradle folder of the current build. A shared lock on the cache in user’s home will only be kept for the short time of cloning required cache artefacts, 3. ignore the cache if exclusive lock can not be acquired. Compile the script and use it only in the current build. This will slow down builds due to waiting and compiling but eventually the cache will be updated.

When the scenario occurs, a GradleScriptException exception with this message is thrown :

A problem occurred evaluating script.
Could not open buildscript class cache for script 'http://.../?p=build-core;a=blob_plain;f=repository-utils.gradle;hb=HEAD' (/home/build/.gradle/caches/1.6/scripts/_p_build_core_a_blob_plain_f_r_4n9gdhqrjd4inp4c6jive7ql9c/DefaultScript/buildscript).
Timeout waiting to lock buildscript class cache for script 'http://.../?p=build-core;a=blob_plain;f=repository-utils.gradle;hb=HEAD' (/home/build/.gradle/caches/1.6/scripts/_p_build_core_a_blob_plain_f_r_4n9gdhqrjd4inp4c6jive7ql9c/DefaultScript/buildscript). It is currently in use by another Gradle instance.
Owner PID: unknown
Our PID: 15314
Owner Operation: unknown
Our operation:
 Lock file: /home/build/.gradle/caches/1.6/scripts/_p_build_core_a_blob_plain_f_r_4n9gdhqrjd4inp4c6jive7ql9c/DefaultScript/buildscript/cache.properties.lock

(Peter Niederwieser) #2

Are you saying that you are running the same build under the same user from the same workspace multiple times concurrently? If so, what’s the use case?


Daemon stuck: "Waiting to acquire shared lock on daemon addresses registry"
(VladP) #3

No, they’re different builds, different workspaces. Each of our build machine can support 3-6 build agents, they are run under the same user for a couple of reasons, but have different workspaces.

I created an example for the scenario: https://gist.github.com/senoctar/5791149 The setup contains two builds and a shared script. The first build applies the shared script and waits (simulating running tests). The second build makes a change to the shared script (simulating a developer updating the script) and then applies it. These builds can be in completely separate folders and the second build will fail.

Because plain Gist repos can’t have folders, I included a batch file that sets up folders like this: build1.gradle -> build1/build.gradle build2.gradle -> build2/build.gradle applied.gradle -> shared/applied.gradle

The script then starts the two builds.


(Peter Niederwieser) #4

Thanks for the precise explanation. I’ve raised GRADLE-2795.


(ghexsel) #5

Our team uses gradle to start a deployment web server and a deployment “backend” server, both of those can run for very long time. Since there is no way to start threads on the background [1][2], it would be nice if there was a way to prevent locking.

I suspect the cache problem is made worse because we’re using some in-house plugin that adds some parameters based on flags coming from a helper groovy script. Even if nothing really changes, sometimes we get locking on the build scripts and have to stop the servers.

[1]http://stackoverflow.com/questions/7864205/run-javaexec-task-in-background-and-then-terminate-when-build-completes [2]http://issues.gradle.org/browse/GRADLE-1254


(mallikharjun rao) #6

Unable to delete file: ----.gradle\1.10\taskArtifacts\cache.properties.lock. I am getting this exception while running the Build. facing this issue from long time. please share me the permanent fix for this asap.


(Luke Daley) #7

Are you certain this is the same issue?


(mallikharjun rao) #8

Yes this is the same


(mallikharjun rao) #9

Please share the Sonar & Cobertura integration scripts & Documentation to configure in Gradle build asap. I tried the configuration as posted in the https://wiki.jenkins-ci.org/display/JENKINS/Gradle+Plugin?showComments=true&showCommentArea=true#addcommentscript. It seems working but not creating reports. We are using Gradle 1.10. Please help me asap. This is on priority in my project. This is a bottleneck for my work… Its a multi project build…


(Peter Niederwieser) #10

How is your question related to this topic?


(mallikharjun rao) #11

Unable to delete file:

.gradle\1.10\taskArtifacts\cache.properties.lock. If I delete .gradle, cache daemon, native directories some times the issue is resolved. But now its not even working though i deleted the .gradle, cache daemon, native directories. Please privide me the solution asap.


(VladP) #12

You issue seems related to server/build configuration not gradle itself. The most probable scenario is that you run gradle on the same project with different users.


(Roth Jianping) #13

I’d like to vote have it fixed soon! I launch our webapp using one gradle and make changes using another.


(VladP) #14

To vote the issue and for a list of workarounds please go to the linked gradle issue: http://issues.gradle.org//browse/GRADLE-2795


(VladP) #15

To vote the issue and for a list of workarounds please go to the linked gradle issue: http://issues.gradle.org//browse/GRADLE-2795