On 11/19/13 1:41 PM, Alan Bateman wrote:
On 19/11/2013 20:14, Martin Buchholz wrote:
In jsr166 tests we have mostly switched to 10 second timeouts to mean "forever".
But in ProcessBuilder tests we are starting up new java processes with their
well-known startup problems, so using a much larger value of "forever" seems
reasonable. I vote for 1 minute. You can write
waitFor(1, TimeUnit.MINUTES);
I agree that a timeout on that order might be needed when starting process.
However I think this one is just starting a thread that exercises the new
waitFor method.
I'll share a discussion we had before I pushed my "fix" yesterday that raised a
timeout from 30 to 60 seconds.
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19d2e9649138
Some of the test machines in our test farm can be startlingly, even absurdly
slow. In this case part of the test involved having a parent process fork a
child process, and the child turns around and connects back to the parent.
There's a 30 second timeout for this. It should never timeout, right? But it did
in our testing environment.
One clue is that on my laptop, this test (including framework setup and
teardown) took about 8 seconds to run. The test log of the failure showed that
the test took 2 MINUTES AND 49 SECONDS to run.
(This was on 32-bit Windows, of course.)
I can only guess at what causes the machines to run so slowly (virus scanning?
other VMs running on the same host?) but sometimes they can be so slow that the
unbelievable happens.
s'marks
