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でのみ発生し、Jenkinsジョブ実行の1％未満で発生することはほとんどありません。さまざまなログを調べても、これまでのところ、原因の有用なヒントは得られていません。当時、リモートのJenkinsノードは切断されていなかったようです。

質問：上記の制約を使用して、InterruptedExceptionの原因、またはその他の潜在的に有用なものを見つける方法は？

このような例外の原因を突き止めるための他のアイデアも歓迎します！おそらく、ジェンキンス/ハドソン特有の何かであり、この以前の質問ではカバーされていません（その答えはここではあまり役に立ちません）。

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

残念ながら、あまり強調されていませんが、条件を待つ最良の方法は、次のようにコードを記述することです。

while（condition <> true）{

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

}

偽の割り込みに注意し、それらを回避するようにコーディングする必要があります。

于 2013-10-04T05:35:06.233 に答える