Re: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient

2011-11-23 Thread Alan Bateman
On 23/11/2011 06:27, David Holmes wrote: Thumbs up from me. David Looks okay to me too although 120s seems way too high, I'd be interested to know how long the termination actually takes on one of these slow machines when it is heavily loaded. -Alan.

Re: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient

2011-11-22 Thread David Holmes
Thumbs up from me. David On 23/11/2011 1:46 AM, Gary Adams wrote: Revised webrev is available - removed the loop on termination - increased the original internal termination timeout to 120 seconds. The termination can exit sooner as the services are shutdown. The 120 second timeout is consiste

Re: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient

2011-11-22 Thread Gary Adams
Revised webrev is available - removed the loop on termination - increased the original internal termination timeout to 120 seconds. The termination can exit sooner as the services are shutdown. The 120 second timeout is consistent with the jtreg defaults, but can also work standalo

Re: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient

2011-11-22 Thread Chris Hegarty
On 11/22/11 11:56 AM, Alan Bateman wrote: On 22/11/2011 02:08, David Holmes wrote: Chris - are you keeping on eye on these test changes and whether there will be any sync'ing up needed with Doug's CVS? I've been keepng an eye on these, from a distance ;-) We have in the past pushed a f

Re: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient

2011-11-22 Thread Alan Bateman
On 22/11/2011 02:08, David Holmes wrote: : I support raising the timeout rather than waiting forever, as these tests should be able to run standalone and in that case they should not hang upon encountering a bug. I'm wary of assuming there is a higher-level test harness involved. Also note th

Re: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient

2011-11-21 Thread David Holmes
Hi Gary, On 22/11/2011 5:26 AM, Gary Adams wrote: The original complaint about the flakey mutex regression test is that it was failing on slower machines. The delay at the end of the processing is unnecessarily restrictive. Since the test harness will terminate after 120 seconds if the test hang

Re: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient

2011-11-21 Thread Alan Bateman
On 21/11/2011 19:26, Gary Adams wrote: The original complaint about the flakey mutex regression test is that it was failing on slower machines. The delay at the end of the processing is unnecessarily restrictive. Since the test harness will terminate after 120 seconds if the test hangs, the test

Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient

2011-11-21 Thread Gary Adams
The original complaint about the flakey mutex regression test is that it was failing on slower machines. The delay at the end of the processing is unnecessarily restrictive. Since the test harness will terminate after 120 seconds if the test hangs, the test does not have to terminate more quickly