You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@archiva.apache.org by Jesse Farinacci <ji...@gmail.com> on 2012/06/13 16:04:42 UTC

checksum failures

Greetings,

I am using Archiva 1.4-M2 via IBM Java 6 on Linux. During Jenkins
builds, I often see message blocks like:

[INFO] artifact stax:stax-api: checking for updates from archiva
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'561b3c18354a1d64a198591ce93479fcc865ee48'; remote =
'6baba24f8e9bb17d12bb8b19623f21f4451e6147' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'561b3c18354a1d64a198591ce93479fcc865ee48'; remote =
'6baba24f8e9bb17d12bb8b19623f21f4451e6147' - IGNORING

This is most easily reproducible during a build which invokes: mvn -e
-U versions:display-dependency-updates versions:display-plugin-updates

Does anyone have any advice on how to fix this? Thanks,

-Jesse

-- 
There are 10 types of people in this world, those
that can read binary and those that can not.

Re: checksum failures

Posted by Jesse Farinacci <ji...@gmail.com>.
Greetings,

On Thu, Jun 14, 2012 at 10:09 AM, Brett Porter <br...@apache.org> wrote:
> Could you try with 3.0.3? The pre-emptive authentication might have an effect.

That didn't affect things. Using auto-installed Apache Maven 3.0.3
with invocation: mvn -e -U versions:display-dependency-updates
versions:display-plugin-updates

jenkins.build.log:

[INFO] artifact org.apache.derby:derby: checking for updates from archiva
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'307a219b1200b6a5567a27c1f8b9d2158873ce1e'; remote =
'13d4c724c1ea3fea0ce4d36fe1e0e99996565937' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'307a219b1200b6a5567a27c1f8b9d2158873ce1e'; remote =
'13d4c724c1ea3fea0ce4d36fe1e0e99996565937' - IGNORING

archiva.log:

2012-06-14 12:36:55 all guest a.b.c.d
"org/apache/derby/derby/maven-metadata.xml" "Modified File (proxied)"
2012-06-14 12:36:55 all guest a.b.c.d
"org/apache/derby/derby/maven-metadata.xml" "Modified File (proxied)"
2012-06-14 12:36:56 all guest a.b.c.d
"org/apache/derby/derby/maven-metadata.xml" "Created File (proxied)"
2012-06-14 12:36:58 all guest a.b.c.d
"org/apache/derby/derby/maven-metadata.xml" "Modified File (proxied)"
2012-06-14 12:36:58 all guest a.b.c.d
"org/apache/derby/derby/maven-metadata.xml" "Modified File (proxied)"
2012-06-14 12:36:59 all guest a.b.c.d
"org/apache/derby/derby/maven-metadata.xml" "Modified File (proxied)"

access.log:

a.b.c.d - - [14/Jun/2012:12:36:56 -0400] "GET
/repository/all/org/apache/derby/derby/maven-metadata.xml HTTP/1.1"
200 474
a.b.c.d - - [14/Jun/2012:12:36:57 -0400] "GET
/repository/all/org/apache/derby/derby/maven-metadata.xml.sha1
HTTP/1.1" 200 64
a.b.c.d - - [14/Jun/2012:12:36:59 -0400] "GET
/repository/all/org/apache/derby/derby/maven-metadata.xml HTTP/1.1"
200 474
a.b.c.d - - [14/Jun/2012:12:37:00 -0400] "GET
/repository/all/org/apache/derby/derby/maven-metadata.xml.sha1
HTTP/1.1" 200 64

And some investigation into the various repositories and what we have as hashes:

