-
Bug
-
Resolution: Fixed
-
Blocker
-
Windows server 2008 R2 (A VM). 32GB RAM, X5765 @3.07 GHz (6 processors)
Jenkins 1.554.3; 1.565.1;
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>
- is related to
-
-
- Open
-
[JENKINS-23868] Use IE/Chrome/Firefox to download Jenkins artifacts has wrong size but no error reported
I've been experiencing the truncated-download issue, too. No exception was raised.
Setting --httpsKeepAliveTimeout=600000 (10 minutes) so far seems to have solved the problem for me. (Thanks!)
sharon xia
added a comment - I have changed the jenkins to use --httpsKeepAliveTimeout=600000, so far I cannot reproduce this issue even with ab. Thanks Daniel!
sharon xia
added a comment - I have changed the jenkins to use --httpsKeepAliveTimeout=600000, so far I cannot reproduce this issue even with ab. Thanks Daniel! 
Ken Adams
added a comment - Cool, I'll try it out later. Thanks. It concerns me a bit that only marnix_klooster got the timeout exception. Otherwise this would be a straightforward config issue.
@danielbeck: 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.
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.
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?
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.
@Daniel, we didn't see this exception when we met this download issue. Not sure how it helps us to prevent this issue? I guess the only way is to downgrade back to 1.532.2?