Potential timeout issues - tests running in the same vm
chris.hegarty at oracle.com
Thu Nov 17 11:36:03 UTC 2011
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
jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run
jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run
jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run
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
> Not all "drops" are good for "applesauce".
More information about the core-libs-dev