Potential timeout issues - tests running in the same vm

David Holmes david.holmes at oracle.com
Fri Nov 18 01:12:18 UTC 2011


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.


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

More information about the core-libs-dev mailing list