Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-6351

Artifacts with a file size exceeding 2GB are served with negative file size

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Environment:
      Hudson 1.355
    • Similar Issues:
      Show 5 results

      Description

      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.

      Cause:
      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).

      Proposed Solution:
      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.

        Attachments

          Activity

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in stapler User: : mindless Path: trunk/stapler/core/src/main/java/org/kohsuke/stapler/ResponseImpl.java https://stapler.dev.java.net/source/browse/stapler/trunk/stapler/core/src/main/java/org/kohsuke/stapler/ResponseImpl.java?view=diff&rev=1494&p1=trunk/stapler/core/src/main/java/org/kohsuke/stapler/ResponseImpl.java&p2=trunk/stapler/core/src/main/java/org/kohsuke/stapler/ResponseImpl.java&r1=1493&r2=1494 trunk/stapler/core/src/main/java/org/kohsuke/stapler/Stapler.java https://stapler.dev.java.net/source/browse/stapler/trunk/stapler/core/src/main/java/org/kohsuke/stapler/Stapler.java?view=diff&rev=1494&p1=trunk/stapler/core/src/main/java/org/kohsuke/stapler/Stapler.java&p2=trunk/stapler/core/src/main/java/org/kohsuke/stapler/Stapler.java&r1=1493&r2=1494 trunk/stapler/core/src/main/java/org/kohsuke/stapler/StaplerResponse.java https://stapler.dev.java.net/source/browse/stapler/trunk/stapler/core/src/main/java/org/kohsuke/stapler/StaplerResponse.java?view=diff&rev=1494&p1=trunk/stapler/core/src/main/java/org/kohsuke/stapler/StaplerResponse.java&p2=trunk/stapler/core/src/main/java/org/kohsuke/stapler/StaplerResponse.java&r1=1493&r2=1494 Log: JENKINS-6351 Add serveFile() methods using long type for contentLength. Deprecate the forms with int contentLength.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/main/core/pom.xml
          trunk/hudson/main/core/src/main/java/hudson/model/DirectoryBrowserSupport.java
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/30571
          Log:
          [FIXED JENKINS-6351] update DirectoryBrowserSupport to use long for contentLength,
          and update stapler to 1.141 which supports long for contentLength.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/core/pom.xml trunk/hudson/main/core/src/main/java/hudson/model/DirectoryBrowserSupport.java trunk/www/changelog.html http://jenkins-ci.org/commit/30571 Log: [FIXED JENKINS-6351] update DirectoryBrowserSupport to use long for contentLength, and update stapler to 1.141 which supports long for contentLength.
          Hide
          peterreilly peterreilly added a comment -

          Thanks for this, I can confirm that this now works for me.

          Show
          peterreilly peterreilly added a comment - Thanks for this, I can confirm that this now works for me.
          Hide
          swiest Simon Wiest added a comment -

          Hi mindless,

          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?

          Show
          swiest Simon Wiest added a comment - Hi mindless, 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?
          Hide
          peterreilly peterreilly added a comment -

          Yes, I use tomcat.

          Show
          peterreilly peterreilly added a comment - Yes, I use tomcat.
          Hide
          mindless Alan Harder added a comment -

          I think a new issue in the Hudson jira is fine.
          Hudson-winstone is at http://github.com/hudson/winstone

          Show
          mindless Alan Harder added a comment - I think a new issue in the Hudson jira is fine. Hudson-winstone is at http://github.com/hudson/winstone

            People

            • Assignee:
              mindless Alan Harder
              Reporter:
              swiest Simon Wiest
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: