James Nord I'm fixing the Socket timeout exception as a part of JENKINS-22722

I have a template for it, but I still have to fill in all fields

Oleg Nenashev well it fixes the symptom not the underlying cause - so it's valid - but not perfectly valid

Do you want me to create a new "Channel reader thread should not fail on SocketTimeoutException" ticket?

James Nord This PR fixed what has been requested. So it's perfectly valid.
But I agree that Channel reader thread should not fail on SocketTimeoutException. I am working on a fix for it

I beleive this was the wrong fix.

A SocketTimeoutException is a non fatal exception.

As per the javacoc

Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout.

the code should be handling SocketTimeoutException and retrying. blindly changing the timeout is just going to punt the issue until someone does nothing for longer still. The only thing that timeouts out that should cause a connection close is a Ping timeout.

Code changed in jenkins
User: Oleg Nenashev
Path:
pom.xml
http://jenkins-ci.org/commit/jenkins/12e79963cca5122351943ee107f65c3ad91a2e25
Log:
[JENKINS-19445, JENKINS-34213, JENKINS-34808, JENKINS-34121] Bump remoting to 2.59. (#2344)

• [JENKINS-19445, JENKINS-34213, JENKINS-34808] Bump remoting to 2.58.

Changes:

• JENKINS-34213(https://issues.jenkins-ci.org/browse/JENKINS-34213) - Ensure that the unexporter cleans up whatever it can each sweep (https://github.com/jenkinsci/remoting/pull/81)
• JENKINS-19445(https://issues.jenkins-ci.org/browse/JENKINS-19445) Force class load on UserRequest in order to prevent deadlock on windows nodes when using JNA and Subversion (https://github.com/jenkinsci/remoting/pull/81)
• JENKINS-34808(https://issues.jenkins-ci.org/browse/JENKINS-34808) - Allow user to adjust socket timeout (https://github.com/jenkinsci/remoting/pull/68)

• JENKINS-34121 - Upgrade remoting to 2.59

(cherry picked from commit 409438f36dc80f20964fb16f8d88041e11ba4ed4)

released in remoting 2.58 and jenkins-2.4

Code changed in jenkins
User: Oleg Nenashev
Path:
pom.xml
http://jenkins-ci.org/commit/jenkins/409438f36dc80f20964fb16f8d88041e11ba4ed4
Log:
[JENKINS-19445, JENKINS-34213, JENKINS-34808, JENKINS-34121] Bump remoting to 2.59. (#2344)

• [JENKINS-19445, JENKINS-34213, JENKINS-34808] Bump remoting to 2.58.

Changes:

• JENKINS-34213(https://issues.jenkins-ci.org/browse/JENKINS-34213) - Ensure that the unexporter cleans up whatever it can each sweep (https://github.com/jenkinsci/remoting/pull/81)
• JENKINS-19445(https://issues.jenkins-ci.org/browse/JENKINS-19445) Force class load on UserRequest in order to prevent deadlock on windows nodes when using JNA and Subversion (https://github.com/jenkinsci/remoting/pull/81)
• JENKINS-34808(https://issues.jenkins-ci.org/browse/JENKINS-34808) - Allow user to adjust socket timeout (https://github.com/jenkinsci/remoting/pull/68)

• JENKINS-34121 - Upgrade remoting to 2.59