~/data/repositories> find | grep 'org/apache/derby' | grep -v
derby-project | grep -v derbyclient | grep metadata.xml.sha1 | while
read sha ; do cat $sha ; echo "  --  $sha" ; done | sort
35c8220539cf6241988387b428705cdc3f34c175  maven-metadata.xml  --
./repository-external-glassfish/org/apache/derby/derby/maven-metadata.xml.sha1
507fb5cd83e467361df8b770f6ff37af03810fd1  maven-metadata.xml  --
./repository-external-central/org/apache/derby/derby/maven-metadata.xml.sha1
896f95af918cc8b7e54ecd997ebb74a02095143d  maven-metadata.xml  --
./repository-external-central/org/apache/derby/derby/10.8.2.2/maven-metadata.xml.sha1
896f95af918cc8b7e54ecd997ebb74a02095143d  maven-metadata.xml  --
./repository-external-glassfish/org/apache/derby/derby/10.8.2.2/maven-metadata.xml.sha1
b71a91c0b4afa464112a4710dd2b0cf6ebb89f5b  maven-metadata.xml  --
./repository-external-jenkins/org/apache/derby/derby/maven-metadata.xml.sha1
b7a6395e2316183ffeee6ae4c6f7c4e683414fd6  maven-metadata.xml  --
./repository-external-sonatype/org/apache/derby/derby/maven-metadata.xml.sha1
db141276ddfa81dfe05ee5bec342acdf3c244e40  maven-metadata.xml  --
./repository-external-central/org/apache/derby/derby/10.8.1.2/maven-metadata.xml.sha1
db141276ddfa81dfe05ee5bec342acdf3c244e40  maven-metadata.xml  --
./repository-external-glassfish/org/apache/derby/derby/10.8.1.2/maven-metadata.xml.sha1
db141276ddfa81dfe05ee5bec342acdf3c244e40  maven-metadata.xml  --
./repository-external-sonatype/org/apache/derby/derby/10.8.1.2/maven-metadata.xml.sha1

So it's almost like one repository is used to provide the metadata and
another is used to provide the artifact. The /repository/all is just a
list of all repositories defined. I think this is really slowing my
builds down, in addition to clogging up the logs, .. please let me
know what I can do to help resolve this faster.

Thanks,

-Jesse

-- 
There are 10 types of people in this world, those
that can read binary and those that can not.

Re: checksum failures

Posted by Brett Porter <br...@apache.org>.
Could you try with 3.0.3? The pre-emptive authentication might have an effect.

On 14/06/2012, at 11:10 PM, Jesse Farinacci wrote:

> Greetings,
> 
> On Thu, Jun 14, 2012 at 9:04 AM, Brett Porter <br...@apache.org> wrote:
>> Also worth checking which version of Maven you are using?
> 
> Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-220.19.1.el6.x86_64", arch:
> "amd64", family: "unix"
> 
> -Jesse
> 
> -- 
> There are 10 types of people in this world, those
> that can read binary and those that can not.

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter






Re: checksum failures

Posted by Jesse Farinacci <ji...@gmail.com>.
Greetings,

On Thu, Jun 14, 2012 at 9:04 AM, Brett Porter <br...@apache.org> wrote:
> Also worth checking which version of Maven you are using?

Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.32-220.19.1.el6.x86_64", arch:
"amd64", family: "unix"

-Jesse

-- 
There are 10 types of people in this world, those
that can read binary and those that can not.

Re: checksum failures

Posted by Brett Porter <br...@apache.org>.
Also worth checking which version of Maven you are using?

On 14/06/2012, at 11:00 PM, Jesse Farinacci wrote:

> Greetings,
> 
> On Thu, Jun 14, 2012 at 2:31 AM, Brett Porter <br...@apache.org> wrote:
>> I started to see the same thing recently, but not all the time. I need a closer look.
>> 
>> A couple of things to confirm:
>> - is the checksum on disk correct (the .sha1 file in the archiva repository alongside the artifact)?
> 
> I'm not sure.. there are many instances of that artifact. I don't find
> anything in the archiva.log which indicates an error, so this seems to
> be an archiva->maven client problem
> 
>> - do you have the checksum correction consumer enabled or disabled?
> 
> More complete details below, however 'create-missing-checksums' was
> enabled but 'validate-checksums' was not.
> 
>> - is this repository proxying another, and if so, what is its checksum policy?
> 
> Yes, it is proxying many other repositories. I believe they are all set to
> 
>> This looks like it's on the maven-metadata.xml file for stax/stax-api, but it doesn't correlate to the one in the main maven repositories. Perhaps the metadata and its checksum are out of sync?
> 
> Previously, we had all consumers enabled except 'repository-purge' and
> 'validate-checksums'. I've enabled both of those now, so hopefully
> that can fix the problem. Here's the current table:
> 
> Enabled?	ID	Description
> enabled	auto-remove	Automatically Remove File from Filesystem.
> enabled	auto-rename	Automatically rename common artifact mistakes.
> enabled	create-archiva-metadata	Create basic metadata for Archiva to
> be able to reference the artifact
> enabled	create-missing-checksums	Create Missing and/or Fix Invalid
> Checksums (.sha1, .md5)
> enabled	duplicate-artifacts	Check for Duplicate Artifacts via SHA1 Checksums
> enabled	index-content	Indexes the repository to provide search and IDE
> integration features
> enabled	metadata-updater	Update / Create maven-metadata.xml files
> enabled	repository-purge	Purge repository of old snapshots
> enabled	validate-checksums	Validate checksums against file.
> 
> Lots of stuff is being purged at present. I'll let it go through a few
> hours of catch up, and then try again.
> 
> -Jesse
> 
> -- 
> There are 10 types of people in this world, those
> that can read binary and those that can not.

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter






