[JIRA] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Richard Mortimer commented on JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed @Arnt Witteveen I agree it would be nice if it could withstand a network outage of a minute or so but there are a few technical challenges to overcome which make this non-trivial. In theory things should survive for a brief network outage and indeed they do on a linux-to-linux master/slave arrangement but windows seems to be much more aggressive in closing down TCP connections and hence the windows side of things has gone before the network connection has been restored. I believe that making the low level protocol cope with a break of the TCP connection is non-trivial. 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] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Daniel Beck commented on JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed temporary network outage of half a minute What kind of real network has regular outages like that? I'd try to discuss SLA with network admins A few workarounds to this issue: Jenkins Enterprise by Cloudbees (Jenkins + commercial plugins and support) offers a "long running builds plugin" that can survive disconnects, master restarts, etc: http://release-notes.cloudbees.com/product/CloudBees+Long-Running+Build+Plugin Something similar will be made available for free as part of the workflow plugin: https://github.com/jenkinsci/workflow-plugin 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] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Arnt Witteveen commented on JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed Thinking about this some more, I still think it would be nice that a temporary network outage of half a minute or so : does not abort a build (that may have been halfway through a build process of several hours). I wouldn't mind seeing, in the log on the server, a message saying network was out, log may be missing a part here in the middle of the log, but why stop the build completely right away? Even in cases where the slave needs the server, there's little point in aborting the build, because the slave is not going to get new work from the server if it can't connect to it anyway? does not cause the client to be offline for that long. If the server receives a new connection attempt of a slave node, and there already is a connection of the same slave node, who not just disconnect the old connection and continue with the new one? 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] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Arnt Witteveen commented on JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed You are correct that this was a network issue: after some time I noticed this always happened around 9PM and mentioned this to a network admin. He said that something similar had happened once, and we let a ping run for a whole day. It seems that there were some network interruptions (of up to a minute IIRC) at the specific time this happened. The machine got switched to another port on the router (or another router), and the issue has not reoccurred since. Sorry for not mentioning this earlier, I forgot about having logged 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] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Richard Mortimer commented on JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed I have been seeing similar problems to this. In my situation one of my slaves is a Windows 7 desktop computer that is set to suspend after a period of inactivity. I've had this running for a few years without problem and the slave has always reconnected successfully when the desktop is woken up. However since the NIO selector thread has been introduced the slaves have ended up being offline for prolonged periods of time and require a manual restart of the Jenkins slave service to bring them back online (see JENKINS-24272). One other symptom that I have observed during testing of this is the server rejecting connections similar to that reported here namely: Jul 16, 2014 9:07:06 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: The server rejected the connection: XXX is already connected to this master. Rejecting this connection. java.lang.Exception: The server rejected the connection: XXX is already connected to this master. Rejecting this connection. at hudson.remoting.Engine.onConnectionRejected(Engine.java:304) at hudson.remoting.Engine.run(Engine.java:276) Having investigated I'm seeing that the slave has decided that the connection is broken and has tore down its TCP connection to the master but the master never sees the TCP RST for this so it continues to retry the TCP packets for 10 or so minutes until the TCP connection times out and then the master tears down the connection. The really strange this is that this behaviour seems to be different between NIO and threaded methods on the master. With threaded the TCP RST is sent by W7 and kills the connection before the slave reconnects but in NIO no RST is ever sent. That happens down at the network packet level so it shouldn't really be affected by NIO but I wonder if it a slight different configuration in the network stack (non-blocking vs blocking) that causes the different behaviour. I also suspect that this may be related to the change to re-start JNLP slaves using a new JVM rather than just restarting in the same process. It may be that the Windows TCP stack just immediately forgets the old TCP socket when the old JVM process exits and hence ignores retries rather than RSTing the connection. I'm planning on waiting for the current crop of JNLP slave fixes to get integrated and will then experiment a bit further to see if I can work out what is stopping the NIO selector getting notified that the slave has closed the TCP connection. 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] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Kohsuke Kawaguchi commented on JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed Thanks for the detailed log analysis. I agree with your order of events list, although there are some details that are still suspicious. For example, if the client has decided to shutdown the connection and that properly arrived at the server, we should see something other than "java.io.IOException: Operation timed out" in the read. And we don't set any read timeout, so I'm puzzled as to why we see this exception during the read. In any case, according to that theory, the first event that caused this is the following: Jul 16, 2014 9:01:57 PM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.net.SocketException: Software caused connection abort: recv failed at java.net.SocketInputStream.socketRead0(Native Method) This appears to be an error unique to Windows, and I found this stackoverflow conversation helpful to understand what it means, as well as this KB article. If I understand this error correctly, it means that Jenkins slave has given WinSock some data to send, and WinSock has sent some packets over the network, but it's not getting the data through to the other side, and so it has given up and declared the connection lost. That happens much later after the write is called, so the next read that came in gets hit by this problem. The links I mentioned above do not really discuss what that "data transmission time-out" is about. It could be anything from WinSock not getting TCK ACK from the other side, TCP flow control, or self-imposed timeout unique to WinSock. I'd have normally suspected the network issue, but the succssive reconnection attempts seem to exclude this possibility. Another possibility could be that this is related to issues like JENKINS-24050, where an unrelated problem kills the NIO selector thread. When that happens, all the sockets stopped getting serviced, so data that the client sent will not be picked up by the application on the server side. TCP ACK should still come in this case, since kernel is getting the packets all right, but perhaps in this situation WinSock might decide to time out, perhaps due to a self-imposed timeout. This would need some experiments. I've just fixed JENKINS-24050, so if possible I'd love to have you try this fix, which should make it into 1.580. Another useful test is to disable the use of NIO on the server side for managing JNLP slaves with the system property '-Djenkins.slaves.NioChannelSelector.disabled=true' on the master. If the problem goes away with it, that'd be an useful input. For anyone else seeing problems, please check relevant logs on both the server and the slave and share it with us, so that we can resolve this problem efficiently. 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] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Arnt Witteveen created JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed Issue Type: Bug Assignee: Unassigned Components: master-slave Created: 17/Jul/14 8:59 AM Description: I have a similar issue to JENKINS-14332, although that says there is no problem on a windows slave (because it eventually reconnects?), so I'm logging this seperatly. The message "hudson.remoting.ChannelClosedException: channel is already closed" breaks my builds on a windows slave. It doesn't happen on every build, but a nightly run of 7 builds seems to have at least one each time. Because these seem to be connection issues, so might be imeout related, here's some setup info, even though I doubt it will be relevant: all those builds are matrix builds. My setup consist of an OSX master YYY that does the build for the 'mac' axis, and a slave XXX that does the build of the 'windows' axis. The windows machine is significantly slower than the mac, so some the builds spend quite some time in a state of '1 axis done, other axis queued'. I don't really see issues here, it seems to work fine for most of the builds most of the time: e.g. these 7 builds are all queued at 20:00, and the example below fails shortly after 21:00, but other builds finish fine later on (so after a longer wait). The failing build on XXX started at 20:50, so it fails after 17 minutes. Other, later and earlier builds run for an hour without problems. In the middle of a build, the build log suddenly says: == 21:07:10 FATAL: channel is already closed 21:07:10 hudson.remoting.ChannelClosedException: channel is already closed 21:07:10 at hudson.remoting.Channel.send(Channel.java:541) 21:07:10 at hudson.remoting.Request.call(Request.java:129) 21:07:10 at hudson.remoting.Channel.call(Channel.java:739) 21:07:10 at hudson.EnvVars.getRemote(EnvVars.java:404) 21:07:10 at hudson.model.Computer.getEnvironment(Computer.java:912) 21:07:10 at jenkins.model.CoreEnvironmentContributor.buildEnvironmentFor(CoreEnvironmentContributor.java:29) 21:07:10 at hudson.model.Run.getEnvironment(Run.java:2250) 21:07:10 at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:907) 21:07:10 at org.jenkinsci.plugins.tokenmacro.impl.EnvironmentVariableMacro.evaluate(EnvironmentVariableMacro.java:23) 21:07:10 at org.jenkinsci.plugins.tokenmacro.DataBoundTokenMacro.evaluate(DataBoundTokenMacro.java:189) 21:07:10 at org.jenkinsci.plugins.tokenmacro.TokenMacro.expand(TokenMacro.java:182) 21:07:10 at org.jenkinsci.plugins.tokenmacro.TokenMacro.expand(TokenMacro.java:154) 21:07:10 at org.jenkinsci.plugins.buildnamesetter.BuildNameSetter.setDisplayName(BuildNameSetter.java:50) 21:07:10 at org.jenkinsci.plugins.buildnamesetter.BuildNameSetter.access$000(BuildNameSetter.java:26) 21:07:10 at org.jenkinsci.plugins.buildnamesetter.BuildNameSetter$1.tearDown(BuildNameSetter.java:42) 21:07:10 at hudson.model.Build$BuildExecution.doRun(Build.java:171) 21:07:10 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:535) 21:07:10 at hudson.model.Run.execute(Run.java:1732) 21:07:10 at hudson.matrix.MatrixRun.run(MatrixRun.java:146) 21:07:10 at hudson.model.ResourceController.execute(ResourceController.java:88) 21:07:10 at hudson.model.Executor.run(Executor.java:234) 21:07:10 Caused by: java.io.IOException: Failed to abort 21:07:10 at org.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:195) 21:07:10 at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:581) 21:07:10 at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) 21:07:10 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) 21:07:10 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 21:07:10 at java.util.concurrent.FutureTask.run(FutureTask.java:138) 21:07:10 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) 21:07:10 at
[JIRA] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Arnt Witteveen updated JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed Change By: Arnt Witteveen (17/Jul/14 9:00 AM) Description: IhaveasimilarissuetoJENKINS-14332,althoughthatsaysthereisnoproblemonawindowsslave(becauseiteventuallyreconnects?),soImloggingthisseperatly.Themessagehudson.remoting.ChannelClosedException:channelisalreadyclosedbreaksmybuildsonawindowsslave.Itdoesnthappenoneverybuild,butanightlyrunof7buildsseemstohaveatleastoneeachtime.Becausetheseseemtobeconnectionissues,somightbeimeoutrelated,heressomesetupinfo,eventhoughIdoubtitwillberelevant:allthosebuildsarematrixbuilds.MysetupconsistofanOSXmasterYYYthatdoesthebuildforthemacaxis,andaslaveXXXthatdoesthebuildofthewindowsaxis.Thewindowsmachineissignificantlyslowerthanthemac,sosomethebuildsspendquitesometimeinastateof1axisdone,otheraxisqueued.Idontreallyseeissueshere,itseemstoworkfineformostofthebuildsmostofthetime:e.g.these7buildsareallqueuedat20:00,andtheexamplebelowfailsshortlyafter21:00,butotherbuildsfinishfinelateron(soafteralongerwait).ThefailingbuildonXXXstartedat20:50,soitfailsafter17minutes.Other,laterandearlierbuildsrunforanhourwithoutproblems.Inthemiddleofabuild,thebuildlog (asseenonthemaster) suddenlysays:==21:07:10FATAL:channelisalreadyclosed21:07:10hudson.remoting.ChannelClosedException:channelisalreadyclosed21:07:10 athudson.remoting.Channel.send(Channel.java:541)21:07:10 athudson.remoting.Request.call(Request.java:129)21:07:10 athudson.remoting.Channel.call(Channel.java:739)21:07:10 athudson.EnvVars.getRemote(EnvVars.java:404)21:07:10 athudson.model.Computer.getEnvironment(Computer.java:912)21:07:10 atjenkins.model.CoreEnvironmentContributor.buildEnvironmentFor(CoreEnvironmentContributor.java:29)21:07:10 athudson.model.Run.getEnvironment(Run.java:2250)21:07:10 athudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:907)21:07:10 atorg.jenkinsci.plugins.tokenmacro.impl.EnvironmentVariableMacro.evaluate(EnvironmentVariableMacro.java:23)21:07:10 atorg.jenkinsci.plugins.tokenmacro.DataBoundTokenMacro.evaluate(DataBoundTokenMacro.java:189)21:07:10 atorg.jenkinsci.plugins.tokenmacro.TokenMacro.expand(TokenMacro.java:182)21:07:10 atorg.jenkinsci.plugins.tokenmacro.TokenMacro.expand(TokenMacro.java:154)21:07:10 atorg.jenkinsci.plugins.buildnamesetter.BuildNameSetter.setDisplayName(BuildNameSetter.java:50)21:07:10 atorg.jenkinsci.plugins.buildnamesetter.BuildNameSetter.access$000(BuildNameSetter.java:26)21:07:10 atorg.jenkinsci.plugins.buildnamesetter.BuildNameSetter$1.tearDown(BuildNameSetter.java:42)21:07:10 athudson.model.Build$BuildExecution.doRun(Build.java:171)21:07:10 athudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:535)21:07:10 athudson.model.Run.execute(Run.java:1732)21:07:10 athudson.matrix.MatrixRun.run(MatrixRun.java:146)21:07:10 athudson.model.ResourceController.execute(ResourceController.java:88)21:07:10 athudson.model.Executor.run(Executor.java:234)21:07:10Causedby:java.io.IOException:Failedtoabort21:07:10 atorg.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:195)21:07:10 atorg.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:581)21:07:10 atjenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)21:07:10 atjava.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)21:07:10 atjava.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)21:07:10 atjava.util.concurrent.FutureTask.run(FutureTask.java:138)21:07:10 atjava.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)21:07:10 atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)21:07:10 atjava.lang.Thread.run(Thread.java:695)21:07:10Causedby:java.io.IOException:Operationtimedout21:07:10 atsun.nio.ch.FileDispatcher.read0(NativeMethod)21:07:10 atsun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)21:07:10 atsun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:198)21:07:10 atsun.nio.ch.IOUtil.read(IOUtil.java:171)21:07:10 atsun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:245)21:07:10
[JIRA] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Arnt Witteveen updated JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed Change By: Arnt Witteveen (17/Jul/14 9:12 AM) Environment: Master:Jenkins1.572onOsX10.7.5,Java:1.6.0_65-b14-462-11M4609Slave:Slaveversion2.43(asreportedbytheversioncolumnplugin)onWindows2008R2Standard (64bit) ,Java7update55 (32bit) 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] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Arnt Witteveen updated JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed Change By: Arnt Witteveen (17/Jul/14 9:19 AM) Description: IhaveasimilarissuetoJENKINS-14332,althoughthatsaysthereisnoproblemonawindowsslave(becauseiteventuallyreconnects?),soImloggingthisseperatly.Themessagehudson.remoting.ChannelClosedException:channelisalreadyclosedbreaksmybuildsonawindowsslave.Itdoesnthappenoneverybuild,butanightlyrunof7buildsseemstohaveatleastoneeachtime.Becausetheseseemtobeconnectionissues,somightbeimeoutrelated,heressomesetupinfo,eventhoughIdoubtitwillberelevant:allthosebuildsarematrixbuilds.MysetupconsistofanOSXmasterYYYthatdoesthebuildforthemacaxis,andaslaveXXXthatdoesthebuildofthewindowsaxis.Thewindowsmachineissignificantlyslowerthanthemac,sosomethebuildsspendquitesometimeinastateof1axisdone,otheraxisqueued.Idontreallyseeissueshere,itseemstoworkfineformostofthebuildsmostofthetime:e.g.these7buildsareallqueuedat20:00,andtheexamplebelowfailsshortlyafter21:00,butotherbuildsfinishfinelateron(soafteralongerwait).ThefailingbuildonXXXstartedat20:50,soitfailsafter17minutes.Other,laterandearlierbuildsrunforanhourwithoutproblems.Inthemiddleofabuild,thebuildlog(asseenonthemaster)suddenlysays:==21:07:10FATAL:channelisalreadyclosed21:07:10hudson.remoting.ChannelClosedException:channelisalreadyclosed21:07:10 athudson.remoting.Channel.send(Channel.java:541)21:07:10 athudson.remoting.Request.call(Request.java:129)21:07:10 athudson.remoting.Channel.call(Channel.java:739)21:07:10 athudson.EnvVars.getRemote(EnvVars.java:404)21:07:10 athudson.model.Computer.getEnvironment(Computer.java:912)21:07:10 atjenkins.model.CoreEnvironmentContributor.buildEnvironmentFor(CoreEnvironmentContributor.java:29)21:07:10 athudson.model.Run.getEnvironment(Run.java:2250)21:07:10 athudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:907)21:07:10 atorg.jenkinsci.plugins.tokenmacro.impl.EnvironmentVariableMacro.evaluate(EnvironmentVariableMacro.java:23)21:07:10 atorg.jenkinsci.plugins.tokenmacro.DataBoundTokenMacro.evaluate(DataBoundTokenMacro.java:189)21:07:10 atorg.jenkinsci.plugins.tokenmacro.TokenMacro.expand(TokenMacro.java:182)21:07:10 atorg.jenkinsci.plugins.tokenmacro.TokenMacro.expand(TokenMacro.java:154)21:07:10 atorg.jenkinsci.plugins.buildnamesetter.BuildNameSetter.setDisplayName(BuildNameSetter.java:50)21:07:10 atorg.jenkinsci.plugins.buildnamesetter.BuildNameSetter.access$000(BuildNameSetter.java:26)21:07:10 atorg.jenkinsci.plugins.buildnamesetter.BuildNameSetter$1.tearDown(BuildNameSetter.java:42)21:07:10 athudson.model.Build$BuildExecution.doRun(Build.java:171)21:07:10 athudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:535)21:07:10 athudson.model.Run.execute(Run.java:1732)21:07:10 athudson.matrix.MatrixRun.run(MatrixRun.java:146)21:07:10 athudson.model.ResourceController.execute(ResourceController.java:88)21:07:10 athudson.model.Executor.run(Executor.java:234)21:07:10Causedby:java.io.IOException:Failedtoabort21:07:10 atorg.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:195)21:07:10 atorg.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:581)21:07:10 atjenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)21:07:10 atjava.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)21:07:10 atjava.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)21:07:10 atjava.util.concurrent.FutureTask.run(FutureTask.java:138)21:07:10 atjava.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)21:07:10 atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)21:07:10 atjava.lang.Thread.run(Thread.java:695)21:07:10Causedby:java.io.IOException:Operationtimedout21:07:10 atsun.nio.ch.FileDispatcher.read0(NativeMethod)21:07:10 atsun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)21:07:10 atsun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:198)21:07:10 atsun.nio.ch.IOUtil.read(IOUtil.java:171)21:07:10 atsun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:245)21:07:10
[JIRA] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Arnt Witteveen commented on JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed JENKINS-19513 may also be related. 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] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Daniel Beck updated JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed Change By: Daniel Beck (17/Jul/14 8:05 PM) Labels: connectionexceptionjenkinsslave remoting 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.
