From shanliang.jiang at oracle.com Fri May 2 09:17:11 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 02 May 2014 11:17:11 +0200 Subject: jmx-dev RFR 8038322: CounterMonitorDeadlockTest.java fails intermittently, presumed deadlock Message-ID: <53636297.5050403@oracle.com> Please review this test fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8038322 Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038322/00/ The test had a timeout of 500*10 ms, better to remove this timeout and to wait the harness timeout. Thanks, Shanliang From daniel.fuchs at oracle.com Fri May 2 10:40:49 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 02 May 2014 12:40:49 +0200 Subject: jmx-dev RFR 8038322: CounterMonitorDeadlockTest.java fails intermittently, presumed deadlock In-Reply-To: <53636297.5050403@oracle.com> References: <53636297.5050403@oracle.com> Message-ID: <53637631.50704@oracle.com> Hi Shanliang, This looks reasonable to me. Another possibility could have been to use the timeout factor to adapt the delay of Thread.sleep in the loop. What you have might be more reliable, but it also means that if the test ever fails in timeout again then it could be more difficult to diagnose what was wrong. Maybe you should add a trace before entering and after leaving any of your two loops, so that you at least will know where the test was being blocked? best regards, -- daniel On 5/2/14 11:17 AM, shanliang wrote: > Please review this test fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8038322 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038322/00/ > > > The test had a timeout of 500*10 ms, better to remove this timeout and > to wait the harness timeout. > > Thanks, > Shanliang From shanliang.jiang at oracle.com Fri May 2 11:20:36 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 02 May 2014 13:20:36 +0200 Subject: jmx-dev RFR 8038322: CounterMonitorDeadlockTest.java fails intermittently, presumed deadlock In-Reply-To: <53637631.50704@oracle.com> References: <53636297.5050403@oracle.com> <53637631.50704@oracle.com> Message-ID: <53637F84.50206@oracle.com> Daniel Fuchs wrote: > Hi Shanliang, > > This looks reasonable to me. > Another possibility could have been to use the timeout factor > to adapt the delay of Thread.sleep in the loop. Yes we could adapt our timeout, but it is simpler to use the testing harness timeout. > > What you have might be more reliable, but it also means > that if the test ever fails in timeout again then it could > be more difficult to diagnose what was wrong. > > Maybe you should add a trace before entering > and after leaving any of your two loops, so that you > at least will know where the test was being blocked? Yes, absolutely useful to add trace: http://cr.openjdk.java.net/~sjiang/JDK-8038322/01/ Thanks, Shanliang > > best regards, > > -- daniel > > On 5/2/14 11:17 AM, shanliang wrote: >> Please review this test fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8038322 >> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038322/00/ >> >> >> The test had a timeout of 500*10 ms, better to remove this timeout and >> to wait the harness timeout. >> >> Thanks, >> Shanliang > From daniel.fuchs at oracle.com Fri May 2 12:11:08 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 02 May 2014 14:11:08 +0200 Subject: jmx-dev RFR 8038322: CounterMonitorDeadlockTest.java fails intermittently, presumed deadlock In-Reply-To: <53637F84.50206@oracle.com> References: <53636297.5050403@oracle.com> <53637631.50704@oracle.com> <53637F84.50206@oracle.com> Message-ID: <53638B5C.5070301@oracle.com> Looks good! On 5/2/14 1:20 PM, shanliang wrote: > Daniel Fuchs wrote: >> Hi Shanliang, >> >> This looks reasonable to me. >> Another possibility could have been to use the timeout factor >> to adapt the delay of Thread.sleep in the loop. > Yes we could adapt our timeout, but it is simpler to use the testing > harness timeout. >> >> What you have might be more reliable, but it also means >> that if the test ever fails in timeout again then it could >> be more difficult to diagnose what was wrong. >> >> Maybe you should add a trace before entering >> and after leaving any of your two loops, so that you >> at least will know where the test was being blocked? > Yes, absolutely useful to add trace: > http://cr.openjdk.java.net/~sjiang/JDK-8038322/01/ > > > Thanks, > Shanliang >> >> best regards, >> >> -- daniel >> >> On 5/2/14 11:17 AM, shanliang wrote: >>> Please review this test fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038322 >>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038322/00/ >>> >>> >>> The test had a timeout of 500*10 ms, better to remove this timeout and >>> to wait the harness timeout. >>> >>> Thanks, >>> Shanliang >> >