-
Bug
-
Resolution: Fixed
-
Major
check wraps most of its body in a timeout, but not getWorkspace. If an agent is unresponsive, this can cause a Timer thread to block indefinitely:
"jenkins.util.Timer [#2] / waiting for hudson.remoting.Channel@...:..." ... java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at hudson.remoting.Request.call(Request.java:147) - locked <...> (a hudson.remoting.UserRequest) at hudson.remoting.Channel.call(Channel.java:780) at hudson.FilePath.act(FilePath.java:1007) at hudson.FilePath.act(FilePath.java:996) at hudson.FilePath.isDirectory(FilePath.java:1532) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.getWorkspace(DurableTaskStep.java:174) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.check(DurableTaskStep.java:244) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.run(DurableTaskStep.java:233)
Remote calls like isDirectory should have a timeout applied. Unfortunately Jenkins core APIs commit the cardinal sin of distributing computing: they offer calls like FilePath.isDirectory() which throw InterruptedException but have no built-in timeout, so it is necessary to go to extra lengths to add a timeout to any Remoting call.
- is related to
-
JENKINS-38381 [JEP-210] Optimize log handling in Pipeline and Durable Task
- Resolved
- relates to
-
JENKINS-38769 Pipeline job hangs when agent loses network connectivity
- Resolved
-
JENKINS-41854 Contextualize a fresh FilePath after an agent reconnection
- Resolved
-
JENKINS-44785 Add Built-in Request timeout support in Remoting
- In Review
- links to