On 11/17/11 6:36 AM, Chris Hegarty wrote:
On 17/11/2011 11:22, Gary Adams wrote:
On 11/17/11 4:14 AM, Chris Hegarty wrote:
On 17/11/2011 08:29, Alan Bateman wrote:
.....
I see Chris's mail points out that some tests do have an unusually
small
timeout. For those tests then I would be tempted to just remove the
timeout. Most likely the original author of the test put a small
timeout
to make it quick to test on a JDK that didn't have the fix.
Right, I've seen this before ( bug in JDK that causes deadlock, set
small timeout on test so doesn't block for too long before being
interrupted by jtreg). But if these tests ever fail then it means we
have a problem, the small timeout is just not necessary at all in a
JDK that doesn't have the issue being tested for.
Maybe this would be a good place to start and eliminate some of the
low hanging fruit ;-)
It would help to know which of the quick timeouts
were intentional and which ones are required for
proper execution of the tests.
Unfortunately, with most of these intermittent failures there is no
silver bullet, each test may have to be looked at individually. We've
been going through this process for months now :-(
From the original list you sent out the obvious candidates for removal
of the timeout parameter are:
jdk/test/java/util/logging/LoggingDeadlock.java:32: * @run
main/timeout=15 LoggingDeadlock
jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run
main/timeout=15 LoggingDeadlock2
jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run
main/timeout=80 LoggingDeadlock3
jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run
main/timeout=15 LoggingDeadlock4
Can we confirm with the test author if the timeouts could be removed?
If these tests ever encounter a java level deadlock and need to be
interrupted by the jtreg harness, then there is a JDK implementation
bug that needs to be fixed. It looks like these timeouts were added
when developing the original bug fix ( and test ) so the test times
out in a timely manner when running a JDK without the fix. This is not
needed for correct operation of the test itself.
Are you seeing issues with these test when running embedded on slow
hardware?
I haven't had the cycles to get to the test run on embedded hardware, but
I may get to it today.
-Chris.
Not all "drops" are good for "applesauce".
