Repository navigation
[JENKINS-3889] EOFException on reconnect after network connection loss #18863
Description
In our network, we repeatedly have problems, that network connection suddenly
drops but is available again right away. After that happened, I only see the
"Connected to.." popup in Windows taskbar - that's how I recognized the
connection loss. I don't know why this happens, and it's usually no problem
during work (but network guys couldn't yet give me an answer).
In such a case, a Hudson slave (running on a computer where this happens)
terminates (Hudson slave window shows state "Terminated"). After the network
connection being available again, the slave tries to reconnect to the master,
but it fails. Hudson slave window shows state "Handshaking" and then an
EOFException occurs. See following stack:
java.io.EOFException: unexpected stream termination
at hudson.remoting.Channel.(Channel.java:312)
at hudson.remoting.Channel.(Channel.java:251)
at hudson.remoting.Channel.(Channel.java:239)
at hudson.remoting.Engine.run(Engine.java:159)
In order to reproduce the problem, simply deactivate your LAN connection in
Windows control panel (you will see Hudson slave window showing state
"Terminated") and then re-activate it (then you see state "Handshaking" and the
EOFException).
As this is easily reproducable for me, I suppose it is not a problem with our
network infrastructure, but a bug in Hudson slave implementation when
reconnecting to the master.
Originally reported by fantasmic, imported from: EOFException on reconnect after network connection loss
- status: Resolved
- priority: Major
- component(s): core
- label(s): remoting
- resolution: Cannot Reproduce
- resolved: 2014-09-07T13:37:45+00:00
- votes: 2
- watchers: 3
- imported: 2025-11-24
Raw content of original issue
In our network, we repeatedly have problems, that network connection suddenly drops but is available again right away. After that happened, I only see the "Connected to.." popup in Windows taskbar - that's how I recognized the connection loss. I don't know why this happens, and it's usually no problem during work (but network guys couldn't yet give me an answer).
In such a case, a Hudson slave (running on a computer where this happens) terminates (Hudson slave window shows state "Terminated"). After the network connection being available again, the slave tries to reconnect to the master, but it fails. Hudson slave window shows state "Handshaking" and then an EOFException occurs. See following stack:
java.io.EOFException: unexpected stream termination at hudson.remoting.Channel.<init>(Channel.java:312) at hudson.remoting.Channel.<init>(Channel.java:251) at hudson.remoting.Channel.<init>(Channel.java:239) at hudson.remoting.Engine.run(Engine.java:159)
In order to reproduce the problem, simply deactivate your LAN connection in Windows control panel (you will see Hudson slave window showing state "Terminated") and then re-activate it (then you see state "Handshaking" and the EOFException).
As this is easily reproducable for me, I suppose it is not a problem with our network infrastructure, but a bug in Hudson slave implementation when reconnecting to the master.
- environment:
Platform: All, OS: Windows XP
Activity
jenkins-infra-bot commentedon Jun 18, 2009
fantasmic:
Raw content of original comment:
Created an attachment (id=745)
Hudson slave windows & error dialog with EOFException
jenkins-infra-bot commentedon Sep 22, 2009
Raw content of original comment:
Thanks for the instruction to reproduce the problem.
I believe this is happening because master failed to notice that the connection
went down in a timely fashion, thus subsequent attempts from the slave to
connect gets rejected (and we aren't nicely telling this problem to the plugin.
You can verify this by checking what the master says about the slave status,
after you disabled the network.
This is a bug at multiple levels...
jenkins-infra-bot commentedon Sep 22, 2009
Raw content of original comment:
Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/main/core/src/main/java/hudson/TcpSlaveAgentListener.java
trunk/hudson/main/remoting/src/main/java/hudson/remoting/Engine.java
trunk/www/changelog.html
http://fisheye4.cenqua.com/changelog/hudson/?cs=22037
Log:
JENKINS-3889JNLP clients now report the reason when the connection is rejected by the master.jenkins-infra-bot commentedon Sep 22, 2009
Raw content of original comment:
Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/main/core/src/main/java/hudson/slaves/ConnectionActivityMonitor.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=22039
Log:
JENKINS-3889In 1.325, I added a ping support so that the master detects dead connections more rapidly. This feature is off by default, until we feel comfortable enough that this feature works correctly.jenkins-infra-bot commentedon Mar 26, 2012
arahmanswitchfly:
Raw content of original comment:
Is there a permanent fix for this issue? I am seeing this all of a sudden on our slave test machines. Our slave machines were working just fine all this time but out of no where we started to notice this issue.
Any help would be appreciated!
Thanks,
Atiq
jenkins-infra-bot commentedon Sep 7, 2014
Raw content of original comment:
Given the age of this issue and the large number of changes since this was reported, I'm resolving this as 'Cannot Reproduce'.
If this or a similar issue still occurs on recent Jenkins versions, please file a new issue. Provide as much information about your setup as you can.