[
https://issues.apache.org/jira/browse/MNG-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762630#comment-17762630
]
Tamas Cservenak edited comment on MNG-7868 at 9/7/23 8:53 AM:
--------------------------------------------------------------
Ideas to try IF "hot artifacts" theory proves right:
For example assume that there is a big multi module build where each module
depend on slf4j-api (HOW it depends does not matter, inherited from parent POM,
directly refd + depMgt, etc, all that matters that effective POM of each module
contains direct dependency on slf4j-api).
1. Refactor the build in following way (very simplified, but only to get the
idea, the goal is really to "prime" local repo and let all the modules enter
the "happy path"):
* introduce new module in reactor like "common-libs", make that one module
depend on slf4j-api, and all the existing module depend on common-libs. This
will cause following:
* all existing modules will be scheduled by smart builder AFTER common-libs is
built
* common-libs will possibly use exclusive lock to get slf4j-api, while all the
others modules will end up on "happy path" (shared lock, as local repo is
primed)
2. OR Resolver code change to reduce the "coarseness" of SyncContext (currently
it causes exclusion for each resolution, ie. both context may resolve 10
artifacts with only one overlapping -- the "hot" one), but this is not gonna
happen in Maven 3.x/Resolver 1.x timeframe, but most probably in Resolver 2.x
that is to be picked up by Maven 4.x.
was (Author: cstamas):
Ideas to try IF "hot artifacts" theory proves right:
For example assume that there is a big multi module build where each module
depend on slf4j-api (HOW it depends does not matter, inherited from parent POM,
directly refd + depMgt, etc, all that matters that effective POM of each module
contains direct dependency on slf4j-api).
1. Refactor the build in following way (very simplified, but only to get the
idea, the goal is really to "prime" local repo and let all the modules enter
the "happy path"):
* introduce new module in reactor like "common-libs", make that one module
depend on slf4j-api, and all the existing module depend on common-libs. This
will cause following:
* all existing modules will be scheduled by smart build AFTER common-libs is
built
* common-libs will possibly use exclusive lock to get slf4j-api, while all the
others modules will end up on "happy path" (shared lock, as local repo is
primed)
2. OR Resolver code change to reduce the "coarseness" of SyncContext (currently
it causes exclusion for each resolution, ie. both context may resolve 10
artifacts with only one overlapping -- the "hot" one), but this is not gonna
happen in Maven 3.x/Resolver 1.x timeframe, but most probably in Resolver 2.x
that is to be picked up by Maven 4.x.
> "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
>
> {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)
