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