Potential timeout issues - tests running in the same vm

[Gary Adams]

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".