[JIRA] [core] (JENKINS-22758) Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Vivekanand SV commented on JENKINS-22758 Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) I updated to 1.575 and used the latest salve.jar, things are working fine till now. Will update if there are any issues. Vivek. 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-22758) Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Vivekanand SV commented on JENKINS-22758 Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) @koshuke, I am using jenkins version 1.574 and I get this error after upgrade to 1.574 for windows slaves (windows 8 and windows 2008 server, I also have windows 7 and windows 2012 server but they are working fine after jenkins upgrade). How should I get the fix that you mentioned above ? Do I just need to download salve.jar from the node page of the current jenkins and use that ? If yes, I tried that and it didn't work. Any ideas ? Vivek. 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-22758) Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Kohsuke Kawaguchi resolved JENKINS-22758 as Fixed Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) This is fixed in remoting 2.41. Change By: Kohsuke Kawaguchi (09/Jun/14 9:12 PM) Status: Open Resolved Resolution: Fixed 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-22758) Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
klou commented on JENKINS-22758 Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) For us this problem seems to have improved a lot with Jenkins 1.563 and corresponding slave.jar 2.41 on the slaves. It was just a try that we did as JENKINS-22734 seemed to be related and fixed in that version. Somehow we now do not see any more broken slave connections even on high load (on either master or slave). What we still need is to disable the Response Time and Clock Difference preventive monitoring on the nodes->configure page. This is because we've noticed (even with 1.563) that right after launching Jenkins Master the Response Time (of all slaves) is recorded around 1 ms (10 secs). Within the first few minutes after starting the Master the Response Time then slowly decreases to acceptable values of << 500 ms. But if preventive monitoring is on, the slaves are taken down due to the huge values at the beginning and before the Response Time decreases. Our LAN infrastructure is 1 GE connections on the slaves and a 10 GE on the Master (virtualized in a VMWare VM) with all machines directly connected to enterprise-grade backbone core switches of our data center. OS ping times are far below 1 ms. 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-22758) Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Cees Bos updated JENKINS-22758 Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) Reverting to 1.559 solved the issue for us. Version 1.560 also gave memory issues for us. Java heap kept growing. After the upgrade it grew up to the max value we have set. Jenkins became slower and slower. After downgrade to 1.559 memory usage is now below 1Gb heap. Change By: Cees Bos (25/Apr/14 6:04 PM) Attachment: usedMemory.png 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-22758) Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Cees Bos edited a comment on JENKINS-22758 Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) It looks like not only an issue with swarm plugin. Today we did an update to 1.560 (from 1.554). We noticed 2 things: We have a regular restart of the JNLP slaves with a Groovy script executed on the slave itself as soon as the executor is free. Each slave has only 1 executed. There are long running jobs active on the JNLP saves. So normally it waits till the job is completed, then the next item gets executed. But now the restart task got executed right away, and broke the running job. The machine got restarted and then tried to connect again to Jenkins, that fails. We have a number of jnlp slaves, but we don't get them connected anymore. >From the perspective of the slave it shows 'connected', but Jenkins master shows it as still unconnected. We have a Jenkins master on Linux and mix of all kind of slaves. In Jenkins you can click on 'Log' for a node, then there is: JNLP agent connected from /10.1.29.228 But the UI still shows it as offline. 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-22758) Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Cees Bos edited a comment on JENKINS-22758 Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) It looks like not only an issue with swarm plugin. We have a number of jnlp slaves, but we don't get them connected anymore. >From the perspective of the slave it shows 'connected', but Jenkins master shows it as still unconnected. We have a Jenkins master on Linux and mix of all kind of slaves. In Jenkins you can click on 'Log' for a node, then there is: JNLP agent connected from /10.1.29.228 But the UI still shows it as offline. 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-22758) Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Cees Bos commented on JENKINS-22758 Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) It looks like not only an issue with swarm plugin. We have a number of jnlp slaves, but we don't get them connected anymore. >From the perspective of the slave it shows 'connected', but Jenkins master shows it as still unconnected. We have a Jenkins master on Linux and mix of all kind of slaves. 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-22758) Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Michael Prokop created JENKINS-22758 Jenkins >=1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: core, swarm Created: 25/Apr/14 8:09 AM Description: My Jenkins slaves are connected via the swarm plugin (tested with swarm-client-1.10 and swarm-client-1.15), as soon as I upgrade Jenkins master to 1.560 Jenkins jobs very soon die with (quoting Jenkins job output): 09:17:44 FATAL: hudson.remoting.RequestAbortedException: java.nio.channels.ClosedByInterruptException 09:17:44 hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.nio.channels.ClosedByInterruptException 09:17:44 at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) 09:17:44 at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) 09:17:44 at hudson.remoting.Request.call(Request.java:174) 09:17:44 at hudson.remoting.Channel.call(Channel.java:738) 09:17:44 at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168) 09:17:44 at com.sun.proxy.$Proxy57.join(Unknown Source) 09:17:44 at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:951) 09:17:44 at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:137) 09:17:44 at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:97) 09:17:44 at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) 09:17:44 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 09:17:44 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:740) 09:17:44 at hudson.model.Build$BuildExecution.build(Build.java:198) 09:17:44 at hudson.model.Build$BuildExecution.doRun(Build.java:159) 09:17:44 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:519) 09:17:44 at hudson.model.Run.execute(Run.java:1703) 09:17:44 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 09:17:44 at hudson.model.ResourceController.execute(ResourceController.java:88) 09:17:44 at hudson.model.Executor.run(Executor.java:231) 09:17:44 Caused by: hudson.remoting.RequestAbortedException: java.nio.channels.ClosedByInterruptException 09:17:44 at hudson.remoting.Request.abort(Request.java:299) 09:17:44 at hudson.remoting.Channel.terminate(Channel.java:801) 09:17:44 at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) 09:17:44 Caused by: java.nio.channels.ClosedByInterruptException 09:17:44 at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:201) 09:17:44 at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:281) 09:17:44 at hudson.remoting.SocketChannelStream$1.read(SocketChannelStream.java:33) 09:17:44 at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:65) 09:17:44 at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109) 09:17:44 at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) 09:17:44 at java.io.InputStream.read(InputStream.java:101) 09:17:44 at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:81) 09:17:44 at hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:77) 09:17:44 at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2291) 09:17:44 at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2584) 09:17:44 at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2594) 09:17:44 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1317) 09:17:44 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369) 09:17:44 at hudson.remoting.Command.readFrom(Command.java:92) 09:17:44 at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:70) 09:17:44 at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) ... an
