Potential timeout issues - tests running in the same vm
david.holmes at oracle.com
Thu Nov 17 17:12:18 PST 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
>> Not all "drops" are good for "applesauce".
More information about the core-libs-dev