Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Blocker
-
Resolution: Fixed
-
Labels:None
-
Environment:Windows 7, Jenkins 1.613
-
Similar Issues:
-
Epic Link:
Description
I am running Jenkins 1.613.
i see the slaves log:
四月 15, 2015 10:15:02 上午 com.youdevise.hudson.slavestatus.SlaveListener call
信息: Slave-status listener starting
四月 15, 2015 10:15:02 上午 com.youdevise.hudson.slavestatus.SocketHTTPListener waitForConnection
信息: Slave-status listener ready on port 3141
四月 15, 2015 1:41:01 下午 hudson.remoting.jnlp.Main createEngine
信息: Setting up slave: 192.168.161.8
四月 15, 2015 1:41:01 下午 hudson.remoting.jnlp.Main$CuiListener <init>
信息: Jenkins agent is running in headless mode.
四月 15, 2015 1:41:01 下午 hudson.remoting.jnlp.Main$CuiListener status
信息: Locating server among http://192.168.95.37:8080/jenkins/
四月 15, 2015 1:41:01 下午 hudson.remoting.jnlp.Main$CuiListener status
信息: Connecting to 192.168.95.37:19994
四月 15, 2015 1:41:01 下午 hudson.remoting.jnlp.Main$CuiListener status
信息: Handshaking
四月 15, 2015 1:41:01 下午 hudson.remoting.jnlp.Main$CuiListener error
严重: The server rejected the connection: 192.168.161.8 is already connected to this master. Rejecting this connection.
java.lang.Exception: The server rejected the connection: 192.168.161.8 is already connected to this master. Rejecting this connection.
at hudson.remoting.Engine.onConnectionRejected(Engine.java:306)
at hudson.remoting.Engine.run(Engine.java:276)
Attachments
Issue Links
- is duplicated by
-
-
- Resolved
-
-
-
- Resolved
-
- is related to
-
-
- Open
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
-
JENKINS-39231 WinSW: Automatically terminate runaway processes in Windows services
-
- Resolved
-
- links to
Activity
Right, for sure. I think there are a few cases:
1) Cases where plugins/core usae computer.getChannel(). These work fine since if the listeners run properly, the channel is set to null and the code can do the right thing at that point depending on what its function is.
2) Cases where the channel object is held on an object (Ping thread, etc.) but there is error handling. These appear okay (ping thread exits).
3) Cases where the channel object is held on an object but no error handling - These need fixing.
I don't know of any real cases of #3. #2 appears okay. #1 is a problem because the listeners which should null out the channel on the computer object don't actually run. That is why we see the "already connected" issue.
Matthew Mitchell
added a comment - Right, for sure. I think there are a few cases:
1) Cases where plugins/core usae computer.getChannel(). These work fine since if the listeners run properly, the channel is set to null and the code can do the right thing at that point depending on what its function is.
2) Cases where the channel object is held on an object (Ping thread, etc.) but there is error handling. These appear okay (ping thread exits).
3) Cases where the channel object is held on an object but no error handling - These need fixing.
I don't know of any real cases of #3. #2 appears okay. #1 is a problem because the listeners which should null out the channel on the computer object don't actually run. That is why we see the "already connected" issue. This also appears to perhaps happen "near" a failure
Matthew Mitchell
added a comment - This also appears to perhaps happen "near" a failure
https://issues.jenkins-ci.org/browse/JENKINS-33358 Some bits have been addressed in JENKINS-39835
Fixed in 2.50
Maybe. I think we firstly need to implement correct handling of Errors and RuntimeExceptions in the core in order to avoid the case when the channel object leaks after the failure. It should help with some cases