[
https://issues.apache.org/jira/browse/MNG-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873752#comment-17873752
]
Daniel Johnson commented on MNG-7868:
-------------------------------------
Well, disclaimer, I do not know the ins-and-outs of how the locking framework
works, how it interacts in the context of the other locking providers
(hazelcast, reddison), or even if it is potentially used for things other than
dependency resolution / artifact transfer. With that in mind, in the context
of failing to acquire a lock in the context due to slow artifact resolution
(meaning maybe this would be a custom wrapping of the root cause exception
within _DefaultArtifactResolver_ alone), may I suggest an error something like:
_Failed to acquire a transfer lock for artifact '<artifact-coordinates>' within
<timeout_value> <timeout_unit>. If seen intermittently, this may be due to a
slow or intermittent server connection. Use '-Daether.syncContext.named.time'
to configure a longer timeout._
You could consider to also add '{_}Please refer to
[https://maven.apache.org/resolver/maven-resolver-named-locks/index.html] for
more information.{_}'{_},{_} but that may be problematic since different
versions of Maven will use different versions of Resolver. And for
[https://maven.apache.org/resolver/maven-resolver-named-locks/index.html]
documentation, it may be useful to have it point users to
[https://maven.apache.org/resolver/configuration.html] for changing the lock
configuration. At least it took me a while to realize even after coming across
this issue and hours of reading the documentation on named locks and finding
numerous instances of this issue reported online, that the 30 second timeout
was configurable.
> "Could not acquire lock(s)" error in concurrent maven builds
> ------------------------------------------------------------
>
> Key: MNG-7868
> URL: https://issues.apache.org/jira/browse/MNG-7868
> Project: Maven
> Issue Type: Bug
> Environment: windows, maven 3.9.4
> Reporter: Jörg Hohwiller
> Priority: Major
> Attachments: MNG-7868-pz_ai_37_lock.txt, MNG-7868-reproduce.txt,
> MNG-7868.zip, image-2024-04-10-15-44-37-013.png, screenshot-1.png
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project foo.bar: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Could not
> acquire lock(s) -> [Help 1]
> {code}
> I am using maven 3.9.4 on windows:
> {code}
> $ mvn -v
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: D:\projects\test\software\mvn
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
> D:\projects\test\software\java
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {code}
> I searched for this bug and found issues like MRESOLVER-332 that first look
> identical or similar but do not really seem to be related so I decided to
> create this issue.
> For this bug I made the following observations:
> * it only happens with concurrent builds: {{mvn -T ...}}
> * is seems to be windows related (at least mainly happens on windows)
> * it is in-deterministic and is not so easy to create an isolated and simple
> project and a reproducible scenario that always results in this error.
> However, I get this very often in my current project with many modules (500+).
> * it is not specific to the maven-install-plugin and also happens from other
> spots in maven:
> I also got this stacktrace:
> {code}
> Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire
> write lock for
> 'C:\Users\hohwille\.m2\repository\.locks\artifact~com.caucho~com.springsource.com.caucho~3.2.1.lock'
> in 30 SECONDS
> at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:202)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:271)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:259)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:352)
> {code}
> See also this related discussion:
> https://github.com/apache/maven-mvnd/issues/836#issuecomment-1702488377
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
