A file was uploaded. self-contained reproducing code

Now that I fixed the memory leak, I uncovered znother bug in the client. In 4.2.8, the JPPFJob.awaitResult(timeout) (used internally in JPPFClient.submitJob() for blocking jobs) is sometimes not notified of the job completion, causing the application thread that awaits the rjob results to be stuck in a wait(). This can happen in extreme cases where the job completes between the call to SubmissionManager.submitJob() and the call to JPPFJob.awaitResults().

awaitResults ultimately calls AbstractJPPFJob.await() which has this code:

void await(final long timeout, final boolean raiseTimeoutException) throws TimeoutException {
  long millis = timeout > 0L ? timeout : Long.MAX_VALUE;
  long elapsed = 0L;
  long start = System.currentTimeMillis();
  while ((results.size() < tasks.size()) && ((elapsed = System.currentTimeMillis() - start) < millis)) results.goToSleep(millis - elapsed);
  if ((elapsed >= millis) && raiseTimeoutException) throw new TimeoutException("timeout expired");
}

The big problem here is results.goToSleep(millis - elapsed) which performs a synchronized call to results.wait(...). If the job has already completed before the while loop is executed, then the thread gets stuck forever. Instead we should do a results.goToSleep(1L).

As a side note, this fix is already implemented in 5.0, 5.1 and in the trunk

Fixed in:

• trunk revision 3873
• branch b5.1 revision 3874
• branch b5.0 revision 3875
• branch b4.2 revision 3876