https://gradle.com/ logo
Join Slack
Powered by
```> Timeout waiting to lock Compressed Files E...
# community-support
a
Copy code
> Timeout waiting to lock Compressed Files Expansion Cache (/var/jenkins/workspace/core/.gradle/8.14.3/expanded). It is currently in use by another Gradle instance.
  Owner PID: 4814
  Our PID: 3262
  Owner Operation: 
  Our operation: 
  Lock file: /var/jenkins/workspace/core/.gradle/8.14.3/expanded/expanded.lock
🧵 1
We have high parallelism in a CI (Jenkins) environment, where jobs are run on ephemeral agents.
v
Please do not split topics across several threads. This makes following the conversation in the threads view very hard as the context of the other messages is missing. If you have additional information either edit the original message or post to its thread. Regarding the problem, do you map this 
.gradle
directory into multiple of these ephemeral agents? Then it can quite likely happen that they lock each other out.
a
My apologies, and thanks for the response, Vampire. I'll take a look!
Does Gradle provide any practical examples of how to implement this? The documentation is ambiguous.
My thinking was after initial compilation (i.e. 
compileJava
), that we'd 
rsync
the data from 
$GRADLE_USER_HOME/caches/modules-2
to the 
rootDir/build/cache
and then set that as 
$GRADLE_RO_DEP_CACHE
Or try perhaps have a separate seeding pipeline that populates the caches into docker image which we then pull into the ci-pipeline. Either way, we've only noticed this issue after we migrated to 
8.14.3
from 
7.6.4
v
we've only noticed this issue after we migrated to 
8.14.3
from 
7.6.4
Probably just a coincidence and you just were lucky before that it somehow worked. 🤷‍♂️
The documentation is ambiguous.
If you think so, you should maybe open a documentation issue.
My thinking was after initial compilation (i.e. 
compileJava
), that we'd 
rsync
the data from 
$GRADLE_USER_HOME/caches/modules-2
to the 
rootDir/build/cache
and then set that as 
$GRADLE_RO_DEP_CACHE
Or try perhaps have a separate seeding pipeline that populates the caches into docker image which we then pull into the ci-pipeline.
Doesn't sound like it makes much sense either. In both cases that directory will not be shared between multiple runners, so using it as ro-cache is not too useful. Also, it sounds like you still want to map the 
GRADLE_USER_HOME
into the container and only additionally replicate the dependencies cache to be used as ro-cache. That will not help in any way, you would still have the same problem. The point is, that you do not share the 
GRADLE_USER_HOME
among several agents, but have the ro-dep-cache which you can share. If you bake it into the Docker image, there is also no point in using it as ro-cache, you could simply bake it in within the 
GRADLE_USER_HOME
, that is also not really related to that documented functionality.
3 Views
Open in Slack
PreviousNext
Powered by