Re: checksum failures

Posted by Jesse Farinacci <ji...@gmail.com>.
Greetings,

On Thu, Jun 14, 2012 at 2:31 AM, Brett Porter <br...@apache.org> wrote:
> I started to see the same thing recently, but not all the time. I need a closer look.
>
> A couple of things to confirm:
> - is the checksum on disk correct (the .sha1 file in the archiva repository alongside the artifact)?

I'm not sure.. there are many instances of that artifact. I don't find
anything in the archiva.log which indicates an error, so this seems to
be an archiva->maven client problem

> - do you have the checksum correction consumer enabled or disabled?

More complete details below, however 'create-missing-checksums' was
enabled but 'validate-checksums' was not.

> - is this repository proxying another, and if so, what is its checksum policy?

Yes, it is proxying many other repositories. I believe they are all set to

> This looks like it's on the maven-metadata.xml file for stax/stax-api, but it doesn't correlate to the one in the main maven repositories. Perhaps the metadata and its checksum are out of sync?

Previously, we had all consumers enabled except 'repository-purge' and
'validate-checksums'. I've enabled both of those now, so hopefully
that can fix the problem. Here's the current table:

Enabled?	ID	Description
enabled	auto-remove	Automatically Remove File from Filesystem.
enabled	auto-rename	Automatically rename common artifact mistakes.
enabled	create-archiva-metadata	Create basic metadata for Archiva to
be able to reference the artifact
enabled	create-missing-checksums	Create Missing and/or Fix Invalid
Checksums (.sha1, .md5)
enabled	duplicate-artifacts	Check for Duplicate Artifacts via SHA1 Checksums
enabled	index-content	Indexes the repository to provide search and IDE
integration features
enabled	metadata-updater	Update / Create maven-metadata.xml files
enabled	repository-purge	Purge repository of old snapshots
enabled	validate-checksums	Validate checksums against file.

Lots of stuff is being purged at present. I'll let it go through a few
hours of catch up, and then try again.

-Jesse

-- 
There are 10 types of people in this world, those
that can read binary and those that can not.

Re: checksum failures

Posted by Brett Porter <br...@apache.org>.
I started to see the same thing recently, but not all the time. I need a closer look.

A couple of things to confirm:
- is the checksum on disk correct (the .sha1 file in the archiva repository alongside the artifact)?
- do you have the checksum correction consumer enabled or disabled?
- is this repository proxying another, and if so, what is its checksum policy?

This looks like it's on the maven-metadata.xml file for stax/stax-api, but it doesn't correlate to the one in the main maven repositories. Perhaps the metadata and its checksum are out of sync?

Cheers,
Brett

On 14/06/2012, at 12:04 AM, Jesse Farinacci wrote:

> Greetings,
> 
> I am using Archiva 1.4-M2 via IBM Java 6 on Linux. During Jenkins
> builds, I often see message blocks like:
> 
> [INFO] artifact stax:stax-api: checking for updates from archiva
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> '561b3c18354a1d64a198591ce93479fcc865ee48'; remote =
> '6baba24f8e9bb17d12bb8b19623f21f4451e6147' - RETRYING
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> '561b3c18354a1d64a198591ce93479fcc865ee48'; remote =
> '6baba24f8e9bb17d12bb8b19623f21f4451e6147' - IGNORING
> 
> This is most easily reproducible during a build which invokes: mvn -e
> -U versions:display-dependency-updates versions:display-plugin-updates
> 
> Does anyone have any advice on how to fix this? Thanks,
> 
> -Jesse
> 
> -- 
> There are 10 types of people in this world, those
> that can read binary and those that can not.

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter