How to debug unexplained thread interruption in Java

I'm getting an InterruptedException from Jenkins, relevant part of stack trace:

    at java.lang.Object.wait(Native Method)
    at hudson.remoting.RemoteInvocationHandler.invoke(
    at $Proxy33.join(Unknown Source)
    at hudson.Launcher$RemoteLauncher$ProcImpl.join(

That interrupt is unexpected and so far unexplained. I can't make that happen under debugger practically, it only happens in a CI which is in production use, and it happens fairly rarely, in well under 1% of Jenkins job executions. Combing through various logs hasn't yielded any useful hints of the cause so far. The remote Jenkins node did not seem to have disconnection at that time.

Question: How to find out the cause of that InterruptedException, or anything else potentially useful, with above constraints?

Any other ideas for tracking down cause of such an exception are also welcome! Perhaps something Jenkins/Hudson specific, not covered by this earlier question (answers of that aren't really helpful here).

2 Answers
  1. The InterruptedException looks normal. Checking the Jenkins source code I see that it gets handled (they close resources in the catch block) and then rethrow. Out of the box I don't get it why they do that (waiting in the first place).

    Looking at the comment before wait:

    // 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.

    I would say that somebody added the wait to overcome "rare occasion of blocking forever" and at the same time introduced a death by interrupt from the waiting.

    Your best bet is to check the Jenkins issue tracker and file a report that your jobs are failing because waiting gets interrupted every now and then and it cancels the remote call. I think they should either go back to waiting if they want to spend that amount of time waiting or continue but not fail at that point.

    2013-02-12 08:48:14
  2. Unfortunately, it is not very well emphasized, but the best way to wait for a condition is by writing code as such:

    while (condition <> true) {

    try {
      //do something
    catch (InterrruptedException e) {


    You have to watch out for spurious interrupts, and code around those.

    inder2013-10-04 05:35:06
Related Articles
You Might Also Like