[JIRA] [core] (JENKINS-23868) Use IE/Chrome/Firefox to download Jenkins artifacts has wrong size but no error reported
Marnix Klooster commented on JENKINS-23868 Use IE/Chrome/Firefox to download Jenkins artifacts has wrong size but no error reported @Daniel Beck: Today I'm adding the --httpKeepAliveTimeout=60 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. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23868) Use IE/Chrome/Firefox to download Jenkins artifacts has wrong size but no error reported
Marnix Klooster commented on JENKINS-23868 Use IE/Chrome/Firefox to download Jenkins artifacts has wrong size but no error reported @Daniel Beck: I don't know about /userContent, and can't easily test. However, just now a colleague encountered a partial download again, for a 300MB file in our NL LAN (so no inter-site communication), downloading from the Jenkins UI (1.565.1), and I noticed in the JavaMelody log the following exception, at the exact time that his download failed, corresponding to the GET request for that download: org.eclipse.jetty.io.EofException: timeout at org.eclipse.jetty.http.AbstractGenerator.blockForOutput(AbstractGenerator.java:520) at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:147) at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:107) at net.bull.javamelody.FilterServletOutputStream.write(FilterServletOutputStream.java:69) at net.bull.javamelody.CounterResponseStream.write(CounterResponseStream.java:82) at org.kohsuke.stapler.Stapler.serveStaticResource(Stapler.java:567) at org.kohsuke.stapler.ResponseImpl.serveFile(ResponseImpl.java:215) at hudson.model.DirectoryBrowserSupport.serveFile(DirectoryBrowserSupport.java:305) at hudson.model.DirectoryBrowserSupport.generateResponse(DirectoryBrowserSupport.java:123) at org.kohsuke.stapler.HttpResponseRenderer$Default.handleHttpResponse(HttpResponseRenderer.java:117) at org.kohsuke.stapler.HttpResponseRenderer$Default.generateResponse(HttpResponseRenderer.java:66) at org.kohsuke.stapler.Function.renderResponse(Function.java:113) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:98) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:120) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:248) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:248) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:248) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:248) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631) at org.kohsuke.stapler.Stapler.service(Stapler.java:225) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:202) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:180) at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:85) at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:89) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99) at
[JIRA] [core] (JENKINS-23868) Use IE/Chrome/Firefox to download Jenkins artifacts has wrong size but no error reported
Marnix Klooster commented on JENKINS-23868 Use IE/Chrome/Firefox to download Jenkins artifacts has wrong size but no error reported We also have this issue. We've seen several instances of this with 1.565.1, from India to a Jenkins master in the Netherlands. Never noticed anything like this with 1.532.2 which we were using before, or any older versions. Funnily enough, we also yesterday had an issue where a build (running on the NL Jenkins master) downloaded (in some Ant build step) a large binary from another Jenkins master running 1.456 (Server: Apache-Coyote/1.1) located in the Philippines, which also resulted in a partial download with no error. No idea what to make of this, but perhaps this helps. Cannot yet reproduce the problem using ab, but haven't yet let it run for a longer period of time... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven-dependency-update-trigger] (JENKINS-9068) Check non snapshot artifacts
Marnix Klooster commented on JENKINS-9068 Check non snapshot artifacts @olamy: Has any work been done on this? How difficult would it be to build this support? In our use of Jenkins+Maven we would find this very useful, to make sure builds are automatically triggered, where we use version ranges to depend on 'any 1.2.x version' of some artifact. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-12759) Archiving failure should make build fail (or unstable)
Marnix Klooster commented on JENKINS-12759 Archiving failure should make build fail (or unstable) I again had something similar, now with 1.480.1. This time it looks even worse. Background: We're doing a build on a slave, which creates big (4 times 700MB) artifacts, and the master archives them to a Windows share. (Note that I introduced both aspects at the same times: until recently these builds were done on the master, and archived on the master's C:-drive. Yes, I'm using Windows.) In this new set-up one of the first builds had its console output end in [antcall] Exiting c:\jenkins-slave\workspace\Installer-trunk-core\build.xml. BUILD SUCCESSFUL Total time: 17 minutes 53 seconds Archiving artifacts and then everything seems to break off: there is no Finished: line at the end. I could find not a single related log message, neither on the master or on the slave. By comparison, a successful build+archive ends thusly: [antcall] Exiting c:\jenkins-slave\workspace\Installer-trunk-core\build.xml. BUILD SUCCESSFUL Total time: 18 minutes 4 seconds Archiving artifacts Recording fingerprints No emails were triggered. Installer-trunk-core-ISO is disabled. Triggering skipped Collecting metadata... Metadata collection done. Finished: SUCCESS I plan to upgrade to 1.509.2 soon. Is there any indication that archiving large files is more reliable currently? Or at least that archiving errors are / can be treated as build failures? (And: If anyone is actually reading this, could they respond, so that I don't feel like I'm reporting issues into thin air? Thanks!) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-12759) Archiving failure should make build fail (or unstable)
Marnix Klooster updated JENKINS-12759 Archiving failure should make build fail (or unstable) For completeness I'm also attaching the original error we got way back when we used 1.409.1: jenkins-1.409.1-archive-artifact-error.txt. Change By: Marnix Klooster (31/Jul/13 8:54 AM) Attachment: jenkins-1.409.1-archive-artifact-error.txt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-16497) Builds with surefire on Windows OS prevent deletion of files with output from tests.
Marnix Klooster commented on JENKINS-16497 Builds with surefire on Windows OS prevent deletion of files with output from tests. We're running into this issue as well, many times. Is there any progress on this issue? Has anyone looked at the V2 patch? Thanks! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-16497) Builds with surefire on Windows OS prevent deletion of files with output from tests.
Marnix Klooster commented on JENKINS-16497 Builds with surefire on Windows OS prevent deletion of files with output from tests. Also, does anyone know of a workaround? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-16474) Slow/hung web UI in 1.483+ (stuck in parseURI)
Marnix Klooster commented on JENKINS-16474 Slow/hung web UI in 1.483+ (stuck in parseURI) @jfigler: I just was pointed to this JIRA issue: we're running 1.480.1, experiencing very slow network connections to the Jenkins UI when a non-trivial number of users is using Jenkins, and until now (running for an afternoon) it looks like the Groovy script from this earlier comment from Feb 7 makes the problem go away. @Jesse Glick: Which LTS version will contain this fix? And is there a way to change the httpKeepAliveTimeout for Winstone more permanently, in 1.480.1? Thanks for your work on this! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-11073) copy artifact fails on windows XP slaves due to failing to set a timestamp
[ https://issues.jenkins-ci.org/browse/JENKINS-11073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162145#comment-162145 ] Marnix Klooster commented on JENKINS-11073: --- Same problem here with 1.22, not with 1.21. Master and slave both run on Windows Server 2008 R2. If you need additional info, just ask. copy artifact fails on windows XP slaves due to failing to set a timestamp -- Key: JENKINS-11073 URL: https://issues.jenkins-ci.org/browse/JENKINS-11073 Project: Jenkins Issue Type: Bug Components: copyartifact, core Affects Versions: current Environment: Windows XP slave. CentOS 5.5 server Reporter: Jeff Koenig Assignee: kutzi Attachments: copyArtifact.txt The copy artifact build step fails when it trys to set the time stamp on windows XP slaves. I have attached the stack trace that shows this error Caused by: java.io.IOException: Failed to set the timestamp of C:\automation\AccuNurse-3.2.0.0-569-upgrade.zip to 131655226 I believe this issue was caused by the changes made for JENKINS-10805. I have also found a discussion of others experiencing the same issue http://groups.google.com/group/jenkinsci-users/browse_thread/thread/249ebeb0660d5e0d/e831b70f5688d0c4?show_docid=e831b70f5688d0c4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
