Potential timeout issues - tests running in the same vm

[Chris Hegarty]

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

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?

-Chris.

>
> Not all "drops" are good for "applesauce".