Howdy, It is confirmed that 3.9.2 has issues regarding locking (found and identified, fix underway). So those who really depend on locking, should not use 3.9.2. Please go back to 3.9.1 and wait for 3.9.3 that will be a bit delayed, as we found this issue right in the last curve before release, luckily.
Preparing resolver 1.9.13 with these https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.13 One issue makes resolver "fail fast" problematic code that attempt unsupported "lock upgrade" (MRESOLVER-220), while other simply undo the code change that introduced problematic code. Stay tuned. Thanks T On Wed, May 31, 2023 at 3:03 PM Tamás Cservenák <ta...@cservenak.net> wrote: > 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 >> >
