[MNG-4742] Multi-threaded artifact resolver corrupts artifacts on download

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Incomplete
• Affects Version/s: 2.2.1
• Component/s: Artifacts and Repositories
• Environment: Windows XP, JDK 1.6, Maven 2.2.1
• Assignee: Unassigned
• Reporter: Cornel Masson
• Created: 27/Jul/10 11:23
• Updated: 02/Jul/14 08:44
• Resolved: 22/Jan/14 20:32

Description

It seems that the artifact resolver is not thread-safe, resulting in corruption of artifacts as they are downloaded.

We have a large build and were seeing numerous CHECKSUM failures, even on Maven jars from Central. On closer inspection, the downloaded JARs themselves appeared corrupted, i.e. it wasn't just corrupt checksums. The other funny thing was that, for each build, it happened on random, different JARs. This happened on JARs from any repository (public, or our own Nexus repo), so it had nothing to do with possible corruptions of our own jars on deploy.

We first tried all the suggestions on the Net, including setting the wagon provider to httpclient. Nothing worked. Then we found the answer:

-Dmaven.artifact.threads=1

As soon as you restrict the artifact resolver to a single thread, the problem goes away (apparently the Maven default is to use up to 5 threads). This looks like a thread-safety issue, with threads perhaps overwriting each other's streams.

What I don't understand is that this bug hasn't surfaced earlier, since we have a standard Maven installation. Note that it happens even when not using Nexus, i.e. when going directly to public repositories.

Issue Links

• depends upon: MNG-4301 Invalid checksums on deploy when using webdav without extension
• duplicates: MNG-4706 Multithreaded building can create bad files for downloaded artifacts in local repository