From jaroslav.bachorik at oracle.com Mon Jun 22 15:36:21 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 22 Jun 2015 17:36:21 +0200 Subject: jmx-dev RFR 8071487: javax/management/monitor/GaugeMonitorDeadlockTest.java timed out Message-ID: <55882B75.1070804@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8071487 Webrev: http://cr.openjdk.java.net/~jbachorik/8071487/webrev.00 GaugeMonitorDeadlockTest fails intermittently due data race - the call to monitorProxy.start() on L105 will eventually result in incrementing the GetCount attribute. If that happens before L109 had the chance to run the loop on L113-128 will become infinite. The initial value will contain the already incremented GetCount value and GetCount attribute value will not get further incremented. I took the liberty to fix the same issue in test/javax/management/monitor/StringMonitorDeadlockTest.java, not waiting for the real test failure. Thanks, -JB- From david.holmes at oracle.com Tue Jun 23 06:04:50 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jun 2015 16:04:50 +1000 Subject: jmx-dev RFR 8071487: javax/management/monitor/GaugeMonitorDeadlockTest.java timed out In-Reply-To: <55882B75.1070804@oracle.com> References: <55882B75.1070804@oracle.com> Message-ID: <5588F702.20606@oracle.com> On 23/06/2015 1:36 AM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8071487 > Webrev: http://cr.openjdk.java.net/~jbachorik/8071487/webrev.00 > > GaugeMonitorDeadlockTest fails intermittently due data race - the call > to monitorProxy.start() on L105 will eventually result in incrementing > the GetCount attribute. If that happens before L109 had the chance to > run the loop on L113-128 will become infinite. The initial value will > contain the already incremented GetCount value and GetCount attribute > value will not get further incremented. The reordering of the start() and initial observedProxy.getGetCount seems reasonable. The changes to the timeout handling less so. The alarm code doesn't look right to me. Each time you call check(true) in the loop you advance the time when the alarm "goes off". ??? David > I took the liberty to fix the same issue in > test/javax/management/monitor/StringMonitorDeadlockTest.java, not > waiting for the real test failure. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Tue Jun 23 07:33:46 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 23 Jun 2015 09:33:46 +0200 Subject: jmx-dev RFR 8071487: javax/management/monitor/GaugeMonitorDeadlockTest.java timed out In-Reply-To: <5588F702.20606@oracle.com> References: <55882B75.1070804@oracle.com> <5588F702.20606@oracle.com> Message-ID: <55890BDA.8010104@oracle.com> Hi David, On 23.6.2015 08:04, David Holmes wrote: > On 23/06/2015 1:36 AM, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8071487 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8071487/webrev.00 >> >> GaugeMonitorDeadlockTest fails intermittently due data race - the call >> to monitorProxy.start() on L105 will eventually result in incrementing >> the GetCount attribute. If that happens before L109 had the chance to >> run the loop on L113-128 will become infinite. The initial value will >> contain the already incremented GetCount value and GetCount attribute >> value will not get further incremented. > > The reordering of the start() and initial observedProxy.getGetCount > seems reasonable. > > The changes to the timeout handling less so. The alarm code doesn't look > right to me. Each time you call check(true) in the loop you advance the > time when the alarm "goes off". ??? Stupid me :( Thanks for catching this. http://cr.openjdk.java.net/~jbachorik/8071487/webrev.01 -JB- > > David > > > >> I took the liberty to fix the same issue in >> test/javax/management/monitor/StringMonitorDeadlockTest.java, not >> waiting for the real test failure. >> >> Thanks, >> >> -JB- From david.holmes at oracle.com Wed Jun 24 09:22:27 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 19:22:27 +1000 Subject: jmx-dev RFR 8071487: javax/management/monitor/GaugeMonitorDeadlockTest.java timed out In-Reply-To: <55890BDA.8010104@oracle.com> References: <55882B75.1070804@oracle.com> <5588F702.20606@oracle.com> <55890BDA.8010104@oracle.com> Message-ID: <558A76D3.2010902@oracle.com> On 23/06/2015 5:33 PM, Jaroslav Bachorik wrote: > Hi David, > > On 23.6.2015 08:04, David Holmes wrote: >> On 23/06/2015 1:36 AM, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8071487 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8071487/webrev.00 >>> >>> GaugeMonitorDeadlockTest fails intermittently due data race - the call >>> to monitorProxy.start() on L105 will eventually result in incrementing >>> the GetCount attribute. If that happens before L109 had the chance to >>> run the loop on L113-128 will become infinite. The initial value will >>> contain the already incremented GetCount value and GetCount attribute >>> value will not get further incremented. >> >> The reordering of the start() and initial observedProxy.getGetCount >> seems reasonable. >> >> The changes to the timeout handling less so. The alarm code doesn't look >> right to me. Each time you call check(true) in the loop you advance the >> time when the alarm "goes off". ??? > > Stupid me :( Thanks for catching this. > > http://cr.openjdk.java.net/~jbachorik/8071487/webrev.01 That looks better, but the Alarm class would benefit from some simple descriptive comments. I must admit I don't really see the need for introducing it. Thanks, David > -JB- > >> >> David >> >> >> >>> I took the liberty to fix the same issue in >>> test/javax/management/monitor/StringMonitorDeadlockTest.java, not >>> waiting for the real test failure. >>> >>> Thanks, >>> >>> -JB- > From jaroslav.bachorik at oracle.com Thu Jun 25 09:53:01 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 25 Jun 2015 11:53:01 +0200 Subject: jmx-dev RFR 8071487: javax/management/monitor/GaugeMonitorDeadlockTest.java timed out In-Reply-To: <558A76D3.2010902@oracle.com> References: <55882B75.1070804@oracle.com> <5588F702.20606@oracle.com> <55890BDA.8010104@oracle.com> <558A76D3.2010902@oracle.com> Message-ID: <558BCF7D.6030001@oracle.com> On 24.6.2015 11:22, David Holmes wrote: > On 23/06/2015 5:33 PM, Jaroslav Bachorik wrote: >> Hi David, >> >> On 23.6.2015 08:04, David Holmes wrote: >>> On 23/06/2015 1:36 AM, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8071487 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8071487/webrev.00 >>>> >>>> GaugeMonitorDeadlockTest fails intermittently due data race - the call >>>> to monitorProxy.start() on L105 will eventually result in incrementing >>>> the GetCount attribute. If that happens before L109 had the chance to >>>> run the loop on L113-128 will become infinite. The initial value will >>>> contain the already incremented GetCount value and GetCount attribute >>>> value will not get further incremented. >>> >>> The reordering of the start() and initial observedProxy.getGetCount >>> seems reasonable. >>> >>> The changes to the timeout handling less so. The alarm code doesn't look >>> right to me. Each time you call check(true) in the loop you advance the >>> time when the alarm "goes off". ??? >> >> Stupid me :( Thanks for catching this. >> >> http://cr.openjdk.java.net/~jbachorik/8071487/webrev.01 > > That looks better, but the Alarm class would benefit from some simple > descriptive comments. I must admit I don't really see the need for > introducing it. I expected to reuse it in some of the other JMX monitoring tests. But it didn't turn out that way. I've removed the Alarm class from the test and just switched to using Util.adjustTimeout() instead of doing the parsing of "test.timeout.factor" system property by hand. http://cr.openjdk.java.net/~jbachorik/8071487/webrev.02 Thanks, -JB- > > Thanks, > David > >> -JB- >> >>> >>> David >>> >>> >>> >>>> I took the liberty to fix the same issue in >>>> test/javax/management/monitor/StringMonitorDeadlockTest.java, not >>>> waiting for the real test failure. >>>> >>>> Thanks, >>>> >>>> -JB- >> From david.holmes at oracle.com Fri Jun 26 06:42:39 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2015 16:42:39 +1000 Subject: jmx-dev RFR 8071487: javax/management/monitor/GaugeMonitorDeadlockTest.java timed out In-Reply-To: <558BCF7D.6030001@oracle.com> References: <55882B75.1070804@oracle.com> <5588F702.20606@oracle.com> <55890BDA.8010104@oracle.com> <558A76D3.2010902@oracle.com> <558BCF7D.6030001@oracle.com> Message-ID: <558CF45F.7060200@oracle.com> Looks good! Thanks, David On 25/06/2015 7:53 PM, Jaroslav Bachorik wrote: > On 24.6.2015 11:22, David Holmes wrote: >> On 23/06/2015 5:33 PM, Jaroslav Bachorik wrote: >>> Hi David, >>> >>> On 23.6.2015 08:04, David Holmes wrote: >>>> On 23/06/2015 1:36 AM, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8071487 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8071487/webrev.00 >>>>> >>>>> GaugeMonitorDeadlockTest fails intermittently due data race - the call >>>>> to monitorProxy.start() on L105 will eventually result in incrementing >>>>> the GetCount attribute. If that happens before L109 had the chance to >>>>> run the loop on L113-128 will become infinite. The initial value will >>>>> contain the already incremented GetCount value and GetCount attribute >>>>> value will not get further incremented. >>>> >>>> The reordering of the start() and initial observedProxy.getGetCount >>>> seems reasonable. >>>> >>>> The changes to the timeout handling less so. The alarm code doesn't >>>> look >>>> right to me. Each time you call check(true) in the loop you advance the >>>> time when the alarm "goes off". ??? >>> >>> Stupid me :( Thanks for catching this. >>> >>> http://cr.openjdk.java.net/~jbachorik/8071487/webrev.01 >> >> That looks better, but the Alarm class would benefit from some simple >> descriptive comments. I must admit I don't really see the need for >> introducing it. > > I expected to reuse it in some of the other JMX monitoring tests. But it > didn't turn out that way. > > I've removed the Alarm class from the test and just switched to using > Util.adjustTimeout() instead of doing the parsing of > "test.timeout.factor" system property by hand. > > http://cr.openjdk.java.net/~jbachorik/8071487/webrev.02 > > Thanks, > > -JB- > >> >> Thanks, >> David >> >>> -JB- >>> >>>> >>>> David >>>> >>>> >>>> >>>>> I took the liberty to fix the same issue in >>>>> test/javax/management/monitor/StringMonitorDeadlockTest.java, not >>>>> waiting for the real test failure. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> >