archiva-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Not Zippy <>
Subject Re: Uploading large files?
Date Tue, 02 Aug 2011 17:55:13 GMT
Generally there is a cap to the amount of data that is allowed to be
posted (via http) to a server. For example tomcat has maxSavePostSize


On Tue, Aug 2, 2011 at 12:49 PM, Dan Armbrust
<> wrote:
> Well, this is interesting.
> A little background.
> I have an admin account on the archiva server.  The password is
> "expired", but I don't want to change it.  So I haven't changed it,
> and I ignore the change requests.  It still lets me use the GUI.  As a
> side note,  Archiva really shouldn't be enforcing arbitrary password
> policies, IMHO.  Forced password changes are silly even in high
> security places.  And this isn't high security....
> Anyway.  When I was trying to use maven to upload before, it was
> giving me a 401 error.  I (correctly) assumed that it was doing this
> because my password was expired.
> So I created a new account.  I made it a "Repository-Manager".
> And then I tried uploading small files using this new account, and it
> worked fine.
> However, when I try to upload a large file, I get the broken pipe at
> an arbitrary point, and the server reports:
> myip -  -  [02/Aug/2011:17:02:27 +0000] "PUT
> /archiva/repository/apelon-data//com/apelon/va/ihtsdo/wb/snomed/snomed-data/2010.07.31-build1-sct-en-vtmvmp-non-human-2-versioni-junk/
> HTTP/1.1" 401 0 "-" "Apache-Maven/2.2 (Java 1.6.0_25; Linux
> 2.6.31-23-generic) maven-artifact/2.2.1"
> And also:
> 2011-08-02 13:02:27,500 [btpool0-39] INFO
>  -
> Authorization Denied
> [ip=myip,permission=archiva-upload-repository,repo=apelon-data] : no
> matching permissions
> So, somewhere along the way when uploading a large file it would
> appear Archiva gets confused and loses the credentials.
> Probably not related, but I have also noticed that the GUI upload
> suffers from a design flaw with large uploads here too - when the
> upload takes longer than the default session timeout, the session
> times out before the upload completes.  The upload will be processed
> successfully - but the user doesn't know this - because the update
> never comes back to the browser saying that it finished.  In fact, the
> browser stays stuck, waiting for the page to finish loading forever...
> which leads me to suspect that you may have a socket leak on your end
> when you expire a session while a request is still being processed.

View raw message