Hi, I confirmed I have observed this behavior on some occasions.
Regards JB On Mon, Jun 19, 2023 at 6:19 PM Tamás Cservenák <ta...@cservenak.net> wrote: > > 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 > >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
