Status: Closed (View Workflow)
When downloading build artifacts from Hudson, files with a size exceeding 2 GB are served with a negative file size in the HTTP header.
This blocks picky HTTP clients from downloading artifacts from Hudson. More forgiving HTTP clients will download the file, but cannnot show any meaningful progress information, because they do not know the total file size in advance.
The class hudson.model.DirectoryBrowserSupport.ContentInfo stores the content length in an int field. The real file size is casted from a long value to int - which limits the file size to some 2 GB (2^31-1 bytes to be exact).
1.) Change field hudson.model.DirectoryBrowserSupport.ContentInfo.contentLength from int to long.
2.) Change method signature of StaplerResponse.serveFile(...) to use long instead of int as length parameter. Note: This requires a change in the Stapler project.
Code changed in hudson
User: : mindless
[FIXED JENKINS-6351] update DirectoryBrowserSupport to use long for contentLength,
and update stapler to 1.141 which supports long for contentLength.
thanks for the swift changes in Hudson and Stapler!
I tried to verify the fix using Hudson 1.357, running in the Winstone container. Alas, serving files larger than 2 GB still did not work (@peterreilly: You are running Hudson in another container, right?).
This problem can be reproduced by placing a file exceeding 2 GB into the HUDSON_HOME/userContents directory. Trying to download this file will then yield error 500 in the browser and the following error message in the console:
[Winstone 2010/05/13 13:50:11] - Untrapped Error in Servlet java.lang.NumberFormatException: For input string: "2399141888" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:461) at java.lang.Integer.parseInt(Integer.java:499) at winstone.WinstoneOutputStream.write(WinstoneOutputStream.java:105) at org.kohsuke.stapler.Stapler.serveStaticResource(Stapler.java:374) at org.kohsuke.stapler.ResponseImpl.serveFile(ResponseImpl.java:124) at hudson.model.DirectoryBrowserSupport.serveFile(DirectoryBrowserSupport.java:279) [...]
Looking at the source code of Winstone (0.9.10-hudson-18), file sizes are assumed to smaller than 2 GB, because lengths, buffer pointers, etc. are stored as integer values.
Of course this is not a Hudson/Stapler problem, but must be solved within Winstone instead. I would therefore suggest to close this issue (
JENKINS-6351) and open another one with a patch request for Winstone.
Does anybody knows, who currently maintains the Hudson-flavoured edition of Winstone? Is there a separate issue tracker for these Winstone editions or is it OK to post the issue here?
I think a new issue in the Hudson jira is fine.
Hudson-winstone is at http://github.com/hudson/winstone
Code changed in stapler
User: : mindless
JENKINS-6351Add serveFile() methods using long type for contentLength.
Deprecate the forms with int contentLength.