Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.2.1
-
Fix Version/s: Issues to be reviewed for 3.x
-
Component/s: Artifacts and Repositories
-
Labels:None
-
Environment:Windows XP, JDK 1.6, Maven 2.2.1
-
Complexity:Intermediate
-
Number of attachments :
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
Activity
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | Issues to be reviewed for 3.x [ 13145 ] |
MNG-4301 can cause same apparent effects, that is CHECKSUM failures.
In this(MNG-4742) issue however actual artifact corruption is taking place.