One potential workaround to try is adding

-Djenkins.slaves.NioChannelSelector.disabled=true

onto the Jenkins master's launcher command line arguments. On Debian/Ubuntu that is as simple as adding the above to JAVA_ARGS in /etc/default/jenkins


If launching jenkins from the commandline it would be

java -Djenkins.slaves.NioChannelSelector.disabled=true -jar jenkins.war

I just tested this on my system and it does seem to change the behaviour when I run my test case. In 3 tests the slave continued working correctly on 3 occassions. 2 of these saw the queued traffic just delivered and things continued as before. In the other example the original TCP connection entered TIME_WAIT state and a new connection was started successfully by the recently suspended slave.

Wed Aug 20 11:18:23 BST 2014
tcp6       0      0 :::42715                :::*                    LISTEN     
tcp6       0      0 192.168.1.23:42715      192.168.1.115:50570     TIME_WAIT  
tcp6       0      0 192.168.1.23:42715      192.168.1.24:47835      ESTABLISHED
tcp6       0      0 192.168.1.23:42715      192.168.1.115:50619     ESTABLISHED

From this I suspect that the new NIO based method of communicating with slaves is not causing the full TCP socket to get closed until TCP timers timeout. Whereas in the thread-per-slave method the connection is tore down almost immediately.

It would be good to know if the NioChannelSelector workaround outlined above helps others.

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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to