[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704348#comment-17704348
]
Tamas Cservenak edited comment on MNG-7705 at 3/23/23 9:39 PM:
---------------------------------------------------------------
Seems we missed few details:
* we had file locking (custom tailored) in TrackingFileManager (way before it
was made into component). It seemed without any reason, and we did remove it
[https://github.com/apache/maven-resolver/commit/fcb6be59c5a5855573886b09c70dab80074a1d27]
* but, it turns out, we have some nice duplication in this area as well, and
surprise, with same custom file locking:
[https://github.com/apache/maven/blob/maven-3.9.x/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java#L204]
and
[https://github.com/apache/maven/blob/maven-3.9.x/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L116]
* Given we all triple-checked resolver (alone, not maven-compat), the
lastUpdated files WITHIN resolver are well protected (assuming locking is
correct). But this is a real game changer, as in a moment something within
build reaches for some compat (maven2 compatibility layer), clash may occur (as
this access happens completely outside of resolver locking)
So, this issue becomes searching the stuff in build that may trigger code in
maven-compat.
was (Author: cstamas):
Seems we missed few details:
* we had file locking (custom tailored) in TrackingFileManager (way before it
was made into component). It seemed without any reason, and we did remote it
[https://github.com/apache/maven-resolver/commit/fcb6be59c5a5855573886b09c70dab80074a1d27]
* but, it turns out, we have some nice duplication in this area as well:
[https://github.com/apache/maven/blob/maven-3.9.x/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java#L204]
and
[https://github.com/apache/maven/blob/maven-3.9.x/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L116]
* Given we all triple-checked resolver (alone, not maven-compat), the
lastUpdated files WITHIN resolver are well protected (assuming locking is
correct).
So, this issue becomes searching the stuff in build that may trigger code in
maven-compat.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---------------------------------------------------------------------------------------------------
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
> Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
> Reporter: Jim Sellers
> Priority: Major
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz, xad-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute
> (ResolveDependenciesMojo.java:103)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependencySourcesMojo.doExecute
> (ResolveDependencySourcesMojo.java:52)
> at org.apache.maven.plugins.dependency.AbstractDependencyMojo.execute
> (AbstractDependencyMojo.java:159)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
