0

我InterruptedException从 Jenkins 那里得到一个堆栈跟踪的相关部分：

java.lang.InterruptedException
    at java.lang.Object.wait(Native Method)
    at hudson.remoting.Request.call(Request.java:127)
    at hudson.remoting.Channel.call(Channel.java:646)
    at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158)
    at $Proxy33.join(Unknown Source)
    at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:861)

这种中断是出乎意料的，迄今为止无法解释。实际上，我无法在调试器下实现这一点，它只发生在生产使用的 CI 中，而且很少发生，远低于 1% 的 Jenkins 作业执行。到目前为止，梳理各种日志并没有产生任何有用的原因提示。远程 Jenkins 节点当时似乎没有断开连接。

问题：如何找出 InterruptedException 的原因，或任何其他可能有用的，具有上述约束？

也欢迎任何其他用于追踪此类异常原因的想法！也许是 Jenkins/Hudson 特定的东西，这个早先的问题没有涵盖（这个问题的答案在这里并没有真正的帮助）。

4

2 回答 2

2

InterruptedException 看起来很正常。检查 Jenkins 源代码，我发现它得到了处理（它们关闭了 catch 块中的资源），然后重新抛出。开箱即用，我不明白他们为什么这样做（首先等待）。

在等待之前查看评论：

// I don't know exactly when this can happen, as pendingCalls are cleaned up by Channel,
// but in production I've observed that in rare occasion it can block forever, even after a channel
// is gone. So be defensive against that.
wait(30*1000);

我会说有人添加了等待来克服“罕见的永远阻塞的情况”，同时引入了等待中断而导致的死亡。

你最好的办法是检查 Jenkins 问题跟踪器并提交一份报告，说明你的工作失败了，因为等待时不时地被打断，它会取消远程调用。我认为如果他们想花这么多时间等待，他们应该回到等待，或者继续但此时不失败。

于 2013-02-12T08:48:14.263 回答
0

不幸的是，它并没有得到很好的强调，但是等待条件的最好方法是编写如下代码：

而（条件<>真）{

try {
  wait(1000L);
  //do something
} 
catch (InterrruptedException e) {
}

}

您必须注意虚假中断，并围绕这些进行编码。

于 2013-10-04T05:35:06.233 回答