archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Lustig>
Subject Re: MRM-1351: please advise
Date Fri, 05 Mar 2010 09:29:53 GMT

brettporter wrote:
> On 03/03/2010, at 1:25 AM, Brett Porter wrote:
>> I am interested in getting to the bottom of your core problem though.
>> Have you been able to try the extra debugging I added to see if it logs
>> the error causes?
> Is this the problem you are receiving Marc?

I strongly doubt those users use Maven 3, we use Maven 2.x. So if this
MRM-1356 is due to Maven3-specific logic, then the answer is "no" - our
problem must have a different source.

Well the thing is we were not able to reproduce it. We had a few people of
different projects complaining that Archiva deployed artifacts which proofed
corrupt on download. This can result in severe impacts to the IT-processes
that have been defined here. (We automatically create deployment-packages as
tar-files by retrieving deployment-units (ear, etc.) from Archiva. Sending a
corrupt deployment-package on stage P would result in major trouble, for
both system-availability and people...)

We have some suspicion that the error was caused by the upload-timeout
configured in tomcat. 
But what really is frightening is the fact that the deploy-plugin apparently
did not report an error - at least the result was BUILD SUCCESSFULL (return
code 0). Such case must not occur.
Apparently Archiva signaled "OK" in the DAV-response, although the artifact
was places corruptly.

So, after all, what we need is to ensure such case cannot happen anymore.

First of all we should ensure that Archiva is really picking up the checksum
that is already sent by Wagon in the DAV-request (or one of them) and use it
to verify the artifact's integrity. Deng pointed out that this may not the
case already:

>>  Does Archiva on the other side grab those values from the DAV-request?
<I don't think so.. IIRC, I think Archiva treats them as separate dav

Secondly, I suppose the whole workflow should be checked for consistency.
In my understanding, the process should be like this:

1. Maven/Wagon sends the artifact along with checksums (+ pom +metafiles)
2. Archiva receives the artifact and it in the managed repo
3. Archiva creates a checksum based on the file that already resides in the
managed repo (not some temp. location)
4. Archiva compares this checksum with the checksum that came with Wagon
5.a if the checksums match, return OK as usual
5.b if the checksums do not match, return HTTP error (400?) with some
meaningful error-string the header, and log an ERROR-message to logfile. the
artifact is removed from the managed repo.
6. Maven deploy-plugin picks up the error and consequently reports a BUILD


View this message in context:
Sent from the archiva-dev mailing list archive at

View raw message