Timeout waiting to lock artifact cache

Did you try one at a time or both together? We’re using both and haven’t seen the problem since.

And, yes, this does completely defeat the point of a cache, but when it’s a choice of “cached” vs “working”, you have to choose the latter.

Where does this problem fit in the gradleware priority queue? Would be nice to know if there’s hope for a fix on the horizon.

Wow, does I understand it right, that if I have a long running task in my gradle script, e.g. integration test that runs for 15-30 minutes, then during this time no other build can be run? This is exactly the situation we are currently facing. But this is absurd, not? How can I possible run multiple jobs in my CI server with such “single-threadedness” of Gradle??

Just in case, my error follows:

* What went wrong:
A problem occurred configuring root project 'plumbr'.
> Could not resolve all dependencies for configuration ':classpath'.
   > Timeout waiting to lock artifact cache (/home/plumbr/.gradle/caches/modules-2). It is currently in use by another Gradle instance.
     Owner PID: 27
     Our PID: 25807
     Owner Operation: resolve configuration ':classpath'
     Our operation: resolve configuration ':classpath'
     Lock file: /home/plumbr/.gradle/caches/modules-2/modules-2.lock
1 Like

@Nikita: The user cache supports concurrent builds by design and we test for it. As evidenced by this thread, there are some issues though. So far we’ve been unable to replicate the scenario that causes this problem to surface in this way.

We do know that under high contention across long running builds, this problem can occur. What we don’t know is exactly what the lock holding build is doing that prevents it from relinquishing the lock for another build. That is, some operation is locking to coarsely and is not respecting requests to relinquish.

Your options are to lobby for a fix, submit a fix, or distribute builds across different user level cache locations.

+1 for “lobby for a fix”.

We’ve resorted to using a new GRADLE_HOME for every instance. Not at all efficient, but the only option available currently for non-gradle-devs.

I use following method, it works. export GRADLE_USER_HOME=$WORKSPACE/.gradle