[JIRA] [core] (JENKINS-24155) Jenkins Slaves Go Offline In Large Quantities and Don't Reconnect Until Reboot
Patricia Wright commented on JENKINS-24155 Jenkins Slaves Go Offline In Large Quantities and Dont Reconnect Until Reboot Still happens, daily. Jenkins 1.596.1 with all plugins up to date. 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-24155) Jenkins Slaves Go Offline In Large Quantities and Don't Reconnect Until Reboot
Patricia Wright commented on JENKINS-24155 Jenkins Slaves Go Offline In Large Quantities and Dont Reconnect Until Reboot I will grab a thread dump the next time i see 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/d/optout.
[JIRA] [core] (JENKINS-24155) Jenkins Slaves Go Offline In Large Quantities and Don't Reconnect Until Reboot
Patricia Wright commented on JENKINS-24155 Jenkins Slaves Go Offline In Large Quantities and Dont Reconnect Until Reboot I'm still having this issue. 1.580.2 I have a large number of slaves that reboot as part of our testing process (tests complete, systems shut down). These slaves go offline in this fashion. 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-22932) Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted
Patricia Wright commented on JENKINS-22932 Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted Even after running on LTS I still see this every week. 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-22932) Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted
Patricia Wright edited a comment on JENKINS-22932 Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted I've seen this happen even after recent fixes. Jobs were running on the slaves at the time.. One thing I noticed - linux slaves didn't disconnect, only windows slaves. This was too big of a problem, I went back to LTS. 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] [slave-status-plugin] (JENKINS-22932) Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted
Patricia Wright commented on JENKINS-22932 Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted I've seen this happen even after recent fixes. Jobs were running on the slaves at the time.. This was too big of a problem, I went back to LTS and have not seen it since. 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] [slave-status-plugin] (JENKINS-22932) Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted
Patricia Wright edited a comment on JENKINS-22932 Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted I've seen this happen even after recent fixes. Jobs were running on the slaves at the time.. One thing I noticed - linux slaves didn't disconnect, only windows slaves. This was too big of a problem, I went back to LTS and have not seen it since. 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-24050) All slaves disconnect and no new slaves can connect due to CancelledKeyException in org.jenkinsci.remoting
Patricia Wright commented on JENKINS-24050 All slaves disconnect and no new slaves can connect due to CancelledKeyException in org.jenkinsci.remoting After this change, the slaves no longer disconnect.Instead, the underlying issue causes the slaves to just stop doing whatever they were doing. Running jobs on those slaves hang forever and can not be cancelled. The Jenkins server starts to spam this in the logs until the filesystem fills up: Sep 11, 2014 10:38:13 AM org.kohsuke.stapler.export.Property writeValue WARNING: null org.kohsuke.stapler.export.NotExportableException: class hudson.plugins.parameterizedtrigger.CapturedEnvironmentAction doesn't have @ExportedBean so cannot write hudson.model.Actionable.actions at org.kohsuke.stapler.export.Model.init(Model.java:73) at org.kohsuke.stapler.export.ModelBuilder.get(ModelBuilder.java:51) at org.kohsuke.stapler.export.Property.writeValue(Property.java:231) at org.kohsuke.stapler.export.Property.writeValue(Property.java:187) at org.kohsuke.stapler.export.Property.writeValue(Property.java:139) at org.kohsuke.stapler.export.Property.writeTo(Property.java:116) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:190) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:185) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:185) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:185) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:185) at org.kohsuke.stapler.export.Model.writeTo(Model.java:157) at org.kohsuke.stapler.ResponseImpl.serveExposedBean(ResponseImpl.java:267) at hudson.model.Api.doPython(Api.java:216) at sun.reflect.GeneratedMethodAccessor387.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) 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$4.doDispatch(MetaClass.java:210) 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.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 hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at
[JIRA] [slave-status] (JENKINS-22932) Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted
Patricia Wright commented on JENKINS-22932 Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted It ran for four days, slaves successfully disconnecting and reconnecting, then the problem surfaced again at about 5am this morning. Many jobs were running, and all slaves disconnected at once. Restarting Jenkins brought everything back online. 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] [slave-status] (JENKINS-22932) Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted
Patricia Wright commented on JENKINS-22932 Jenkins slave cannot reconnect to Master once it has been disconnected unless Jenkins is restarted Looks like a regression, or sporadic issue. I'm experiencing this now. In our environment, ubuntu master, windows slaves. Jenkins: 1.572 slave.jar version: 2.43 (the version on the master) java.io.IOException: NioChannelHub is not currently running at org.jenkinsci.remoting.nio.NioChannelHub$1.makeTransport(NioChannelHub.java:446) at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:220) at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:149) at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:159) at org.jenkinsci.remoting.nio.NioChannelBuilder.build(NioChannelBuilder.java:36) at org.jenkinsci.remoting.nio.NioChannelBuilder.build(NioChannelBuilder.java:52) at jenkins.slaves.JnlpSlaveAgentProtocol$Handler.jnlpConnect(JnlpSlaveAgentProtocol.java:120) at jenkins.slaves.DefaultJnlpSlaveReceiver.handle(DefaultJnlpSlaveReceiver.java:63) at jenkins.slaves.JnlpSlaveAgentProtocol2$Handler2.run(JnlpSlaveAgentProtocol2.java:57) at jenkins.slaves.JnlpSlaveAgentProtocol2.handle(JnlpSlaveAgentProtocol2.java:31) at hudson.TcpSlaveAgentListener$ConnectionHandler.run(TcpSlaveAgentListener.java:157) In our environment slaves get disconnected after a suite of tests complete (and revert to a clean vSphere snapshot) and then reconnect. It runs fine for a while, with many disconnects/reconnects. Then starts tossing these exceptions and nothing can connect until a restart. 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] [view-job-filters] (JENKINS-21862) Build Filter (Wrapper) column not properly showing results for Parameterized builds
Patricia Wright created JENKINS-21862 Build Filter (Wrapper) column not properly showing results for Parameterized builds Issue Type: Bug Affects Versions: current Assignee: Jacob Robertson Components: view-job-filters Created: 18/Feb/14 9:33 PM Description: All test jobs are called with the BRANCH parameter. I create a view as follows: New List View Under Job Filters i have nothing checked. I select "Parameterized job filter" from the Add Job Filter dropdown. Under Name: I enter "BRANCH" Under Value: I enter the exact parameter I seek to make this view for. "main" for example (with no quotes of course) Match Type: I select "Include Matched" Under columns, I select Build Filter (Wrapper) Column from the add columns I select "Number of Builds" Repeat for Status and Weather Delete the Number of Builds, Status, and Weather, (last successful, etc..) default columns. Save the view. Now when I look at the view, I see the all of the test jobs that have been run with the BRANCH parameter "main". The bug is that the counts for success/failure/etc..., weather, and status, are not filtered to include only jobs with the parameter I specified. Instead they show the values for all jobs no matter what the parameter. It is as if the Build Filter (Wrapper) Column is doing nothing. I've tried several other permutations of the filter: include all, exclude not matching param. include matching param, exclude not matching param None work. Environment: linux, jenkins 1.550, view job filters 1.26 Project: Jenkins Priority: Major Reporter: Patricia Wright 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-multijob-plugin] (JENKINS-19068) Keep job running until all downstream jobs finish
Patricia Wright commented on JENKINS-19068 Keep job running until all downstream jobs finish In some ways I would categorize this as a bug, not a new feature. It limits the functionality, but more importantly - post-build actions that want to deal with downstream jobs executed by the multijob aren't as useful because they may get kicked off while some of the downstream jobs are running. One way to replicate: create a multijob project that runs three jobs. phase1: example1 job shell command: sleep 30 ; true example2 job shell command: sleep 30 ; true example3 job shell command: false Any post-build actions on the multijob happen when example1 and example2 are running. Here is what I would like to do: Multijob Project with 3 phases: phase 1: Setup a test environment phase 2: Run 10 tests in parallel (or a series of phases for various tests) phase X: ... phase Z: Tear down the test environment. If any of the phase 2 tests fail, multijob exits and phase Z cleanup never happens. There are workarounds (post build trigger that always runs and monitors running jobs, blocking until they are done which then does the real post-build actions) I suggest two checkboxes for each multijob phases: "block until all jobs in this phase are complete" "continue to next phase even if this phase fails" (default, do not continue) 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-multijob-plugin] (JENKINS-19068) Keep job running until all downstream jobs finish
Patricia Wright edited a comment on JENKINS-19068 Keep job running until all downstream jobs finish In some ways I would categorize this as a bug, not a new feature. It limits the functionality, but more importantly - post-build actions that want to deal with downstream jobs executed by the multijob aren't as useful because they may get kicked off while some of the downstream jobs are running. One way to replicate: create a multijob project that runs three jobs. phase1: example1 job shell command: sleep 30 ; true example2 job shell command: sleep 30 ; true example3 job shell command: false Any post-build actions on the multijob happen when example1 and example2 are running. Here is what I would like to do: Multijob Project with many phases: phase 1: Setup a test environment phase 2: Run 10 tests in parallel (or a series of phases for various tests) phase X: ... phase Z: Tear down the test environment. If any of the phase 2 tests fail, multijob exits and phase Z cleanup never happens. There are workarounds (post build trigger that always runs and monitors running jobs, blocking until they are done which then does the real post-build actions) I suggest two checkboxes for each multijob phases: "block until all jobs in this phase are complete" "continue to next phase even if this phase fails" (default, do not continue) 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.
