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

Use IE/Chrome/Firefox to download Jenkins artifacts has wrong size but no error reported

    Details

    • Similar Issues:

      Description

      The symptom is:
      When I download a file, e.g. the file size should be 472MB, and at the first few seconds, the progress shows 46.8/472MB and changes with size. Then suddenly the file size because 169/169MB and then finished download without error.

      Meet this issue in IE/Chrome/Firefox. Clear the load download history could resolve it for a while but may have the same issue other other download in other jobs(We have several jobs with the same artifact name)

      Run jenkins with
      <executable>C:\Program Files\Java\jre7\bin\java.exe</executable>
      <arguments>-d64 -Xrs -XX:MaxPermSize=2g -Xmx16g -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=8080</arguments>

        Attachments

        1. resend.jpg
          resend.jpg
          116 kB
        2. test.png
          test.png
          85 kB

          Issue Links

            Activity

            Hide
            marnix_klooster Marnix Klooster added a comment -

            @Daniel Beck: Today I'm adding the --httpKeepAliveTimeout=600000 flag, and we'll see what happens.

            Still, this timeout cannot be the whole story: the report sounds like the problem does not occur with 1.532.3 and before, while it does occur with 1.554.3 and later. (The fact that for me, a remote 1.456 also triggers the problem might be an outlier...?) If the default for httpKeepAliveTimeout has not changed (and I think it is already 5000 for quite some time), and multiple users' networks didn't simultaneously and suddenly deteriorate, then there has to be some other cause.

            Right?

            Finally, we also have seen this problem occurring with 1.565.1 on our local LAN, which is when we got the timeout exception. I'm pretty sure our local LAN not have any real networking problems, but I could be wrong of course, and the timeout occurring on 1.565.1 could be a coincidence which could equally have happened on 1.532.3.

            Show
            marnix_klooster Marnix Klooster added a comment - @ Daniel Beck : Today I'm adding the --httpKeepAliveTimeout=600000 flag, and we'll see what happens. Still, this timeout cannot be the whole story: the report sounds like the problem does not occur with 1.532.3 and before, while it does occur with 1.554.3 and later. (The fact that for me, a remote 1.456 also triggers the problem might be an outlier...?) If the default for httpKeepAliveTimeout has not changed (and I think it is already 5000 for quite some time), and multiple users' networks didn't simultaneously and suddenly deteriorate, then there has to be some other cause. Right? Finally, we also have seen this problem occurring with 1.565.1 on our local LAN, which is when we got the timeout exception. I'm pretty sure our local LAN not have any real networking problems, but I could be wrong of course, and the timeout occurring on 1.565.1 could be a coincidence which could equally have happened on 1.532.3.
            Hide
            danielbeck Daniel Beck added a comment -

            the whole story

            Jetty replaced Winstone as embedded container in 1.535. (CLI and some messages were kept, so it still appears to be winstone, but it's not). So while they're supposed to behave similar, it should be no surprise that details are handled differently.

            Show
            danielbeck Daniel Beck added a comment - the whole story Jetty replaced Winstone as embedded container in 1.535. (CLI and some messages were kept, so it still appears to be winstone, but it's not). So while they're supposed to behave similar, it should be no surprise that details are handled differently.
            Hide
            danielbeck Daniel Beck added a comment -

            Please don't close issues, it's just annoying to change labels.

            Show
            danielbeck Daniel Beck added a comment - Please don't close issues, it's just annoying to change labels.
            Hide
            markewaite Mark Waite added a comment - - edited

            Sorry, I assumed it was desirable to close issues when we believe work is complete on them. Should I resolve issues and never close them as a general practice, or is that specific to certain types of bug reports?

            Show
            markewaite Mark Waite added a comment - - edited Sorry, I assumed it was desirable to close issues when we believe work is complete on them. Should I resolve issues and never close them as a general practice, or is that specific to certain types of bug reports?
            Hide
            danielbeck Daniel Beck added a comment -

            It's done inconsistently so IMO value of closing is doubtful (at least on core issues). Unfortunately it'll prevent any subsequent editing at the moment, including labels. This can lead to annoying reopen-edit-close cycles when fixing labels, hence my recommendation above.

            Maybe I'll be able to convince rtyler to allow editing labels on closed issues. In that case, closing isn't nearly as bad.

            Show
            danielbeck Daniel Beck added a comment - It's done inconsistently so IMO value of closing is doubtful (at least on core issues). Unfortunately it'll prevent any subsequent editing at the moment, including labels. This can lead to annoying reopen-edit-close cycles when fixing labels, hence my recommendation above. Maybe I'll be able to convince rtyler to allow editing labels on closed issues. In that case, closing isn't nearly as bad.

              People

              • Assignee:
                Unassigned
                Reporter:
                sharon_xia sharon xia
              • Votes:
                3 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: