Potential timeout issues - tests running in the same vm

[David Holmes]

On 18/11/2011 11:12 AM, David Holmes wrote:
> Chris,
>
> On 17/11/2011 9:36 PM, Chris Hegarty wrote:
>> 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.
>
> Many tests that would hang if they encountered the problem they are
> testing for, use timeouts as a means to not lock up the entire testing
> process. We should not be removing such timeouts in my view, even if we
> have to adjust them for slower machines etc.

Okay based on discussion in other thread - if the above timeouts are 
smaller than the default then perhaps they should be removed. Though 
where does this default come from? If we remove explicit timeouts and 
the default gets lowered then we may get a sudden set of failures.

Too many pieces here under different control.

David

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