How to fix error 'could not acquire write lock for 'artifact:org.bytedeco:opencv:4.5.5-1.5.7' ?

Question

depes.edn:

{:deps {org.deeplearning4j/deeplearning4j-nlp {:mvn/version "1.0.0-M2.1"}}}

It happened before in an older Clojure version, but disappeared, see here:

https://clojurians-log.clojureverse.org/tools-deps/2021-09-16

Now I have it back with a recent clojure CLI:
1.11.1.1200

The workarround is still to limit the number of download threads;

clj -Sthreads 1

So it only happens to me using (the default) multi-threaded downloading.

Answer 1

I haven't been able to reproduce this and haven't had any other reports from anyone on this for a while, so not going to create a ticket for now.

Comments

I cannot reproduce neither from work, on a fast network.
I will try again from home later, on a slow line.

---

I can reproduce it  by limiting the bandwidth of my work machine.

So first running:

sudo wondershaper -a eth0 -d 1024 -u 1024

to limit download bandwith to 1MBit/s

and then starting the clj from latest Clojure Docker image

docker run -ti clojure clj -Sdeps '{:deps {org.deeplearning4j/deeplearning4j-nlp {:mvn/version "1.0.0-M2.1"}}}'


fails with:


Downloading: com/twelvemonkeys/imageio/imageio-bmp/3.1.1/imageio-bmp-3.1.1.jar from central
Downloading: org/bytedeco/javacpp/1.5.7/javacpp-1.5.7-linux-arm64.jar from central
Error building classpath. Could not acquire write lock for 'artifact:org.bytedeco:leptonica:1.82.0-1.5.7'
java.lang.IllegalStateException: Could not acquire write lock for 'artifact:org.bytedeco:leptonica:1.82.0-1.5.7'
        at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(N

---

Thanks, I think I understand why we're seeing this again and have some things to look at

Answer 2

Logged as https://clojure.atlassian.net/browse/TDEPS-244

Comments

I can reproduce this:

I'm on Windows, using the Posix launcher under MSYS.  The install script requires a Windows path in the prefix, then it installs fine.

I don't have the problem with the `clj` tool, but rather when running `clojure -M:repl`.

At some point during the download process, downloads just stop.  After a long wait I get the above error message.

My hypothesis is that there's a deadlock somewhere.  NTFS is a lot more picky about file locking than Linuxes are.  I might look there along with the threads...

The workaround described above solves this for me.

---

(I installed temurin-19-jdk on Windows via Scoop and added its bin directory to my path if that matters.)

---

Ahhh-I just noticed the ticket and the progress there.  Thanks for your work on this!

---

Just to add that after nuking ".m2" I got it again on org/bytedeco/mkl/2020.3-1.5.4/mkl-2020.3-1.5.4-linux-x86-redist.jar (which is big)
and indeed "clj -Sthreads 1" fixes it.

---

Hi,

Adding my bit here too, I can reproduce this 100% of the time on my MBP M1.

```
Error building classpath. Could not acquire write lock for 'artifact:org.apache:apache:25'
java.lang.IllegalStateException: Could not acquire write lock for 'artifact:org.apache:apache:25'
    at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:165)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:233)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:212)
...
...
```

```
❯ clj --version
Clojure CLI version 1.11.1.1413
```

```
❯ java --version
openjdk 20.0.2 2023-07-18
OpenJDK Runtime Environment Temurin-20.0.2+9 (build 20.0.2+9)
OpenJDK 64-Bit Server VM Temurin-20.0.2+9 (build 20.0.2+9, mixed mode)
```

---

I've bumped all deps, which includes a pretty big jump and a lot of locking related updates in the Maven resolver, would be curious if there is any difference in these cases you all are experiencing. This version is not released as a stable, but if you are on Mac you can `brew uninstall clojure` then `brew install clojure/tools/clojure@1.11.1.1420` to get the prerelease CLI. Please remove any mods for -Sthreads 1 of course.

---

Not sure it helps, but I had the issue againn tody in latest Clojure:
```
2:46:25 error Downloading: org/bytedeco/mkl/2020.3-1.5.4/mkl-2020.3-1.5.4-linux-x86_64-redist.jar from central
12:46:26 error Error building classpath. Could not acquire write lock for 'artifact:org.bytedeco:mkl:2020.3-1.5.4'
12:46:26 error java.lang.IllegalStateException: Could not acquire write lock for 'artifact:org.bytedeco:mkl:2020.3-1.5.4'
....
```
using 1.11.3.1456

It s inside a Docker build, so I have it reproducible on every container creation
Usual fix works: "-Sthreads 1"

I have in meanwhile upgraded my internet connection to fibre, but it still happens....
So my initial assumption on it happening on "slow networks" is not true.

---

The problem is still present on Clojure 1.12:
Only sometimes, as before.

[2024-09-09T21:19:21.048Z] Downloading: org/bytedeco/mkl/2020.3-1.5.4/mkl-2020.3-1.5.4-linux-x86-redist.jar from central
[2024-09-09T21:19:22.032Z] Error building classpath. Could not acquire write lock for 'artifact:org.bytedeco:mkl:2020.3-1.5.4'
[2024-09-09T21:19:22.032Z] java.lang.IllegalStateException: Could not acquire write lock for 'artifact:org.bytedeco:mkl:2020.3-1.5.4'
    at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire(NamedLockFactoryAdapter.java:165)
[2024-09-09T21:19:22.032Z]
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:233)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:212)
    at o

---

Yeah, I have a partially done upgrade to a new set of Maven libs that I think will help but it’s a big change.

---

In the context of Clojure in Docker, libraries get download  repeatedly.
So I see this "often", and using "-Sthreads 1" in Dockerfiles as default is for me know habit.
It happens far more often then any other random Docker build issue due to "bad network or similar".
So it is in my experience the number 1 reason of failing Docker builds.
I suppose "network issues" get retried in some from, this not.