Howdy, 1. yes, "slow" vs "fast" HW renders absolute time (the lock timeout) somewhat to be interpreted more like "relative" time (which is not), a time that "works" in one env may not work in other :( 2. is this constantly happening? 3. it may depend... do you build with empty or pre-populated (hot) local repository (see below) 4. readlock use was increased in 3.9.1 (and 3.9.2) to support better concurrency. When we introduced locking in 3.9,0 very few locks were "shared" (resolver locking is very similar to java ReadWriteLocks, so there are read/shared and write/exclusive locks), and it resulted in almost a "serialization" of access for "hot" artifacts.
Resolver 1.9.8 (and after) got this commit: https://github.com/apache/maven-resolver/commit/4c5e9ea98f8815c6df8bf26baa9032c8d9cd5f2d As can be seen, installer always uses exclusive locking (as it WRITES to local repo), deployer was laxed to always use shared locking (as it READS local repo to upload remotely), while resolver was made "optimistic" -- if local repo is "warm" (the ideal case), it will acquire shared locks only, but if something needed (or told so, like -U), it will "upgrade". So, what I'd propose to try out: a) try out installAtEnd and deployAtEnd using latest install/deploy plugins (installAtEnd sounds more interesting, as it requires exclusive lock) https://maven.apache.org/plugins/maven-install-plugin/install-mojo.html#installAtEnd https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd As in this case even MT build will "wait" until the last module (1 thread builds a single module), and install will happen from it. Also, as you said, "noop" lock factory is actually no-locking, equivalent to 3.8.x. On Sat, May 27, 2023 at 8:28 AM Dan Tran <dant...@gmail.com> wrote: > Hi > > My multi-threaded build encounters the below failure at the very end of the > build > > *05:26:33* Suppressed: java.lang.IllegalStateException: Attempt > 1: Could not acquire read lock for > 'artifact:ch.qos.logback:logback-classic:1.2.12' in 150 > SECONDS*05:26:33* at > > org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire > (NamedLockFactoryAdapter.java:202)*05:26:33* at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:275)*05:26:33* at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:260)*05:26:33* at > > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies > (DefaultRepositorySystem.java:352)*05:26:33* at > org.apache.maven.project.DefaultProjectDependenciesResolver.resolve > (DefaultProjectDependenciesResolver.java:182)*05:26:33* at > > org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies > (LifecycleDependencyResolver.java:224)*05:26:33* at > > org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies > (LifecycleDependencyResolver.java:136) > > > Some observation > > > 1. Seems to happen only on slow build host/agent > > 2. The failure is 2/3 into the build where logback-classic is the most > common dependency of all modules should be at local already > > 3. Increase lock time not helping > > 4. why readlock? instead of writelock > > > Thought? > > > Thanks > > > -D >
