From jaroslav.bachorik at oracle.com Tue Sep 3 01:02:09 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 03 Sep 2013 10:02:09 +0200 Subject: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up Message-ID: <52259781.1070405@oracle.com> Please, review the following patch: http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 It addresses the problem of the test not properly cleaning up the created threads at exit. It does so by running the test in "othervm" mode. Although it is possible to modify the test to cleanup the threads at exit it would add more complexity to the test while achieving the same result as running the test in "othervm" mode. Thanks, -JB - From chris.hegarty at oracle.com Tue Sep 3 01:21:43 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 03 Sep 2013 09:21:43 +0100 Subject: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up In-Reply-To: <52259781.1070405@oracle.com> References: <52259781.1070405@oracle.com> Message-ID: <52259C17.2080606@oracle.com> On 09/03/2013 09:02 AM, Jaroslav Bachorik wrote: > Please, review the following patch: > http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 > > It addresses the problem of the test not properly cleaning up the > created threads at exit. It does so by running the test in "othervm" > mode. Although it is possible to modify the test to cleanup the threads > at exit it would add more complexity to the test while achieving the > same result as running the test in "othervm" mode. Seems reasonable. -Chris. > > Thanks, > > -JB - > From shanliang.jiang at oracle.com Tue Sep 3 01:32:46 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 03 Sep 2013 10:32:46 +0200 Subject: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up In-Reply-To: <52259781.1070405@oracle.com> References: <52259781.1070405@oracle.com> Message-ID: <52259EAE.70007@oracle.com> Looks good, simple but workable solution! Shanliang Jaroslav Bachorik wrote: > Please, review the following patch: > http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 > > It addresses the problem of the test not properly cleaning up the > created threads at exit. It does so by running the test in "othervm" > mode. Although it is possible to modify the test to cleanup the threads > at exit it would add more complexity to the test while achieving the > same result as running the test in "othervm" mode. > > Thanks, > > -JB - > From daniel.fuchs at oracle.com Tue Sep 3 02:17:05 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 03 Sep 2013 11:17:05 +0200 Subject: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up In-Reply-To: <52259781.1070405@oracle.com> References: <52259781.1070405@oracle.com> Message-ID: <5225A911.7050507@oracle.com> On 9/3/13 10:02 AM, Jaroslav Bachorik wrote: > It addresses the problem of the test not properly cleaning up the > created threads at exit. It does so by running the test in "othervm" > mode. Although it is possible to modify the test to cleanup the threads > at exit it would add more complexity to the test while achieving the > same result as running the test in "othervm" mode. +1 -- daniel From Alan.Bateman at oracle.com Tue Sep 3 03:57:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 11:57:01 +0100 Subject: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up In-Reply-To: <52259781.1070405@oracle.com> References: <52259781.1070405@oracle.com> Message-ID: <5225C07D.9050007@oracle.com> On 03/09/2013 09:02, Jaroslav Bachorik wrote: > Please, review the following patch: > http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 > > It addresses the problem of the test not properly cleaning up the > created threads at exit. It does so by running the test in "othervm" > mode. Although it is possible to modify the test to cleanup the threads > at exit it would add more complexity to the test while achieving the > same result as running the test in "othervm" mode. > > Thanks, > > -JB - This looks okay. There is a second test that I noted in the bug that has a similar issue, maybe that needs its own bug. -Alan From jaroslav.bachorik at oracle.com Tue Sep 3 04:15:33 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 03 Sep 2013 13:15:33 +0200 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure Message-ID: <5225C4D5.6040805@oracle.com> Please, review the following patch of the intermittently failing test: http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 Sometimes the ThreadExecutionSynchronizer class failes to achieve the desired synchronization (due to possible data races when evaluating and setting the "waiting" variable) leading to test failures. The patch fixes the possibility of data race. Also the Locks class is tidied up a bit. Thanks, -JB- From jaroslav.bachorik at oracle.com Tue Sep 3 04:26:32 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 03 Sep 2013 13:26:32 +0200 Subject: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up In-Reply-To: <5225C07D.9050007@oracle.com> References: <52259781.1070405@oracle.com> <5225C07D.9050007@oracle.com> Message-ID: <5225C768.5050207@oracle.com> On 09/03/2013 12:57 PM, Alan Bateman wrote: > On 03/09/2013 09:02, Jaroslav Bachorik wrote: >> Please, review the following patch: >> http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 >> >> It addresses the problem of the test not properly cleaning up the >> created threads at exit. It does so by running the test in "othervm" >> mode. Although it is possible to modify the test to cleanup the threads >> at exit it would add more complexity to the test while achieving the >> same result as running the test in "othervm" mode. >> >> Thanks, >> >> -JB - > This looks okay. There is a second test that I noted in the bug that has > a similar issue, maybe that needs its own bug. Hm, actually there are 6 other tests using the LockingThread class which leaves the threads running. So all those tests should be made running in "othervm" mode. Does increasing the number of tests running in "othervm" mode have any negative consequences? -JB- > > -Alan From jaroslav.bachorik at oracle.com Tue Sep 3 04:53:28 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 03 Sep 2013 13:53:28 +0200 Subject: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up In-Reply-To: <5225C768.5050207@oracle.com> References: <52259781.1070405@oracle.com> <5225C07D.9050007@oracle.com> <5225C768.5050207@oracle.com> Message-ID: <5225CDB8.2010904@oracle.com> On 09/03/2013 01:26 PM, Jaroslav Bachorik wrote: > On 09/03/2013 12:57 PM, Alan Bateman wrote: >> On 03/09/2013 09:02, Jaroslav Bachorik wrote: >>> Please, review the following patch: >>> http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 >>> >>> It addresses the problem of the test not properly cleaning up the >>> created threads at exit. It does so by running the test in "othervm" >>> mode. Although it is possible to modify the test to cleanup the threads >>> at exit it would add more complexity to the test while achieving the >>> same result as running the test in "othervm" mode. >>> >>> Thanks, >>> >>> -JB - >> This looks okay. There is a second test that I noted in the bug that has >> a similar issue, maybe that needs its own bug. > > Hm, actually there are 6 other tests using the LockingThread class which > leaves the threads running. So all those tests should be made running in > "othervm" mode. I was too hasty, it seems. The number of tests not being run in "othervm" mode and leaving live threads is 4 (in addition to SynchronizerLockingThread). They are: java/lang/management/ThreadMXBean/MyOwnSynchronizer java/lang/management/ThreadMXBean/SharedSynchronizer java/lang/management/ThreadMXBean/SynchronizationStatistics java/lang/management/ThreadMXBean/LockedMonitors -JB- > > Does increasing the number of tests running in "othervm" mode have any > negative consequences? > > -JB- > >> >> -Alan > From Alan.Bateman at oracle.com Tue Sep 3 04:54:50 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 12:54:50 +0100 Subject: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up In-Reply-To: <5225C768.5050207@oracle.com> References: <52259781.1070405@oracle.com> <5225C07D.9050007@oracle.com> <5225C768.5050207@oracle.com> Message-ID: <5225CE0A.9020305@oracle.com> On 03/09/2013 12:26, Jaroslav Bachorik wrote: > : > Hm, actually there are 6 other tests using the LockingThread class which > leaves the threads running. So all those tests should be made running in > "othervm" mode. > > Does increasing the number of tests running in "othervm" mode have any > negative consequences? The big advantage of agentvm mode is that it doesn't need to start a new VM for each test so you save on the startup. The advantage is very apparent with short running tests, barely noticeable with long running tests. It's okay to have tests running in othervm mode (reliability trumps performance), we just need to be careful not to use it to fix every issue, otherwise the overall test execution time will creep up. -Alan. From daniel.fuchs at oracle.com Tue Sep 3 05:10:57 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 03 Sep 2013 14:10:57 +0200 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <5225C4D5.6040805@oracle.com> References: <5225C4D5.6040805@oracle.com> Message-ID: <5225D1D1.4080706@oracle.com> Hi Jaroslav, Have you considered replacing the ThreadExecutionSynchronizer with a plain (and more reliable) CyclicBarrier or Phaser object? best regards -- daniel On 9/3/13 1:15 PM, Jaroslav Bachorik wrote: > Please, review the following patch of the intermittently failing test: > http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 > > > Sometimes the ThreadExecutionSynchronizer class failes to achieve the > desired synchronization (due to possible data races when evaluating and > setting the "waiting" variable) leading to test failures. > > The patch fixes the possibility of data race. Also the Locks class is > tidied up a bit. > > Thanks, > > -JB- > From jaroslav.bachorik at oracle.com Tue Sep 3 06:02:39 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 03 Sep 2013 15:02:39 +0200 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <5225D1D1.4080706@oracle.com> References: <5225C4D5.6040805@oracle.com> <5225D1D1.4080706@oracle.com> Message-ID: <5225DDEF.2010402@oracle.com> On 09/03/2013 02:10 PM, Daniel Fuchs wrote: > Hi Jaroslav, > > Have you considered replacing the ThreadExecutionSynchronizer with > a plain (and more reliable) CyclicBarrier or Phaser object? > > > > Yes, I've played with the idea of using more advanced concurrency constructs. But I couldn't fit the CyclicBarrier to the usecase and when I used Phaser the solution complexity was considerably higher. It might be due to my lack of experience with the Phaser, specifically, but the plain old 'synchronized' yielded the best results for me :( -JB- > > best regards > > -- daniel > > On 9/3/13 1:15 PM, Jaroslav Bachorik wrote: >> Please, review the following patch of the intermittently failing test: >> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 >> >> >> Sometimes the ThreadExecutionSynchronizer class failes to achieve the >> desired synchronization (due to possible data races when evaluating and >> setting the "waiting" variable) leading to test failures. >> >> The patch fixes the possibility of data race. Also the Locks class is >> tidied up a bit. >> >> Thanks, >> >> -JB- >> > From jaroslav.bachorik at oracle.com Tue Sep 3 06:36:39 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 03 Sep 2013 15:36:39 +0200 Subject: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up In-Reply-To: <5225CE0A.9020305@oracle.com> References: <52259781.1070405@oracle.com> <5225C07D.9050007@oracle.com> <5225C768.5050207@oracle.com> <5225CE0A.9020305@oracle.com> Message-ID: <5225E5E7.7000308@oracle.com> On 09/03/2013 01:54 PM, Alan Bateman wrote: > On 03/09/2013 12:26, Jaroslav Bachorik wrote: >> : >> Hm, actually there are 6 other tests using the LockingThread class which >> leaves the threads running. So all those tests should be made running in >> "othervm" mode. >> >> Does increasing the number of tests running in "othervm" mode have any >> negative consequences? > The big advantage of agentvm mode is that it doesn't need to start a new > VM for each test so you save on the startup. The advantage is very > apparent with short running tests, barely noticeable with long running > tests. It's okay to have tests running in othervm mode (reliability > trumps performance), we just need to be careful not to use it to fix > every issue, otherwise the overall test execution time will creep up. Ok, I've rounded up all the tests in java/lang/management/ThreadMXBean not cleaning up the threads and not running in "othervm" mode and made them running in "othervm" mode. There are 5 such tests. IMO, for 5 tests it is worth to go for the simple solution and just run them in "othervm" mode. If the number goes significantly higher, though, we should consider putting more effort into fixing the cleanup logic in those tests. The updated patch is at http://cr.openjdk.java.net/~jbachorik/8004179/webrev.02 -JB- > > -Alan. From Alan.Bateman at oracle.com Tue Sep 3 06:52:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Sep 2013 14:52:36 +0100 Subject: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up In-Reply-To: <5225E5E7.7000308@oracle.com> References: <52259781.1070405@oracle.com> <5225C07D.9050007@oracle.com> <5225C768.5050207@oracle.com> <5225CE0A.9020305@oracle.com> <5225E5E7.7000308@oracle.com> Message-ID: <5225E9A4.4000805@oracle.com> On 03/09/2013 14:36, Jaroslav Bachorik wrote: > : > Ok, I've rounded up all the tests in java/lang/management/ThreadMXBean > not cleaning up the threads and not running in "othervm" mode and made > them running in "othervm" mode. There are 5 such tests. > > IMO, for 5 tests it is worth to go for the simple solution and just run > them in "othervm" mode. If the number goes significantly higher, though, > we should consider putting more effort into fixing the cleanup logic in > those tests. > > The updated patch is at > http://cr.openjdk.java.net/~jbachorik/8004179/webrev.02 > Okay, this seems okay for me for now. -Alan. From david.holmes at oracle.com Tue Sep 3 18:34:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Sep 2013 11:34:22 +1000 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <5225DDEF.2010402@oracle.com> References: <5225C4D5.6040805@oracle.com> <5225D1D1.4080706@oracle.com> <5225DDEF.2010402@oracle.com> Message-ID: <52268E1E.2060306@oracle.com> Hi Jaroslav, On 3/09/2013 11:02 PM, Jaroslav Bachorik wrote: > On 09/03/2013 02:10 PM, Daniel Fuchs wrote: >> Hi Jaroslav, >> >> Have you considered replacing the ThreadExecutionSynchronizer with >> a plain (and more reliable) CyclicBarrier or Phaser object? >> >> >> >> > > Yes, I've played with the idea of using more advanced concurrency > constructs. But I couldn't fit the CyclicBarrier to the usecase and when > I used Phaser the solution complexity was considerably higher. It might > be due to my lack of experience with the Phaser, specifically, but the > plain old 'synchronized' yielded the best results for me :( Unfortunately your use of wait() does not account for spurious wakeups - which the existing Semaphore masks from you. A CyclicBarrier would seem to be a better fit, but the logic in this test is convoluted enough that it is hard to tell exactly what the synchronization protocol is. Also your gratuitous style changes made it very hard to see actual functional changes in the test. There's really no need to change for loops into for-each loops. ;-) David ---- > -JB- > >> >> best regards >> >> -- daniel >> >> On 9/3/13 1:15 PM, Jaroslav Bachorik wrote: >>> Please, review the following patch of the intermittently failing test: >>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 >>> >>> >>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the >>> desired synchronization (due to possible data races when evaluating and >>> setting the "waiting" variable) leading to test failures. >>> >>> The patch fixes the possibility of data race. Also the Locks class is >>> tidied up a bit. >>> >>> Thanks, >>> >>> -JB- >>> >> > From mandy.chung at oracle.com Tue Sep 3 19:24:51 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 03 Sep 2013 19:24:51 -0700 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <5225C4D5.6040805@oracle.com> References: <5225C4D5.6040805@oracle.com> Message-ID: <522699F3.5000904@oracle.com> Hi Jaroslav, Like Daniel and David said, CyclicBarrier and other j.u.concurrent utility seem a good replacement with the ThreadExecutionSynchronizer class. ThreadMXBean/Locks.java was written prior to j.u.concurrent added to the platform (both java.util.concurrent and java.lang.management were added in JDK 5). Later ThreadExecutionSynchronizer was added to fix some intermittent issue. I think it's worth the investigation to replace the existing logic with j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used by a few other tests). Mandy On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote: > Please, review the following patch of the intermittently failing test: > http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 > > Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 > > > Sometimes the ThreadExecutionSynchronizer class failes to achieve the > desired synchronization (due to possible data races when evaluating and > setting the "waiting" variable) leading to test failures. > > The patch fixes the possibility of data race. Also the Locks class is > tidied up a bit. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Tue Sep 3 23:56:56 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 04 Sep 2013 08:56:56 +0200 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <522699F3.5000904@oracle.com> References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com> Message-ID: <5226D9B8.1040402@oracle.com> On 09/04/2013 04:24 AM, Mandy Chung wrote: > Hi Jaroslav, > > Like Daniel and David said, CyclicBarrier and other j.u.concurrent > utility seem a good replacement with the ThreadExecutionSynchronizer > class. ThreadMXBean/Locks.java was written prior to j.u.concurrent > added to the platform (both java.util.concurrent and > java.lang.management were added in JDK 5). Later > ThreadExecutionSynchronizer was added to fix some intermittent issue. > > I think it's worth the investigation to replace the existing logic with > j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used > by a few other tests). Ok, let's go back to the basics :) The reason for the test to fail intermittently are stale reads from the "waiting" variable. In order to minimize the changes it seems sufficient to make the "waiting" variable volatile to prevent the stale reads. The code modifying the "waiting" variable is already guarded by the semaphore so we are good there. The changes in Locks.java are about more consistent approach to waiting for a thread to enter a desired state. I took Erik's recommendation to just wait indefinitely for the desired thread state and let the harness deal with timeouts. The very simplified patch is at http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03 I will file a task for JDK9 to remove ThreadExecutionSynchronizer and simplify java.lang.management tests using it. -JB- > > Mandy > > On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote: >> Please, review the following patch of the intermittently failing test: >> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 >> >> >> Sometimes the ThreadExecutionSynchronizer class failes to achieve the >> desired synchronization (due to possible data races when evaluating and >> setting the "waiting" variable) leading to test failures. >> >> The patch fixes the possibility of data race. Also the Locks class is >> tidied up a bit. >> >> Thanks, >> >> -JB- > From jaroslav.bachorik at oracle.com Wed Sep 4 00:16:03 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 04 Sep 2013 09:16:03 +0200 Subject: jmx-dev RFR: 8002307 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal representation by storing an externally mutable object In-Reply-To: <51E7BB6C.6030704@oracle.com> References: <51A4AB45.4070100@oracle.com> <51A4DC90.7050809@oracle.com> <51E7BB6C.6030704@oracle.com> Message-ID: <5226DE33.9000801@oracle.com> [ping] Thanks for the reviews. I still need a reviewer to take a look at this. This issue blocks a P2 targeted for JDK8 (JDK-7148504). Thanks, -JB- On 07/18/2013 11:54 AM, Jaroslav Bachorik wrote: > Hi, > > thanks for the comments. > > Here (http://cr.openjdk.java.net/~jbachorik/8002307/webrev.03/) is the > updated webrev implementing suggestions from Daniel and Shanliang. > > -JB- > > From daniel.fuchs at oracle.com Wed Sep 4 00:19:24 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 04 Sep 2013 09:19:24 +0200 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <5226D9B8.1040402@oracle.com> References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com> <5226D9B8.1040402@oracle.com> Message-ID: <5226DEFC.5000905@oracle.com> Hi Jaroslav, That looks like a reasonable small change if you are anxious to get that fix out of your plate fast. I'll trust that your analysis is right and that declaring waiting volatile is enough to fix the issue. It was certainly an error to access 'waiting' from multiple threads without any kind of synchronization. I'll be happy to see ThreadExecutionSynchronizer go away in JDK 9 :-) best regards, -- daniel On 9/4/13 8:56 AM, Jaroslav Bachorik wrote: > On 09/04/2013 04:24 AM, Mandy Chung wrote: >> Hi Jaroslav, >> >> Like Daniel and David said, CyclicBarrier and other j.u.concurrent >> utility seem a good replacement with the ThreadExecutionSynchronizer >> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent >> added to the platform (both java.util.concurrent and >> java.lang.management were added in JDK 5). Later >> ThreadExecutionSynchronizer was added to fix some intermittent issue. >> >> I think it's worth the investigation to replace the existing logic with >> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used >> by a few other tests). > > Ok, let's go back to the basics :) > > The reason for the test to fail intermittently are stale reads from the > "waiting" variable. In order to minimize the changes it seems sufficient > to make the "waiting" variable volatile to prevent the stale reads. The > code modifying the "waiting" variable is already guarded by the > semaphore so we are good there. > > The changes in Locks.java are about more consistent approach to waiting > for a thread to enter a desired state. I took Erik's recommendation to > just wait indefinitely for the desired thread state and let the harness > deal with timeouts. > > The very simplified patch is at > http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03 > > I will file a task for JDK9 to remove ThreadExecutionSynchronizer and > simplify java.lang.management tests using it. > > -JB- > >> Mandy >> >> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote: >>> Please, review the following patch of the intermittently failing test: >>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 >>> >>> >>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the >>> desired synchronization (due to possible data races when evaluating and >>> setting the "waiting" variable) leading to test failures. >>> >>> The patch fixes the possibility of data race. Also the Locks class is >>> tidied up a bit. >>> >>> Thanks, >>> >>> -JB- From david.holmes at oracle.com Wed Sep 4 01:29:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Sep 2013 18:29:05 +1000 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <5226D9B8.1040402@oracle.com> References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com> <5226D9B8.1040402@oracle.com> Message-ID: <5226EF51.8010402@oracle.com> On 4/09/2013 4:56 PM, Jaroslav Bachorik wrote: > On 09/04/2013 04:24 AM, Mandy Chung wrote: >> Hi Jaroslav, >> >> Like Daniel and David said, CyclicBarrier and other j.u.concurrent >> utility seem a good replacement with the ThreadExecutionSynchronizer >> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent >> added to the platform (both java.util.concurrent and >> java.lang.management were added in JDK 5). Later >> ThreadExecutionSynchronizer was added to fix some intermittent issue. >> >> I think it's worth the investigation to replace the existing logic with >> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used >> by a few other tests). > > > Ok, let's go back to the basics :) > > The reason for the test to fail intermittently are stale reads from the > "waiting" variable. In order to minimize the changes it seems sufficient > to make the "waiting" variable volatile to prevent the stale reads. The > code modifying the "waiting" variable is already guarded by the > semaphore so we are good there. Yes that seems valid. > The changes in Locks.java are about more consistent approach to waiting > for a thread to enter a desired state. I took Erik's recommendation to > just wait indefinitely for the desired thread state and let the harness > deal with timeouts. Yes that seems good too. > The very simplified patch is at > http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03 One thing you "fixed" in the original version but is no longer "fixed" is findOwnerInfo where you made the break exit both loops. I'm unclear if that is a correctness issue or just an optimization? I suspect an optimization and that once you have found what you need, lock.equals(blockedLock) will not be true for any other ThreadInfo objects. Thanks, David > I will file a task for JDK9 to remove ThreadExecutionSynchronizer and > simplify java.lang.management tests using it. > > -JB- > >> >> Mandy >> >> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote: >>> Please, review the following patch of the intermittently failing test: >>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 >>> >>> >>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the >>> desired synchronization (due to possible data races when evaluating and >>> setting the "waiting" variable) leading to test failures. >>> >>> The patch fixes the possibility of data race. Also the Locks class is >>> tidied up a bit. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Wed Sep 4 01:33:13 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 04 Sep 2013 10:33:13 +0200 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <5226EF51.8010402@oracle.com> References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com> <5226D9B8.1040402@oracle.com> <5226EF51.8010402@oracle.com> Message-ID: <5226F049.9090108@oracle.com> On 09/04/2013 10:29 AM, David Holmes wrote: > On 4/09/2013 4:56 PM, Jaroslav Bachorik wrote: >> On 09/04/2013 04:24 AM, Mandy Chung wrote: >>> Hi Jaroslav, >>> >>> Like Daniel and David said, CyclicBarrier and other j.u.concurrent >>> utility seem a good replacement with the ThreadExecutionSynchronizer >>> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent >>> added to the platform (both java.util.concurrent and >>> java.lang.management were added in JDK 5). Later >>> ThreadExecutionSynchronizer was added to fix some intermittent issue. >>> >>> I think it's worth the investigation to replace the existing logic with >>> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used >>> by a few other tests). >> >> >> Ok, let's go back to the basics :) >> >> The reason for the test to fail intermittently are stale reads from the >> "waiting" variable. In order to minimize the changes it seems sufficient >> to make the "waiting" variable volatile to prevent the stale reads. The >> code modifying the "waiting" variable is already guarded by the >> semaphore so we are good there. > > Yes that seems valid. > >> The changes in Locks.java are about more consistent approach to waiting >> for a thread to enter a desired state. I took Erik's recommendation to >> just wait indefinitely for the desired thread state and let the harness >> deal with timeouts. > > Yes that seems good too. > >> The very simplified patch is at >> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03 > > One thing you "fixed" in the original version but is no longer "fixed" > is findOwnerInfo where you made the break exit both loops. I'm unclear > if that is a correctness issue or just an optimization? I suspect an > optimization and that once you have found what you need, > lock.equals(blockedLock) will not be true for any other ThreadInfo objects. Exactly. It was an optimization and I excluded the change to keep the fix very simple - given that the whole test would very likely be rewritten for JDK9. -JB- > > Thanks, > David > >> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and >> simplify java.lang.management tests using it. >> >> -JB- >> >>> >>> Mandy >>> >>> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote: >>>> Please, review the following patch of the intermittently failing test: >>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 >>>> >>>> >>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the >>>> desired synchronization (due to possible data races when evaluating and >>>> setting the "waiting" variable) leading to test failures. >>>> >>>> The patch fixes the possibility of data race. Also the Locks class is >>>> tidied up a bit. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> From shanliang.jiang at oracle.com Thu Sep 5 01:37:46 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 05 Sep 2013 10:37:46 +0200 Subject: jmx-dev Codereview request: 8023529 OpenMBeanInfoSupport.equals/hashCode throw NPE Message-ID: <522842DA.6010908@oracle.com> I have added 2 tasts to make sure that call OpenMBean*InfoSupport.equals/hashCode do not throw NPE The unit tests and JCK tests are passed. Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8023529 Thanks, Shanliang From jaroslav.bachorik at oracle.com Thu Sep 5 03:59:01 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Sep 2013 12:59:01 +0200 Subject: jmx-dev Codereview request: 8023529 OpenMBeanInfoSupport.equals/hashCode throw NPE In-Reply-To: <522842DA.6010908@oracle.com> References: <522842DA.6010908@oracle.com> Message-ID: <522863F5.20709@oracle.com> On 09/05/2013 10:37 AM, shanliang wrote: > I have added 2 tasts to make sure that call > OpenMBean*InfoSupport.equals/hashCode do not throw NPE > The unit tests and JCK tests are passed. > > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8023529 javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java * rename the "obj1", "obj2" parameters to something more explicit - eg. "referenceInfo" and "nullValueinfo" or something similar * when testing "obj.equals(null);" the messages should not contain reference to the parameter since you are not, in fact, testing the null value of the given parameter but rather a null info object * the message "got NPE if null paramer" should read "got NPE for null paramter" * "Thread.sleep(100);" on line 153 is necessary? ----- javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java * the message "got NPE if null paramer" should read "got NPE for null paramter" * "Thread.sleep(100);" on line 143 is necessary? -JB- > > Thanks, > > Shanliang From jaroslav.bachorik at oracle.com Thu Sep 5 05:52:12 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Sep 2013 14:52:12 +0200 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <5226F049.9090108@oracle.com> References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com> <5226D9B8.1040402@oracle.com> <5226EF51.8010402@oracle.com> <5226F049.9090108@oracle.com> Message-ID: <52287E7C.3050107@oracle.com> On 09/04/2013 10:33 AM, Jaroslav Bachorik wrote: > On 09/04/2013 10:29 AM, David Holmes wrote: >> On 4/09/2013 4:56 PM, Jaroslav Bachorik wrote: >>> On 09/04/2013 04:24 AM, Mandy Chung wrote: >>>> Hi Jaroslav, >>>> >>>> Like Daniel and David said, CyclicBarrier and other j.u.concurrent >>>> utility seem a good replacement with the ThreadExecutionSynchronizer >>>> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent >>>> added to the platform (both java.util.concurrent and >>>> java.lang.management were added in JDK 5). Later >>>> ThreadExecutionSynchronizer was added to fix some intermittent issue. >>>> >>>> I think it's worth the investigation to replace the existing logic with >>>> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used >>>> by a few other tests). >>> >>> >>> Ok, let's go back to the basics :) >>> >>> The reason for the test to fail intermittently are stale reads from the >>> "waiting" variable. In order to minimize the changes it seems sufficient >>> to make the "waiting" variable volatile to prevent the stale reads. The >>> code modifying the "waiting" variable is already guarded by the >>> semaphore so we are good there. >> >> Yes that seems valid. >> >>> The changes in Locks.java are about more consistent approach to waiting >>> for a thread to enter a desired state. I took Erik's recommendation to >>> just wait indefinitely for the desired thread state and let the harness >>> deal with timeouts. >> >> Yes that seems good too. >> >>> The very simplified patch is at >>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03 >> >> One thing you "fixed" in the original version but is no longer "fixed" >> is findOwnerInfo where you made the break exit both loops. I'm unclear >> if that is a correctness issue or just an optimization? I suspect an >> optimization and that once you have found what you need, >> lock.equals(blockedLock) will not be true for any other ThreadInfo objects. > > Exactly. It was an optimization and I excluded the change to keep the > fix very simple - given that the whole test would very likely be > rewritten for JDK9. Task for removal of java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer filed - JDK-8024326 So, is this change good to go? Thanks, -JB- > > -JB- > >> >> Thanks, >> David >> >>> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and >>> simplify java.lang.management tests using it. >>> >>> -JB- >>> >>>> >>>> Mandy >>>> >>>> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote: >>>>> Please, review the following patch of the intermittently failing test: >>>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 >>>>> >>>>> >>>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the >>>>> desired synchronization (due to possible data races when evaluating and >>>>> setting the "waiting" variable) leading to test failures. >>>>> >>>>> The patch fixes the possibility of data race. Also the Locks class is >>>>> tidied up a bit. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> > From daniel.fuchs at oracle.com Thu Sep 5 05:59:50 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 05 Sep 2013 14:59:50 +0200 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <52287E7C.3050107@oracle.com> References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com> <5226D9B8.1040402@oracle.com> <5226EF51.8010402@oracle.com> <5226F049.9090108@oracle.com> <52287E7C.3050107@oracle.com> Message-ID: <52288046.9020100@oracle.com> On 9/5/13 2:52 PM, Jaroslav Bachorik wrote: > On 09/04/2013 10:33 AM, Jaroslav Bachorik wrote: >> On 09/04/2013 10:29 AM, David Holmes wrote: >>> On 4/09/2013 4:56 PM, Jaroslav Bachorik wrote: >>>> On 09/04/2013 04:24 AM, Mandy Chung wrote: >>>>> Hi Jaroslav, >>>>> >>>>> Like Daniel and David said, CyclicBarrier and other j.u.concurrent >>>>> utility seem a good replacement with the ThreadExecutionSynchronizer >>>>> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent >>>>> added to the platform (both java.util.concurrent and >>>>> java.lang.management were added in JDK 5). Later >>>>> ThreadExecutionSynchronizer was added to fix some intermittent issue. >>>>> >>>>> I think it's worth the investigation to replace the existing logic with >>>>> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used >>>>> by a few other tests). >>>> >>>> >>>> Ok, let's go back to the basics :) >>>> >>>> The reason for the test to fail intermittently are stale reads from the >>>> "waiting" variable. In order to minimize the changes it seems sufficient >>>> to make the "waiting" variable volatile to prevent the stale reads. The >>>> code modifying the "waiting" variable is already guarded by the >>>> semaphore so we are good there. >>> >>> Yes that seems valid. >>> >>>> The changes in Locks.java are about more consistent approach to waiting >>>> for a thread to enter a desired state. I took Erik's recommendation to >>>> just wait indefinitely for the desired thread state and let the harness >>>> deal with timeouts. >>> >>> Yes that seems good too. >>> >>>> The very simplified patch is at >>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03 >>> >>> One thing you "fixed" in the original version but is no longer "fixed" >>> is findOwnerInfo where you made the break exit both loops. I'm unclear >>> if that is a correctness issue or just an optimization? I suspect an >>> optimization and that once you have found what you need, >>> lock.equals(blockedLock) will not be true for any other ThreadInfo objects. >> >> Exactly. It was an optimization and I excluded the change to keep the >> fix very simple - given that the whole test would very likely be >> rewritten for JDK9. > > Task for removal of > java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer filed - > JDK-8024326 > > So, is this change good to go? In what I'm concerned yes - but I'm not a reviewer... cheers, -- daniel > > Thanks, > > -JB- > >> >> -JB- >> >>> >>> Thanks, >>> David >>> >>>> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and >>>> simplify java.lang.management tests using it. >>>> >>>> -JB- >>>> >>>>> >>>>> Mandy >>>>> >>>>> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote: >>>>>> Please, review the following patch of the intermittently failing test: >>>>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 >>>>>> >>>>>> >>>>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the >>>>>> desired synchronization (due to possible data races when evaluating and >>>>>> setting the "waiting" variable) leading to test failures. >>>>>> >>>>>> The patch fixes the possibility of data race. Also the Locks class is >>>>>> tidied up a bit. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >> > From mandy.chung at oracle.com Thu Sep 5 11:37:15 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Sep 2013 11:37:15 -0700 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <5226D9B8.1040402@oracle.com> References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com> <5226D9B8.1040402@oracle.com> Message-ID: <5228CF5B.5010207@oracle.com> On 9/3/13 11:56 PM, Jaroslav Bachorik wrote: > > Ok, let's go back to the basics :) > > The reason for the test to fail intermittently are stale reads from the > "waiting" variable. In order to minimize the changes it seems sufficient > to make the "waiting" variable volatile to prevent the stale reads. The > code modifying the "waiting" variable is already guarded by the > semaphore so we are good there. > > The changes in Locks.java are about more consistent approach to waiting > for a thread to enter a desired state. I took Erik's recommendation to > just wait indefinitely for the desired thread state and let the harness > deal with timeouts. > > The very simplified patch is at > http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03 This simple change looks good. There are a couple of other tests using ThreadExecutionSynchronizer. Not sure if they run into this intermittent issue; if so, similiar fix might apply - just to mention it. Anyway this fix is good to go. > I will file a task for JDK9 to remove ThreadExecutionSynchronizer and > simplify java.lang.management tests using it. > Thanks for filing the bug for JDK9. Mandy From david.holmes at oracle.com Thu Sep 5 19:18:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Sep 2013 12:18:01 +1000 Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure In-Reply-To: <52287E7C.3050107@oracle.com> References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com> <5226D9B8.1040402@oracle.com> <5226EF51.8010402@oracle.com> <5226F049.9090108@oracle.com> <52287E7C.3050107@oracle.com> Message-ID: <52293B59.90608@oracle.com> Seems good to go to me. David On 5/09/2013 10:52 PM, Jaroslav Bachorik wrote: > On 09/04/2013 10:33 AM, Jaroslav Bachorik wrote: >> On 09/04/2013 10:29 AM, David Holmes wrote: >>> On 4/09/2013 4:56 PM, Jaroslav Bachorik wrote: >>>> On 09/04/2013 04:24 AM, Mandy Chung wrote: >>>>> Hi Jaroslav, >>>>> >>>>> Like Daniel and David said, CyclicBarrier and other j.u.concurrent >>>>> utility seem a good replacement with the ThreadExecutionSynchronizer >>>>> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent >>>>> added to the platform (both java.util.concurrent and >>>>> java.lang.management were added in JDK 5). Later >>>>> ThreadExecutionSynchronizer was added to fix some intermittent issue. >>>>> >>>>> I think it's worth the investigation to replace the existing logic with >>>>> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used >>>>> by a few other tests). >>>> >>>> >>>> Ok, let's go back to the basics :) >>>> >>>> The reason for the test to fail intermittently are stale reads from the >>>> "waiting" variable. In order to minimize the changes it seems sufficient >>>> to make the "waiting" variable volatile to prevent the stale reads. The >>>> code modifying the "waiting" variable is already guarded by the >>>> semaphore so we are good there. >>> >>> Yes that seems valid. >>> >>>> The changes in Locks.java are about more consistent approach to waiting >>>> for a thread to enter a desired state. I took Erik's recommendation to >>>> just wait indefinitely for the desired thread state and let the harness >>>> deal with timeouts. >>> >>> Yes that seems good too. >>> >>>> The very simplified patch is at >>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03 >>> >>> One thing you "fixed" in the original version but is no longer "fixed" >>> is findOwnerInfo where you made the break exit both loops. I'm unclear >>> if that is a correctness issue or just an optimization? I suspect an >>> optimization and that once you have found what you need, >>> lock.equals(blockedLock) will not be true for any other ThreadInfo objects. >> >> Exactly. It was an optimization and I excluded the change to keep the >> fix very simple - given that the whole test would very likely be >> rewritten for JDK9. > > Task for removal of > java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer filed - > JDK-8024326 > > So, is this change good to go? > > Thanks, > > -JB- > >> >> -JB- >> >>> >>> Thanks, >>> David >>> >>>> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and >>>> simplify java.lang.management tests using it. >>>> >>>> -JB- >>>> >>>>> >>>>> Mandy >>>>> >>>>> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote: >>>>>> Please, review the following patch of the intermittently failing test: >>>>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 >>>>>> >>>>>> >>>>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the >>>>>> desired synchronization (due to possible data races when evaluating and >>>>>> setting the "waiting" variable) leading to test failures. >>>>>> >>>>>> The patch fixes the possibility of data race. Also the Locks class is >>>>>> tidied up a bit. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >> > From shanliang.jiang at oracle.com Fri Sep 6 04:24:34 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 06 Sep 2013 13:24:34 +0200 Subject: jmx-dev Codereview request: 8023529 MBean*Info.equals: throw NPE Message-ID: <5229BB72.4060502@oracle.com> Hi, Thanks to review the following fix: webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8023954 Shanliang From daniel.fuchs at oracle.com Fri Sep 6 05:44:55 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 06 Sep 2013 14:44:55 +0200 Subject: jmx-dev Codereview request: 8023529 MBean*Info.equals: throw NPE In-Reply-To: <5229BB72.4060502@oracle.com> References: <5229BB72.4060502@oracle.com> Message-ID: <5229CE47.7080802@oracle.com> On 9/6/13 1:24 PM, shanliang wrote: > Hi, > > Thanks to review the following fix: > > webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8023954 > > Shanliang > Hi Shanliang, Looks good - but it looks as if some hashCode() will suffer from the same issue (for instance MBeanOperationInfo.hashCode) Do you have an other defect to track that? I have to wonder why we allow to create an MBeanOperationInfo with a null name though... I wished the first implementation had thrown NPE at construction time. -- daniel From shanliang.jiang at oracle.com Fri Sep 6 06:17:00 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 06 Sep 2013 15:17:00 +0200 Subject: jmx-dev Codereview request: 8023529 MBean*Info.equals: throw NPE In-Reply-To: <5229CE47.7080802@oracle.com> References: <5229BB72.4060502@oracle.com> <5229CE47.7080802@oracle.com> Message-ID: <5229D5CC.3030006@oracle.com> Daniel Fuchs wrote: > On 9/6/13 1:24 PM, shanliang wrote: >> Hi, >> >> Thanks to review the following fix: >> >> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8023954 >> >> Shanliang >> > > Hi Shanliang, > > Looks good - but it looks as if some hashCode() will suffer from the > same issue (for instance MBeanOperationInfo.hashCode) > > Do you have an other defect to track that? We have another bug JDK-8023669 and thank you for having done the code review :) I am waiting a reviewer's review for push the fix > > I have to wonder why we allow to create an MBeanOperationInfo > with a null name though... I wished the first implementation > had thrown NPE at construction time. I had same wondering, but I had no intention to modify it because that is related to the specification. The class OpenMBeanOperation does refuse a null or empty class name. Shanliang > > -- daniel From shanliang.jiang at oracle.com Tue Sep 10 07:15:33 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 10 Sep 2013 16:15:33 +0200 Subject: jmx-dev Codereview request: 8023529 OpenMBeanInfoSupport.equals/hashCode throw NPE In-Reply-To: <522863F5.20709@oracle.com> References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com> Message-ID: <522F2985.80207@oracle.com> Jaroslav Bachorik wrote: > On 09/05/2013 10:37 AM, shanliang wrote: > >> I have added 2 tasts to make sure that call >> OpenMBean*InfoSupport.equals/hashCode do not throw NPE >> The unit tests and JCK tests are passed. >> >> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8023529 >> > > javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java > > * rename the "obj1", "obj2" parameters to something more explicit - eg. > "referenceInfo" and "nullValueinfo" or something similar > No reference object here, the test has to call both obj1.equals and obj2.equals. > * when testing "obj.equals(null);" the messages should not contain > reference to the parameter since you are not, in fact, testing the null > value of the given parameter but rather a null info object > * the message "got NPE if null paramer" should read "got NPE for null > paramter" > Right, should be "a null object" instead of "a null parameter." > * "Thread.sleep(100);" on line 153 is necessary? > It is not necessary for the test, removed now. > ----- > > javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java > > * the message "got NPE if null paramer" should read "got NPE for null > paramter" > * "Thread.sleep(100);" on line 143 is necessary? > Thanks for the review, here is the new version: http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/ Shanliang > > -JB- > > >> Thanks, >> >> Shanliang >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20130910/c2ab9f86/attachment.html From david.holmes at oracle.com Tue Sep 10 16:48:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Sep 2013 09:48:48 +1000 Subject: jmx-dev Codereview request: 8023529 OpenMBeanInfoSupport.equals/hashCode throw NPE In-Reply-To: <522F2985.80207@oracle.com> References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com> <522F2985.80207@oracle.com> Message-ID: <522FAFE0.1050304@oracle.com> I'm a bit confused. The two webrevs are vastly different: http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/ http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/ Should they be combined somehow? David ----- On 11/09/2013 12:15 AM, shanliang wrote: > Jaroslav Bachorik wrote: >> On 09/05/2013 10:37 AM, shanliang wrote: >> >>> I have added 2 tasts to make sure that call >>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE >>> The unit tests and JCK tests are passed. >>> >>> Webrev:http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/ >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8023529 >>> >> >> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java >> >> * rename the "obj1", "obj2" parameters to something more explicit - eg. >> "referenceInfo" and "nullValueinfo" or something similar >> > No reference object here, the test has to call both obj1.equals and > obj2.equals. >> * when testing "obj.equals(null);" the messages should not contain >> reference to the parameter since you are not, in fact, testing the null >> value of the given parameter but rather a null info object >> * the message "got NPE if null paramer" should read "got NPE for null >> paramter" >> > Right, should be "a null object" instead of "a null parameter." >> * "Thread.sleep(100);" on line 153 is necessary? >> > It is not necessary for the test, removed now. >> ----- >> >> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java >> >> * the message "got NPE if null paramer" should read "got NPE for null >> paramter" >> * "Thread.sleep(100);" on line 143 is necessary? >> > Thanks for the review, here is the new version: > > http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/ > > Shanliang >> >> -JB- >> >> >>> Thanks, >>> >>> Shanliang >>> >> >> > From david.holmes at oracle.com Tue Sep 10 17:05:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Sep 2013 10:05:17 +1000 Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode : NPE In-Reply-To: <521F5697.3040108@oracle.com> References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com> <521F5697.3040108@oracle.com> Message-ID: <522FB3BD.2040008@oracle.com> On 30/08/2013 12:11 AM, shanliang wrote: > Here is the new version: > http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/ This seems good to address the NPE potential. You are changing the values of the hashcodes though - is that a problem? In javax/management/MBeanInfo.java Objects.hash(getClassName(), getDescriptor().hashCode()) should, I think, be Objects.hash(getClassName(), getDescriptor()) David ----- > Indeed, calling Objects.hash(Object ...) is a good idea, which > simplifies the code. > > I used also Arrays.hashCode() to simplify the code, now the fix likes > really simple. > > I have passed JCK tests, unit tests of management are passed too in my > desk. > > toString() worked perfectly in the test, nothing to fix. > > Shanliang > > Daniel Fuchs wrote: >> On 8/29/13 9:34 AM, shanliang wrote: >>> Hi, >>> >>> Please review following fix, it addresses the issue only in the method >>> "hashCode": >>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669 >>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/ >>> >>> Thanks, >>> Shanliang >>> >> >> Hi Shanliang, >> >> >> >> >> I suggest to simplify this by calling: >> >> public int hashCode() { >> return Objects.hash(getName(), getType()); >> } >> >> (see >> ) >> >> >> >> >> >> int hash = getName() == null ? 10 : getName().hashCode(); >> >> could be replaced by: >> >> int hash = Objects.hashCode(getName()); >> >> Generally - and that stands for the other files you modified, you can >> simplify things by replacing x.hashCode() with Objects.hashCode(x) >> whenever there's the possibility that x can be null. >> >> Note however that Objects is an API @since JDK 7 - so if you intend >> to backport this fix to 6 & 5 you will need to alter your changeset >> when backporting it. >> >> >> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest >> to use Objects.hash(...); >> >> best regards, >> >> -- daniel >> >> BTW: one more question: you're also testing toString() in the test >> and that's good - but are there any toString() that will require >> fixing? >> >> > From shanliang.jiang at oracle.com Tue Sep 10 23:44:12 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 11 Sep 2013 08:44:12 +0200 Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode : NPE In-Reply-To: <522FB3BD.2040008@oracle.com> References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com> <521F5697.3040108@oracle.com> <522FB3BD.2040008@oracle.com> Message-ID: <5230113C.1010308@oracle.com> David Holmes wrote: > On 30/08/2013 12:11 AM, shanliang wrote: >> Here is the new version: >> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/ > > This seems good to address the NPE potential. > > You are changing the values of the hashcodes though - is that a problem? Good question! It should not be a problem. The value "hashCode" is declared as "private transient", so it must be always same for an MBeanInfo instance within a VM. > > In javax/management/MBeanInfo.java > > Objects.hash(getClassName(), getDescriptor().hashCode()) > > should, I think, be > > Objects.hash(getClassName(), getDescriptor()) Yes you are right, corrected in the new version: http://cr.openjdk.java.net/~sjiang/jdk-8023669/02/ thanks, Shanliang > > David > ----- > >> Indeed, calling Objects.hash(Object ...) is a good idea, which >> simplifies the code. >> >> I used also Arrays.hashCode() to simplify the code, now the fix likes >> really simple. >> >> I have passed JCK tests, unit tests of management are passed too in my >> desk. >> >> toString() worked perfectly in the test, nothing to fix. >> >> Shanliang >> >> Daniel Fuchs wrote: >>> On 8/29/13 9:34 AM, shanliang wrote: >>>> Hi, >>>> >>>> Please review following fix, it addresses the issue only in the method >>>> "hashCode": >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669 >>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/ >>>> >>>> Thanks, >>>> Shanliang >>>> >>> >>> Hi Shanliang, >>> >>> >>> >>> >>> >>> I suggest to simplify this by calling: >>> >>> public int hashCode() { >>> return Objects.hash(getName(), getType()); >>> } >>> >>> (see >>> ) >>> >>> >>> >>> >>> >>> >>> >>> int hash = getName() == null ? 10 : getName().hashCode(); >>> >>> could be replaced by: >>> >>> int hash = Objects.hashCode(getName()); >>> >>> Generally - and that stands for the other files you modified, you can >>> simplify things by replacing x.hashCode() with Objects.hashCode(x) >>> whenever there's the possibility that x can be null. >>> >>> Note however that Objects is an API @since JDK 7 - so if you intend >>> to backport this fix to 6 & 5 you will need to alter your changeset >>> when backporting it. >>> >>> >>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest >>> to use Objects.hash(...); >>> >>> best regards, >>> >>> -- daniel >>> >>> BTW: one more question: you're also testing toString() in the test >>> and that's good - but are there any toString() that will require >>> fixing? >>> >>> >> From shanliang.jiang at oracle.com Wed Sep 11 00:33:52 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 11 Sep 2013 09:33:52 +0200 Subject: jmx-dev Codereview request: 8023529 OpenMBeanInfoSupport.equals/hashCode throw NPE In-Reply-To: <522FAFE0.1050304@oracle.com> References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com> <522F2985.80207@oracle.com> <522FAFE0.1050304@oracle.com> Message-ID: <52301CE0.2040407@oracle.com> David Holmes wrote: > I'm a bit confused. The two webrevs are vastly different: > > http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/ > > http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/ > > Should they be combined somehow? The version 01 is correct. The version 00 was a mistake, yesterday I had some problems to generate the version 01, so the version 00 was re-generated by mistake with another fix, sorry for this confusing. Thanks, Shanliang > > David > ----- > > On 11/09/2013 12:15 AM, shanliang wrote: >> Jaroslav Bachorik wrote: >>> On 09/05/2013 10:37 AM, shanliang wrote: >>> >>>> I have added 2 tasts to make sure that call >>>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE >>>> The unit tests and JCK tests are passed. >>>> >>>> Webrev:http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/ >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8023529 >>>> >>> >>> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java >>> >>> * rename the "obj1", "obj2" parameters to something more explicit - eg. >>> "referenceInfo" and "nullValueinfo" or something similar >>> >> No reference object here, the test has to call both obj1.equals and >> obj2.equals. >>> * when testing "obj.equals(null);" the messages should not contain >>> reference to the parameter since you are not, in fact, testing the null >>> value of the given parameter but rather a null info object >>> * the message "got NPE if null paramer" should read "got NPE for null >>> paramter" >>> >> Right, should be "a null object" instead of "a null parameter." >>> * "Thread.sleep(100);" on line 153 is necessary? >>> >> It is not necessary for the test, removed now. >>> ----- >>> >>> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java >>> >>> * the message "got NPE if null paramer" should read "got NPE for null >>> paramter" >>> * "Thread.sleep(100);" on line 143 is necessary? >>> >> Thanks for the review, here is the new version: >> >> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/ >> >> Shanliang >>> >>> -JB- >>> >>> >>>> Thanks, >>>> >>>> Shanliang >>>> >>> >>> >> From daniel.fuchs at oracle.com Wed Sep 11 00:37:01 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 Sep 2013 09:37:01 +0200 Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode : NPE In-Reply-To: <522FB3BD.2040008@oracle.com> References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com> <521F5697.3040108@oracle.com> <522FB3BD.2040008@oracle.com> Message-ID: <52301D9D.1040706@oracle.com> On 9/11/13 2:05 AM, David Holmes wrote: > On 30/08/2013 12:11 AM, shanliang wrote: >> Here is the new version: >> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/ > > This seems good to address the NPE potential. > > You are changing the values of the hashcodes though - is that a problem? Hi David, The algorithm by which hashCode() is computed isn't specified - so it shouldn't be an issue changing it - should it? I must say I don't know how HashMap is serialized - for instance. So assuming we have an App1 sending a Map of MBeanInfos to an App2 over the wire, is that a problem if in App2 the MBeanInfo hashCodes resolve to different values? I assume it doesn't... I have never considered values of hashCode() to be part of the standard/API. Since the algorithm isn't specified, then 2 implementations of the standard should be free to use different algorithms - and this shouldn't prevent then to interoperate. So I hope we're safe in modifying the hashCode algorithm. The important part is that it still satisfies the hashCode/equals contract. cheers, -- daniel > > In javax/management/MBeanInfo.java > > Objects.hash(getClassName(), getDescriptor().hashCode()) > > should, I think, be > > Objects.hash(getClassName(), getDescriptor()) > David > ----- > >> Indeed, calling Objects.hash(Object ...) is a good idea, which >> simplifies the code. >> >> I used also Arrays.hashCode() to simplify the code, now the fix likes >> really simple. >> >> I have passed JCK tests, unit tests of management are passed too in my >> desk. >> >> toString() worked perfectly in the test, nothing to fix. >> >> Shanliang >> >> Daniel Fuchs wrote: >>> On 8/29/13 9:34 AM, shanliang wrote: >>>> Hi, >>>> >>>> Please review following fix, it addresses the issue only in the method >>>> "hashCode": >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669 >>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/ >>>> >>>> Thanks, >>>> Shanliang >>>> >>> >>> Hi Shanliang, >>> >>> >>> >>> >>> >>> I suggest to simplify this by calling: >>> >>> public int hashCode() { >>> return Objects.hash(getName(), getType()); >>> } >>> >>> (see >>> ) >>> >>> >>> >>> >>> >>> >>> >>> int hash = getName() == null ? 10 : getName().hashCode(); >>> >>> could be replaced by: >>> >>> int hash = Objects.hashCode(getName()); >>> >>> Generally - and that stands for the other files you modified, you can >>> simplify things by replacing x.hashCode() with Objects.hashCode(x) >>> whenever there's the possibility that x can be null. >>> >>> Note however that Objects is an API @since JDK 7 - so if you intend >>> to backport this fix to 6 & 5 you will need to alter your changeset >>> when backporting it. >>> >>> >>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest >>> to use Objects.hash(...); >>> >>> best regards, >>> >>> -- daniel >>> >>> BTW: one more question: you're also testing toString() in the test >>> and that's good - but are there any toString() that will require >>> fixing? >>> >>> >> From shanliang.jiang at oracle.com Wed Sep 11 00:54:52 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 11 Sep 2013 09:54:52 +0200 Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode : NPE In-Reply-To: <52301D9D.1040706@oracle.com> References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com> <521F5697.3040108@oracle.com> <522FB3BD.2040008@oracle.com> <52301D9D.1040706@oracle.com> Message-ID: <523021CC.3050506@oracle.com> Daniel Fuchs wrote: > On 9/11/13 2:05 AM, David Holmes wrote: >> On 30/08/2013 12:11 AM, shanliang wrote: >>> Here is the new version: >>> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/ >> >> This seems good to address the NPE potential. >> >> You are changing the values of the hashcodes though - is that a problem? > Hi David, > > The algorithm by which hashCode() is computed isn't specified - so it > shouldn't > be an issue changing it - should it? > > I must say I don't know how HashMap is serialized - for instance. So > assuming > we have an App1 sending a Map of MBeanInfos to an App2 over the wire, > is that > a problem if in App2 the MBeanInfo hashCodes resolve to different values? > I assume it doesn't... If app1 sends a Map to app2, the hashCode of each key (MBeanInfo) will be re-calculated in app2, it is because the variable "hashCode" of an MBeanOInfo is declared as "transient", the value calculated in the app1 is not serialized and sent to the app2. So must no problem here. An exception is that we have Map, and the key "int" here is hashCode of an MBeanInfo, if app1 sends this map to app2, then app2 uses an MBenInfo's hashCode to look for a value in the map. But this seems little possible. Thanks, Shanliang > > I have never considered values of hashCode() to be part of the > standard/API. > Since the algorithm isn't specified, then 2 implementations of the > standard should > be free to use different algorithms - and this shouldn't prevent then to > interoperate. So I hope we're safe in modifying the hashCode algorithm. > > The important part is that it still satisfies the hashCode/equals > contract. > > cheers, > > -- daniel > >> >> In javax/management/MBeanInfo.java >> >> Objects.hash(getClassName(), getDescriptor().hashCode()) >> >> should, I think, be >> >> Objects.hash(getClassName(), getDescriptor()) >> David >> ----- >> >>> Indeed, calling Objects.hash(Object ...) is a good idea, which >>> simplifies the code. >>> >>> I used also Arrays.hashCode() to simplify the code, now the fix likes >>> really simple. >>> >>> I have passed JCK tests, unit tests of management are passed too in my >>> desk. >>> >>> toString() worked perfectly in the test, nothing to fix. >>> >>> Shanliang >>> >>> Daniel Fuchs wrote: >>>> On 8/29/13 9:34 AM, shanliang wrote: >>>>> Hi, >>>>> >>>>> Please review following fix, it addresses the issue only in the >>>>> method >>>>> "hashCode": >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669 >>>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/ >>>>> >>>>> Thanks, >>>>> Shanliang >>>>> >>>> >>>> Hi Shanliang, >>>> >>>> >>>> >>>> >>>> >>>> I suggest to simplify this by calling: >>>> >>>> public int hashCode() { >>>> return Objects.hash(getName(), getType()); >>>> } >>>> >>>> (see >>>> ) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> int hash = getName() == null ? 10 : getName().hashCode(); >>>> >>>> could be replaced by: >>>> >>>> int hash = Objects.hashCode(getName()); >>>> >>>> Generally - and that stands for the other files you modified, you can >>>> simplify things by replacing x.hashCode() with Objects.hashCode(x) >>>> whenever there's the possibility that x can be null. >>>> >>>> Note however that Objects is an API @since JDK 7 - so if you intend >>>> to backport this fix to 6 & 5 you will need to alter your changeset >>>> when backporting it. >>>> >>>> >>>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest >>>> to use Objects.hash(...); >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> BTW: one more question: you're also testing toString() in the test >>>> and that's good - but are there any toString() that will require >>>> fixing? >>>> >>>> >>> > From jaroslav.bachorik at oracle.com Wed Sep 11 01:16:43 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 11 Sep 2013 10:16:43 +0200 Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode : NPE In-Reply-To: <523021CC.3050506@oracle.com> References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com> <521F5697.3040108@oracle.com> <522FB3BD.2040008@oracle.com> <52301D9D.1040706@oracle.com> <523021CC.3050506@oracle.com> Message-ID: <523026EB.8090801@oracle.com> On 09/11/2013 09:54 AM, shanliang wrote: > Daniel Fuchs wrote: >> On 9/11/13 2:05 AM, David Holmes wrote: >>> On 30/08/2013 12:11 AM, shanliang wrote: >>>> Here is the new version: >>>> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/ >>> >>> This seems good to address the NPE potential. >>> >>> You are changing the values of the hashcodes though - is that a problem? >> Hi David, >> >> The algorithm by which hashCode() is computed isn't specified - so it >> shouldn't >> be an issue changing it - should it? >> >> I must say I don't know how HashMap is serialized - for instance. So >> assuming >> we have an App1 sending a Map of MBeanInfos to an App2 over the wire, >> is that >> a problem if in App2 the MBeanInfo hashCodes resolve to different values? >> I assume it doesn't... > If app1 sends a Map to app2, the hashCode of each key > (MBeanInfo) will be re-calculated in app2, it is because the variable > "hashCode" of an MBeanOInfo is declared as "transient", the value > calculated in the app1 is not serialized and sent to the app2. So must > no problem here. > > An exception is that we have Map, and the key "int" here is > hashCode of an MBeanInfo, if app1 sends this map to app2, then app2 uses > an MBenInfo's hashCode to look for a value in the map. But this seems > little possible. Storing objects in a map by their hashcodes makes little sense. Two distinct objects can share the same hashcode easily - thus this kind of usage would mess up the application anyway. -JB- > > Thanks, > Shanliang >> >> I have never considered values of hashCode() to be part of the >> standard/API. >> Since the algorithm isn't specified, then 2 implementations of the >> standard should >> be free to use different algorithms - and this shouldn't prevent then to >> interoperate. So I hope we're safe in modifying the hashCode algorithm. >> >> The important part is that it still satisfies the hashCode/equals >> contract. >> >> cheers, >> >> -- daniel >> >>> >>> In javax/management/MBeanInfo.java >>> >>> Objects.hash(getClassName(), getDescriptor().hashCode()) >>> >>> should, I think, be >>> >>> Objects.hash(getClassName(), getDescriptor()) >>> David >>> ----- >>> >>>> Indeed, calling Objects.hash(Object ...) is a good idea, which >>>> simplifies the code. >>>> >>>> I used also Arrays.hashCode() to simplify the code, now the fix likes >>>> really simple. >>>> >>>> I have passed JCK tests, unit tests of management are passed too in my >>>> desk. >>>> >>>> toString() worked perfectly in the test, nothing to fix. >>>> >>>> Shanliang >>>> >>>> Daniel Fuchs wrote: >>>>> On 8/29/13 9:34 AM, shanliang wrote: >>>>>> Hi, >>>>>> >>>>>> Please review following fix, it addresses the issue only in the >>>>>> method >>>>>> "hashCode": >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669 >>>>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/ >>>>>> >>>>>> Thanks, >>>>>> Shanliang >>>>>> >>>>> >>>>> Hi Shanliang, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I suggest to simplify this by calling: >>>>> >>>>> public int hashCode() { >>>>> return Objects.hash(getName(), getType()); >>>>> } >>>>> >>>>> (see >>>>> ) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> int hash = getName() == null ? 10 : getName().hashCode(); >>>>> >>>>> could be replaced by: >>>>> >>>>> int hash = Objects.hashCode(getName()); >>>>> >>>>> Generally - and that stands for the other files you modified, you can >>>>> simplify things by replacing x.hashCode() with Objects.hashCode(x) >>>>> whenever there's the possibility that x can be null. >>>>> >>>>> Note however that Objects is an API @since JDK 7 - so if you intend >>>>> to backport this fix to 6 & 5 you will need to alter your changeset >>>>> when backporting it. >>>>> >>>>> >>>>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest >>>>> to use Objects.hash(...); >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> BTW: one more question: you're also testing toString() in the test >>>>> and that's good - but are there any toString() that will require >>>>> fixing? >>>>> >>>>> >>>> >> > From david.holmes at oracle.com Wed Sep 11 01:20:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Sep 2013 18:20:30 +1000 Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode : NPE In-Reply-To: <52301D9D.1040706@oracle.com> References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com> <521F5697.3040108@oracle.com> <522FB3BD.2040008@oracle.com> <52301D9D.1040706@oracle.com> Message-ID: <523027CE.4020009@oracle.com> On 11/09/2013 5:37 PM, Daniel Fuchs wrote: > On 9/11/13 2:05 AM, David Holmes wrote: >> On 30/08/2013 12:11 AM, shanliang wrote: >>> Here is the new version: >>> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/ >> >> This seems good to address the NPE potential. >> >> You are changing the values of the hashcodes though - is that a problem? > Hi David, > > The algorithm by which hashCode() is computed isn't specified - so it > shouldn't be an issue changing it - should it? It shouldn't :) But that was why I asked. Even though the exact hashcode is not part of the contract/spec we need to think about what impact it might have just in case we suddenly realize it is a problem somewhere. The main effect of the change would be on how maps store and traverse these objects. Nobody should be relying on such details of course, but there always seems to be someone who does. Anyway I raised the question and it's been explored and I don't see any flashing red lights so no problem. :) Reviewed. Cheers, David > > I must say I don't know how HashMap is serialized - for instance. So > assuming > we have an App1 sending a Map of MBeanInfos to an App2 over the wire, is > that > a problem if in App2 the MBeanInfo hashCodes resolve to different values? > I assume it doesn't... > > I have never considered values of hashCode() to be part of the > standard/API. > Since the algorithm isn't specified, then 2 implementations of the > standard should > be free to use different algorithms - and this shouldn't prevent then to > interoperate. So I hope we're safe in modifying the hashCode algorithm. > > The important part is that it still satisfies the hashCode/equals contract. > > cheers, > > -- daniel > >> >> In javax/management/MBeanInfo.java >> >> Objects.hash(getClassName(), getDescriptor().hashCode()) >> >> should, I think, be >> >> Objects.hash(getClassName(), getDescriptor()) >> David >> ----- >> >>> Indeed, calling Objects.hash(Object ...) is a good idea, which >>> simplifies the code. >>> >>> I used also Arrays.hashCode() to simplify the code, now the fix likes >>> really simple. >>> >>> I have passed JCK tests, unit tests of management are passed too in my >>> desk. >>> >>> toString() worked perfectly in the test, nothing to fix. >>> >>> Shanliang >>> >>> Daniel Fuchs wrote: >>>> On 8/29/13 9:34 AM, shanliang wrote: >>>>> Hi, >>>>> >>>>> Please review following fix, it addresses the issue only in the method >>>>> "hashCode": >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669 >>>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/ >>>>> >>>>> Thanks, >>>>> Shanliang >>>>> >>>> >>>> Hi Shanliang, >>>> >>>> >>>> >>>> >>>> >>>> I suggest to simplify this by calling: >>>> >>>> public int hashCode() { >>>> return Objects.hash(getName(), getType()); >>>> } >>>> >>>> (see >>>> ) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> int hash = getName() == null ? 10 : getName().hashCode(); >>>> >>>> could be replaced by: >>>> >>>> int hash = Objects.hashCode(getName()); >>>> >>>> Generally - and that stands for the other files you modified, you can >>>> simplify things by replacing x.hashCode() with Objects.hashCode(x) >>>> whenever there's the possibility that x can be null. >>>> >>>> Note however that Objects is an API @since JDK 7 - so if you intend >>>> to backport this fix to 6 & 5 you will need to alter your changeset >>>> when backporting it. >>>> >>>> >>>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest >>>> to use Objects.hash(...); >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> BTW: one more question: you're also testing toString() in the test >>>> and that's good - but are there any toString() that will require >>>> fixing? >>>> >>>> >>> > From david.holmes at oracle.com Wed Sep 11 01:30:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Sep 2013 18:30:48 +1000 Subject: jmx-dev Codereview request: 8023529 OpenMBeanInfoSupport.equals/hashCode throw NPE In-Reply-To: <52301CE0.2040407@oracle.com> References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com> <522F2985.80207@oracle.com> <522FAFE0.1050304@oracle.com> <52301CE0.2040407@oracle.com> Message-ID: <52302A38.1020800@oracle.com> On 11/09/2013 5:33 PM, shanliang wrote: > David Holmes wrote: >> I'm a bit confused. The two webrevs are vastly different: >> >> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/ >> >> http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/ >> >> Should they be combined somehow? > The version 01 is correct. > The version 00 was a mistake, yesterday I had some problems to generate > the version 01, so the version 00 was re-generated by mistake with > another fix, sorry for this confusing. Ok functional change seems fine. Looking at the tests a few minor nits: test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java 163 obj1.equals(null); ... 184 obj1.equals(null); I think line 163 can be deleted. In both tests ... Use spaces around the + operator in strings eg: "OK-1: "+obj1.get... The message "with a null object" isn't quite reflective of what is being tested. "null attribute" or even "null field" perhaps? When you catch NPE and report an error it would be good to also print the NPE stacktrace so we can see where we hit the unexpected NPE. The tests are a little verbose ie printing each successful test result, but that might be normal style in this area. David ----- > Thanks, > Shanliang >> >> David >> ----- >> >> On 11/09/2013 12:15 AM, shanliang wrote: >>> Jaroslav Bachorik wrote: >>>> On 09/05/2013 10:37 AM, shanliang wrote: >>>> >>>>> I have added 2 tasts to make sure that call >>>>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE >>>>> The unit tests and JCK tests are passed. >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/ >>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8023529 >>>>> >>>> >>>> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java >>>> >>>> * rename the "obj1", "obj2" parameters to something more explicit - eg. >>>> "referenceInfo" and "nullValueinfo" or something similar >>>> >>> No reference object here, the test has to call both obj1.equals and >>> obj2.equals. >>>> * when testing "obj.equals(null);" the messages should not contain >>>> reference to the parameter since you are not, in fact, testing the null >>>> value of the given parameter but rather a null info object >>>> * the message "got NPE if null paramer" should read "got NPE for null >>>> paramter" >>>> >>> Right, should be "a null object" instead of "a null parameter." >>>> * "Thread.sleep(100);" on line 153 is necessary? >>>> >>> It is not necessary for the test, removed now. >>>> ----- >>>> >>>> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java >>>> >>>> * the message "got NPE if null paramer" should read "got NPE for null >>>> paramter" >>>> * "Thread.sleep(100);" on line 143 is necessary? >>>> >>> Thanks for the review, here is the new version: >>> >>> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/ >>> >>> Shanliang >>>> >>>> -JB- >>>> >>>> >>>>> Thanks, >>>>> >>>>> Shanliang >>>>> >>>> >>>> >>> > From shanliang.jiang at oracle.com Wed Sep 11 05:32:26 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 11 Sep 2013 14:32:26 +0200 Subject: jmx-dev Codereview request: 8023529 OpenMBeanInfoSupport.equals/hashCode throw NPE In-Reply-To: <52302A38.1020800@oracle.com> References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com> <522F2985.80207@oracle.com> <522FAFE0.1050304@oracle.com> <52301CE0.2040407@oracle.com> <52302A38.1020800@oracle.com> Message-ID: <523062DA.20804@oracle.com> David Holmes wrote: > Ok functional change seems fine. > > Looking at the tests a few minor nits: > > test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java > > 163 obj1.equals(null); > ... > 184 obj1.equals(null); > > I think line 163 can be deleted. Yes. > > In both tests ... > > Use spaces around the + operator in strings eg: > > "OK-1: "+obj1.get... > > > The message "with a null object" isn't quite reflective of what is > being tested. "null attribute" or even "null field" perhaps? > > When you catch NPE and report an error it would be good to also print > the NPE stacktrace so we can see where we hit the unexpected NPE. OK. > > The tests are a little verbose ie printing each successful test > result, but that might be normal style in this area. Here we need to test all fields so I print out what we test, so easy to check no missed. I get used to add more info, because sometime we miss info when a test fails. Here is the new version: http://cr.openjdk.java.net/~sjiang/jdk-8023529/02/ Thanks, Shanliang > > David > ----- > >> Thanks, >> Shanliang >>> >>> David >>> ----- >>> >>> On 11/09/2013 12:15 AM, shanliang wrote: >>>> Jaroslav Bachorik wrote: >>>>> On 09/05/2013 10:37 AM, shanliang wrote: >>>>> >>>>>> I have added 2 tasts to make sure that call >>>>>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE >>>>>> The unit tests and JCK tests are passed. >>>>>> >>>>>> Webrev:http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/ >>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8023529 >>>>>> >>>>> >>>>> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java >>>>> >>>>> * rename the "obj1", "obj2" parameters to something more explicit >>>>> - eg. >>>>> "referenceInfo" and "nullValueinfo" or something similar >>>>> >>>> No reference object here, the test has to call both obj1.equals and >>>> obj2.equals. >>>>> * when testing "obj.equals(null);" the messages should not contain >>>>> reference to the parameter since you are not, in fact, testing the >>>>> null >>>>> value of the given parameter but rather a null info object >>>>> * the message "got NPE if null paramer" should read "got NPE for null >>>>> paramter" >>>>> >>>> Right, should be "a null object" instead of "a null parameter." >>>>> * "Thread.sleep(100);" on line 153 is necessary? >>>>> >>>> It is not necessary for the test, removed now. >>>>> ----- >>>>> >>>>> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java >>>>> >>>>> * the message "got NPE if null paramer" should read "got NPE for null >>>>> paramter" >>>>> * "Thread.sleep(100);" on line 143 is necessary? >>>>> >>>> Thanks for the review, here is the new version: >>>> >>>> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/ >>>> >>>> Shanliang >>>>> >>>>> -JB- >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Shanliang >>>>>> >>>>> >>>>> >>>> >> From jaroslav.bachorik at oracle.com Wed Sep 11 07:51:53 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 11 Sep 2013 16:51:53 +0200 Subject: jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java Message-ID: <52308389.6060001@oracle.com> Please, review this simple patch for an intermittently failing test. The test fails in cases when the connection loopback is resolved to be 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The test does not anticipate this possibility and requires the loopback address to be exactly 127.0.0.1 The test will end comparing 127.0.0.1 against 127.0.1.1 and will consider them non equal even though they are both the same loopback. The patch adds a bit of flexibility to the test allowing for any two valid loopback addresses (127.0.0.0/8) to be equal. Issue : JDK-8022220 Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 Thanks, -JB- From shanliang.jiang at oracle.com Wed Sep 11 08:06:10 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 11 Sep 2013 17:06:10 +0200 Subject: jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java In-Reply-To: <52308389.6060001@oracle.com> References: <52308389.6060001@oracle.com> Message-ID: <523086E2.4050307@oracle.com> The fix looks OK for me. I am wondering that in case of loopback address, is it better to always using "127.0.0.1" to generate a connectionId? this will make sure to have a unique id. Shanliang Jaroslav Bachorik wrote: > Please, review this simple patch for an intermittently failing test. > > The test fails in cases when the connection loopback is resolved to be > 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The > test does not anticipate this possibility and requires the loopback > address to be exactly 127.0.0.1 > > The test will end comparing 127.0.0.1 against 127.0.1.1 and will > consider them non equal even though they are both the same loopback. The > patch adds a bit of flexibility to the test allowing for any two valid > loopback addresses (127.0.0.0/8) to be equal. > > Issue : JDK-8022220 > Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 > > Thanks, > > -JB- > From jaroslav.bachorik at oracle.com Wed Sep 11 08:20:59 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 11 Sep 2013 17:20:59 +0200 Subject: jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java In-Reply-To: <523086E2.4050307@oracle.com> References: <52308389.6060001@oracle.com> <523086E2.4050307@oracle.com> Message-ID: <52308A5B.8020206@oracle.com> On 09/11/2013 05:06 PM, shanliang wrote: > The fix looks OK for me. > > I am wondering that in case of loopback address, is it better to always > using "127.0.0.1" to generate a connectionId? this will make sure to > have a unique id. I am afraid we are getting the 127.0.1.1 variant from RMI (java.rmi.server.RemoteServer#getClientHost()). I don't know what else might break if we start fiddling around with it. For now I would better keep it the simplest possible. -JB- > > Shanliang > > Jaroslav Bachorik wrote: >> Please, review this simple patch for an intermittently failing test. >> >> The test fails in cases when the connection loopback is resolved to be >> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The >> test does not anticipate this possibility and requires the loopback >> address to be exactly 127.0.0.1 >> >> The test will end comparing 127.0.0.1 against 127.0.1.1 and will >> consider them non equal even though they are both the same loopback. The >> patch adds a bit of flexibility to the test allowing for any two valid >> loopback addresses (127.0.0.0/8) to be equal. >> >> Issue : JDK-8022220 >> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 >> >> Thanks, >> >> -JB- >> > From jaroslav.bachorik at oracle.com Wed Sep 11 08:39:56 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 11 Sep 2013 17:39:56 +0200 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out Message-ID: <52308ECC.1050304@oracle.com> Please, review the patch for an intermittently failing test. The test is a shell test, using files for the interprocess synchronization. This leads to intermittent failures. In order to fix this the test is rewritten in Java - the original functionality and outputs should be 100% preserved. The patch is unfortunately a bit difficult to follow since there is no similarity between the *.sh and *.java file so one needs to go through the new source in whole. The changes in "launcher" files are all about adding permissions to execute (0755) and as such the webrev shows no differences. Thanks, Issue : JDK-8004926 Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 -JB- From david.holmes at oracle.com Wed Sep 11 17:37:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2013 10:37:53 +1000 Subject: jmx-dev Codereview request: 8023529 OpenMBeanInfoSupport.equals/hashCode throw NPE In-Reply-To: <523062DA.20804@oracle.com> References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com> <522F2985.80207@oracle.com> <522FAFE0.1050304@oracle.com> <52301CE0.2040407@oracle.com> <52302A38.1020800@oracle.com> <523062DA.20804@oracle.com> Message-ID: <52310CE1.4080207@oracle.com> You didn't print the NPE stacktrace in OpenMBeanInfoHashCodeNPETest.java Otherwise ok. No need to rereview if you add the stacktrace printing. Thanks, David On 11/09/2013 10:32 PM, shanliang wrote: > David Holmes wrote: >> Ok functional change seems fine. >> >> Looking at the tests a few minor nits: >> >> test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java >> >> 163 obj1.equals(null); >> ... >> 184 obj1.equals(null); >> >> I think line 163 can be deleted. > Yes. >> >> In both tests ... >> >> Use spaces around the + operator in strings eg: >> >> "OK-1: "+obj1.get... >> >> >> The message "with a null object" isn't quite reflective of what is >> being tested. "null attribute" or even "null field" perhaps? >> >> When you catch NPE and report an error it would be good to also print >> the NPE stacktrace so we can see where we hit the unexpected NPE. > OK. >> >> The tests are a little verbose ie printing each successful test >> result, but that might be normal style in this area. > Here we need to test all fields so I print out what we test, so easy to > check no missed. > I get used to add more info, because sometime we miss info when a test > fails. > > Here is the new version: > http://cr.openjdk.java.net/~sjiang/jdk-8023529/02/ > > Thanks, > Shanliang > >> >> David >> ----- >> >>> Thanks, >>> Shanliang >>>> >>>> David >>>> ----- >>>> >>>> On 11/09/2013 12:15 AM, shanliang wrote: >>>>> Jaroslav Bachorik wrote: >>>>>> On 09/05/2013 10:37 AM, shanliang wrote: >>>>>> >>>>>>> I have added 2 tasts to make sure that call >>>>>>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE >>>>>>> The unit tests and JCK tests are passed. >>>>>>> >>>>>>> Webrev:http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/ >>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8023529 >>>>>>> >>>>>> >>>>>> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java >>>>>> >>>>>> * rename the "obj1", "obj2" parameters to something more explicit >>>>>> - eg. >>>>>> "referenceInfo" and "nullValueinfo" or something similar >>>>>> >>>>> No reference object here, the test has to call both obj1.equals and >>>>> obj2.equals. >>>>>> * when testing "obj.equals(null);" the messages should not contain >>>>>> reference to the parameter since you are not, in fact, testing the >>>>>> null >>>>>> value of the given parameter but rather a null info object >>>>>> * the message "got NPE if null paramer" should read "got NPE for null >>>>>> paramter" >>>>>> >>>>> Right, should be "a null object" instead of "a null parameter." >>>>>> * "Thread.sleep(100);" on line 153 is necessary? >>>>>> >>>>> It is not necessary for the test, removed now. >>>>>> ----- >>>>>> >>>>>> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java >>>>>> >>>>>> * the message "got NPE if null paramer" should read "got NPE for null >>>>>> paramter" >>>>>> * "Thread.sleep(100);" on line 143 is necessary? >>>>>> >>>>> Thanks for the review, here is the new version: >>>>> >>>>> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/ >>>>> >>>>> Shanliang >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Shanliang >>>>>>> >>>>>> >>>>>> >>>>> >>> > From david.holmes at oracle.com Wed Sep 11 20:45:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2013 13:45:15 +1000 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <52308ECC.1050304@oracle.com> References: <52308ECC.1050304@oracle.com> Message-ID: <523138CB.9040401@oracle.com> Hi Jaroslav, You need a copyright notice in the new file. As written this test can only run on a full JDK - so please add it to the :needs_jdk group in TEST.groups. (Does jcmd really needs to come from the test-jdk? And use the VMOPTS passed to the test?) Is there a reason this test can't run on OSX? I know it would need further modification but was wondering if there is something inherent in the test that makes it inapplicable to OSX. I think the test would be a lot simpler if the jdk tests had the hotspot test library's process tools available. :( David ----- On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: > Please, review the patch for an intermittently failing test. > > The test is a shell test, using files for the interprocess > synchronization. This leads to intermittent failures. > > In order to fix this the test is rewritten in Java - the original > functionality and outputs should be 100% preserved. The patch is > unfortunately a bit difficult to follow since there is no similarity > between the *.sh and *.java file so one needs to go through the new > source in whole. > > The changes in "launcher" files are all about adding permissions to > execute (0755) and as such the webrev shows no differences. > > Thanks, > > Issue : JDK-8004926 > Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 > > -JB- > From chris.hegarty at oracle.com Thu Sep 12 01:12:50 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 Sep 2013 09:12:50 +0100 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <523138CB.9040401@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> Message-ID: <52317782.1060300@oracle.com> On 09/12/2013 04:45 AM, David Holmes wrote: > Hi Jaroslav, > > You need a copyright notice in the new file. > > As written this test can only run on a full JDK - so please add it to > the :needs_jdk group in TEST.groups. (Does jcmd really needs to come > from the test-jdk? And use the VMOPTS passed to the test?) > > Is there a reason this test can't run on OSX? I know it would need > further modification but was wondering if there is something inherent in > the test that makes it inapplicable to OSX. > > I think the test would be a lot simpler if the jdk tests had the hotspot > test library's process tools available. :( We have some, is there an obvious gap? http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ -Chris. > > David > ----- > > On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >> Please, review the patch for an intermittently failing test. >> >> The test is a shell test, using files for the interprocess >> synchronization. This leads to intermittent failures. >> >> In order to fix this the test is rewritten in Java - the original >> functionality and outputs should be 100% preserved. The patch is >> unfortunately a bit difficult to follow since there is no similarity >> between the *.sh and *.java file so one needs to go through the new >> source in whole. >> >> The changes in "launcher" files are all about adding permissions to >> execute (0755) and as such the webrev shows no differences. >> >> Thanks, >> >> Issue : JDK-8004926 >> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >> >> -JB- >> From jaroslav.bachorik at oracle.com Thu Sep 12 01:22:32 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 12 Sep 2013 10:22:32 +0200 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <52317782.1060300@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> Message-ID: <523179C8.50606@oracle.com> On 09/12/2013 10:12 AM, Chris Hegarty wrote: > On 09/12/2013 04:45 AM, David Holmes wrote: >> Hi Jaroslav, >> >> You need a copyright notice in the new file. >> >> As written this test can only run on a full JDK - so please add it to >> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come >> from the test-jdk? And use the VMOPTS passed to the test?) >> >> Is there a reason this test can't run on OSX? I know it would need >> further modification but was wondering if there is something inherent in >> the test that makes it inapplicable to OSX. >> >> I think the test would be a lot simpler if the jdk tests had the hotspot >> test library's process tools available. :( > > We have some, is there an obvious gap? > > http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ Hm, thanks for the info. I should have used this library instead. Please, stand by for the updated webrev. -JB- > > > -Chris. > >> >> David >> ----- >> >> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>> Please, review the patch for an intermittently failing test. >>> >>> The test is a shell test, using files for the interprocess >>> synchronization. This leads to intermittent failures. >>> >>> In order to fix this the test is rewritten in Java - the original >>> functionality and outputs should be 100% preserved. The patch is >>> unfortunately a bit difficult to follow since there is no similarity >>> between the *.sh and *.java file so one needs to go through the new >>> source in whole. >>> >>> The changes in "launcher" files are all about adding permissions to >>> execute (0755) and as such the webrev shows no differences. >>> >>> Thanks, >>> >>> Issue : JDK-8004926 >>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>> >>> -JB- >>> From david.holmes at oracle.com Thu Sep 12 03:06:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Sep 2013 20:06:56 +1000 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <52317782.1060300@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> Message-ID: <52319240.9010005@oracle.com> On 12/09/2013 6:12 PM, Chris Hegarty wrote: > On 09/12/2013 04:45 AM, David Holmes wrote: >> Hi Jaroslav, >> >> You need a copyright notice in the new file. >> >> As written this test can only run on a full JDK - so please add it to >> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come >> from the test-jdk? And use the VMOPTS passed to the test?) >> >> Is there a reason this test can't run on OSX? I know it would need >> further modification but was wondering if there is something inherent in >> the test that makes it inapplicable to OSX. >> >> I think the test would be a lot simpler if the jdk tests had the hotspot >> test library's process tools available. :( > > We have some, is there an obvious gap? > > http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ Thanks! I had managed not to find that path. So Jaroslav may be able to use that for launching jcmd and checking process output. David ----- > > -Chris. > >> >> David >> ----- >> >> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>> Please, review the patch for an intermittently failing test. >>> >>> The test is a shell test, using files for the interprocess >>> synchronization. This leads to intermittent failures. >>> >>> In order to fix this the test is rewritten in Java - the original >>> functionality and outputs should be 100% preserved. The patch is >>> unfortunately a bit difficult to follow since there is no similarity >>> between the *.sh and *.java file so one needs to go through the new >>> source in whole. >>> >>> The changes in "launcher" files are all about adding permissions to >>> execute (0755) and as such the webrev shows no differences. >>> >>> Thanks, >>> >>> Issue : JDK-8004926 >>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>> >>> -JB- >>> From jaroslav.bachorik at oracle.com Thu Sep 12 07:17:08 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 12 Sep 2013 16:17:08 +0200 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <523179C8.50606@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> Message-ID: <5231CCE4.7060902@oracle.com> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: > On 09/12/2013 10:12 AM, Chris Hegarty wrote: >> On 09/12/2013 04:45 AM, David Holmes wrote: >>> Hi Jaroslav, >>> >>> You need a copyright notice in the new file. >>> >>> As written this test can only run on a full JDK - so please add it to >>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come >>> from the test-jdk? And use the VMOPTS passed to the test?) >>> >>> Is there a reason this test can't run on OSX? I know it would need >>> further modification but was wondering if there is something inherent in >>> the test that makes it inapplicable to OSX. >>> >>> I think the test would be a lot simpler if the jdk tests had the hotspot >>> test library's process tools available. :( >> >> We have some, is there an obvious gap? >> >> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ > > Hm, thanks for the info. I should have used this library instead. > > Please, stand by for the updated webrev. I was able to get rid off the JCMD. Using the testlibrary the target application can recognize its own PID and print it to its stdout. The main application then just reads the stdout to parse the PID. No need for JCMD any more. I could not find a way to remove the dependency on "test.jdk" system property. According to the jtreg web documentation (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java" system property should be available but in fact is not. But it seems that the testlibrary uses "test.jdk" system property too. The test does not run on OSX because nobody built the launcher binary :) I think it is a kind of DIY so I took the liberty of adding a linux-amd64 launcher while working on the test. While working with the test library I realized I was missing a crucial feature (at least for my purposes) - waiting for a certain message to appear in the stdout/stderr of the launched process. Very often I need to wait for the target process to get to certain point before the test can be allowed to continue - and the point is indicated by a message in stdout/stderr. Currently all the proc tools are designed to work in "batch" mode - the whole stdout/stderr is captured in strings and analyzed after the target process died - and are not suitable for this kind of usage. Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 > > -JB- > >> >> >> -Chris. >> >>> >>> David >>> ----- >>> >>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>> Please, review the patch for an intermittently failing test. >>>> >>>> The test is a shell test, using files for the interprocess >>>> synchronization. This leads to intermittent failures. >>>> >>>> In order to fix this the test is rewritten in Java - the original >>>> functionality and outputs should be 100% preserved. The patch is >>>> unfortunately a bit difficult to follow since there is no similarity >>>> between the *.sh and *.java file so one needs to go through the new >>>> source in whole. >>>> >>>> The changes in "launcher" files are all about adding permissions to >>>> execute (0755) and as such the webrev shows no differences. >>>> >>>> Thanks, >>>> >>>> Issue : JDK-8004926 >>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>> >>>> -JB- >>>> > From dmitry.samersoff at oracle.com Thu Sep 12 08:13:31 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 12 Sep 2013 19:13:31 +0400 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5231CCE4.7060902@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> Message-ID: <5231DA1B.4070706@oracle.com> Jaroslav, CustomLauncherTest.java: 102: this check could be moved to switch at ll. 108 otherwise test fails on "sunos" and "linux" because PLATFORM remains unset. 129: I would prefer don't have pattern like this one ever in shell script. Could you prepare a list of VM's to check and just loop over it? It makes test better readable. Also I think nowdays we can always use server VM. -Dmitry On 2013-09-12 18:17, Jaroslav Bachorik wrote: > On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>> Hi Jaroslav, >>>> >>>> You need a copyright notice in the new file. >>>> >>>> As written this test can only run on a full JDK - so please add it to >>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come >>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>> >>>> Is there a reason this test can't run on OSX? I know it would need >>>> further modification but was wondering if there is something inherent in >>>> the test that makes it inapplicable to OSX. >>>> >>>> I think the test would be a lot simpler if the jdk tests had the hotspot >>>> test library's process tools available. :( >>> >>> We have some, is there an obvious gap? >>> >>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >> >> Hm, thanks for the info. I should have used this library instead. >> >> Please, stand by for the updated webrev. > > I was able to get rid off the JCMD. Using the testlibrary the target > application can recognize its own PID and print it to its stdout. The > main application then just reads the stdout to parse the PID. No need > for JCMD any more. > > I could not find a way to remove the dependency on "test.jdk" system > property. According to the jtreg web documentation > (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java" > system property should be available but in fact is not. But it seems > that the testlibrary uses "test.jdk" system property too. > > The test does not run on OSX because nobody built the launcher binary :) > I think it is a kind of DIY so I took the liberty of adding a > linux-amd64 launcher while working on the test. > > While working with the test library I realized I was missing a crucial > feature (at least for my purposes) - waiting for a certain message to > appear in the stdout/stderr of the launched process. Very often I need > to wait for the target process to get to certain point before the test > can be allowed to continue - and the point is indicated by a message in > stdout/stderr. Currently all the proc tools are designed to work in > "batch" mode - the whole stdout/stderr is captured in strings and > analyzed after the target process died - and are not suitable for this > kind of usage. > > Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 > >> >> -JB- >> >>> >>> >>> -Chris. >>> >>>> >>>> David >>>> ----- >>>> >>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>> Please, review the patch for an intermittently failing test. >>>>> >>>>> The test is a shell test, using files for the interprocess >>>>> synchronization. This leads to intermittent failures. >>>>> >>>>> In order to fix this the test is rewritten in Java - the original >>>>> functionality and outputs should be 100% preserved. The patch is >>>>> unfortunately a bit difficult to follow since there is no similarity >>>>> between the *.sh and *.java file so one needs to go through the new >>>>> source in whole. >>>>> >>>>> The changes in "launcher" files are all about adding permissions to >>>>> execute (0755) and as such the webrev shows no differences. >>>>> >>>>> Thanks, >>>>> >>>>> Issue : JDK-8004926 >>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>> >>>>> -JB- >>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Thu Sep 12 08:31:53 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 12 Sep 2013 17:31:53 +0200 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5231DA1B.4070706@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> Message-ID: <5231DE69.7090309@oracle.com> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: > Jaroslav, > > CustomLauncherTest.java: > > 102: this check could be moved to switch at ll. 108 > otherwise test fails on "sunos" and "linux" because PLATFORM remains unset. Good idea. Thanks. > > 129: I would prefer don't have pattern like this one ever in shell > script. Could you prepare a list of VM's to check and just loop over it? > It makes test better readable. Also I think nowdays we can always use > server VM. I tried to mirror the original shell test as closely as possible. It would be nice if we could rely on the "server" vm only. Definitely more readable. -JB- > > -Dmitry > > > On 2013-09-12 18:17, Jaroslav Bachorik wrote: >> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>> Hi Jaroslav, >>>>> >>>>> You need a copyright notice in the new file. >>>>> >>>>> As written this test can only run on a full JDK - so please add it to >>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come >>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>> >>>>> Is there a reason this test can't run on OSX? I know it would need >>>>> further modification but was wondering if there is something inherent in >>>>> the test that makes it inapplicable to OSX. >>>>> >>>>> I think the test would be a lot simpler if the jdk tests had the hotspot >>>>> test library's process tools available. :( >>>> >>>> We have some, is there an obvious gap? >>>> >>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>> >>> Hm, thanks for the info. I should have used this library instead. >>> >>> Please, stand by for the updated webrev. >> >> I was able to get rid off the JCMD. Using the testlibrary the target >> application can recognize its own PID and print it to its stdout. The >> main application then just reads the stdout to parse the PID. No need >> for JCMD any more. >> >> I could not find a way to remove the dependency on "test.jdk" system >> property. According to the jtreg web documentation >> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java" >> system property should be available but in fact is not. But it seems >> that the testlibrary uses "test.jdk" system property too. >> >> The test does not run on OSX because nobody built the launcher binary :) >> I think it is a kind of DIY so I took the liberty of adding a >> linux-amd64 launcher while working on the test. >> >> While working with the test library I realized I was missing a crucial >> feature (at least for my purposes) - waiting for a certain message to >> appear in the stdout/stderr of the launched process. Very often I need >> to wait for the target process to get to certain point before the test >> can be allowed to continue - and the point is indicated by a message in >> stdout/stderr. Currently all the proc tools are designed to work in >> "batch" mode - the whole stdout/stderr is captured in strings and >> analyzed after the target process died - and are not suitable for this >> kind of usage. >> >> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >> >>> >>> -JB- >>> >>>> >>>> >>>> -Chris. >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>> Please, review the patch for an intermittently failing test. >>>>>> >>>>>> The test is a shell test, using files for the interprocess >>>>>> synchronization. This leads to intermittent failures. >>>>>> >>>>>> In order to fix this the test is rewritten in Java - the original >>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>> unfortunately a bit difficult to follow since there is no similarity >>>>>> between the *.sh and *.java file so one needs to go through the new >>>>>> source in whole. >>>>>> >>>>>> The changes in "launcher" files are all about adding permissions to >>>>>> execute (0755) and as such the webrev shows no differences. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Issue : JDK-8004926 >>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>> >>>>>> -JB- >>>>>> >>> >> > > From dmitry.samersoff at oracle.com Thu Sep 12 08:53:10 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 12 Sep 2013 19:53:10 +0400 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5231DE69.7090309@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> Message-ID: <5231E366.1020206@oracle.com> Jaroslav, I'm not sure that replacing 50 lines shell script with 250 lines Java program we should keep it close to original. ;) -Dmitry On 2013-09-12 19:31, Jaroslav Bachorik wrote: > On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >> Jaroslav, >> >> CustomLauncherTest.java: >> >> 102: this check could be moved to switch at ll. 108 >> otherwise test fails on "sunos" and "linux" because PLATFORM remains unset. > > Good idea. Thanks. > >> >> 129: I would prefer don't have pattern like this one ever in shell >> script. Could you prepare a list of VM's to check and just loop over it? >> It makes test better readable. Also I think nowdays we can always use >> server VM. > > I tried to mirror the original shell test as closely as possible. It > would be nice if we could rely on the "server" vm only. Definitely more > readable. > > -JB- > >> >> -Dmitry >> >> >> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> You need a copyright notice in the new file. >>>>>> >>>>>> As written this test can only run on a full JDK - so please add it to >>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come >>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>> >>>>>> Is there a reason this test can't run on OSX? I know it would need >>>>>> further modification but was wondering if there is something inherent in >>>>>> the test that makes it inapplicable to OSX. >>>>>> >>>>>> I think the test would be a lot simpler if the jdk tests had the hotspot >>>>>> test library's process tools available. :( >>>>> >>>>> We have some, is there an obvious gap? >>>>> >>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>> >>>> Hm, thanks for the info. I should have used this library instead. >>>> >>>> Please, stand by for the updated webrev. >>> >>> I was able to get rid off the JCMD. Using the testlibrary the target >>> application can recognize its own PID and print it to its stdout. The >>> main application then just reads the stdout to parse the PID. No need >>> for JCMD any more. >>> >>> I could not find a way to remove the dependency on "test.jdk" system >>> property. According to the jtreg web documentation >>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java" >>> system property should be available but in fact is not. But it seems >>> that the testlibrary uses "test.jdk" system property too. >>> >>> The test does not run on OSX because nobody built the launcher binary :) >>> I think it is a kind of DIY so I took the liberty of adding a >>> linux-amd64 launcher while working on the test. >>> >>> While working with the test library I realized I was missing a crucial >>> feature (at least for my purposes) - waiting for a certain message to >>> appear in the stdout/stderr of the launched process. Very often I need >>> to wait for the target process to get to certain point before the test >>> can be allowed to continue - and the point is indicated by a message in >>> stdout/stderr. Currently all the proc tools are designed to work in >>> "batch" mode - the whole stdout/stderr is captured in strings and >>> analyzed after the target process died - and are not suitable for this >>> kind of usage. >>> >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>> >>>> >>>> -JB- >>>> >>>>> >>>>> >>>>> -Chris. >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>> Please, review the patch for an intermittently failing test. >>>>>>> >>>>>>> The test is a shell test, using files for the interprocess >>>>>>> synchronization. This leads to intermittent failures. >>>>>>> >>>>>>> In order to fix this the test is rewritten in Java - the original >>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>> unfortunately a bit difficult to follow since there is no similarity >>>>>>> between the *.sh and *.java file so one needs to go through the new >>>>>>> source in whole. >>>>>>> >>>>>>> The changes in "launcher" files are all about adding permissions to >>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Issue : JDK-8004926 >>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>> >>>>>>> -JB- >>>>>>> >>>> >>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Thu Sep 12 09:05:19 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 12 Sep 2013 18:05:19 +0200 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5231E366.1020206@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <5231E366.1020206@oracle.com> Message-ID: <5231E63F.7070903@oracle.com> On 09/12/2013 05:53 PM, Dmitry Samersoff wrote: > Jaroslav, > > I'm not sure that replacing 50 lines shell script with 250 lines Java > program we should keep it close to original. ;) Well, I've deliberately dropped the intermittent failure generator ;) And it's 150 against 250 ... What I meant was that reviewers were often complaining when the old and the new version had nothing in common at all. So, when I saw something like 105 if [ ! -f "${JVMLIB}" ]; then 106 JVMLIB="${TESTJAVA}/jre/lib/${LIBARCH}/server/libjvm.so" 107 if [ ! -f "${JVMLIB}" ]; then 108 JVMLIB="${TESTJAVA}/lib/${LIBARCH}/client/libjvm.so" 109 if [ ! -f "${JVMLIB}" ]; then 110 JVMLIB="${TESTJAVA}/lib/${LIBARCH}/serevr/libjvm.so" 111 if [ ! -f "${JVMLIB}" ]; then 112 echo "Unable to locate libjvm.so in ${TESTJAVA}" 113 exit 1 114 fi 115 fi 116 fi 117 fi I just directly copied it to java. It's nasty but at least one can see where it came from and that it used to work before ... But this is just nitpicking. I completely agree that it can (and should) be made more readable. Always leave the code in the better state than before the fix, I say. -JB- > > -Dmitry > > > On 2013-09-12 19:31, Jaroslav Bachorik wrote: >> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>> Jaroslav, >>> >>> CustomLauncherTest.java: >>> >>> 102: this check could be moved to switch at ll. 108 >>> otherwise test fails on "sunos" and "linux" because PLATFORM remains unset. >> >> Good idea. Thanks. >> >>> >>> 129: I would prefer don't have pattern like this one ever in shell >>> script. Could you prepare a list of VM's to check and just loop over it? >>> It makes test better readable. Also I think nowdays we can always use >>> server VM. >> >> I tried to mirror the original shell test as closely as possible. It >> would be nice if we could rely on the "server" vm only. Definitely more >> readable. >> >> -JB- >> >>> >>> -Dmitry >>> >>> >>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>> Hi Jaroslav, >>>>>>> >>>>>>> You need a copyright notice in the new file. >>>>>>> >>>>>>> As written this test can only run on a full JDK - so please add it to >>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come >>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>> >>>>>>> Is there a reason this test can't run on OSX? I know it would need >>>>>>> further modification but was wondering if there is something inherent in >>>>>>> the test that makes it inapplicable to OSX. >>>>>>> >>>>>>> I think the test would be a lot simpler if the jdk tests had the hotspot >>>>>>> test library's process tools available. :( >>>>>> >>>>>> We have some, is there an obvious gap? >>>>>> >>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>> >>>>> Hm, thanks for the info. I should have used this library instead. >>>>> >>>>> Please, stand by for the updated webrev. >>>> >>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>> application can recognize its own PID and print it to its stdout. The >>>> main application then just reads the stdout to parse the PID. No need >>>> for JCMD any more. >>>> >>>> I could not find a way to remove the dependency on "test.jdk" system >>>> property. According to the jtreg web documentation >>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java" >>>> system property should be available but in fact is not. But it seems >>>> that the testlibrary uses "test.jdk" system property too. >>>> >>>> The test does not run on OSX because nobody built the launcher binary :) >>>> I think it is a kind of DIY so I took the liberty of adding a >>>> linux-amd64 launcher while working on the test. >>>> >>>> While working with the test library I realized I was missing a crucial >>>> feature (at least for my purposes) - waiting for a certain message to >>>> appear in the stdout/stderr of the launched process. Very often I need >>>> to wait for the target process to get to certain point before the test >>>> can be allowed to continue - and the point is indicated by a message in >>>> stdout/stderr. Currently all the proc tools are designed to work in >>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>> analyzed after the target process died - and are not suitable for this >>>> kind of usage. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>> >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>> >>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>> >>>>>>>> In order to fix this the test is rewritten in Java - the original >>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>> unfortunately a bit difficult to follow since there is no similarity >>>>>>>> between the *.sh and *.java file so one needs to go through the new >>>>>>>> source in whole. >>>>>>>> >>>>>>>> The changes in "launcher" files are all about adding permissions to >>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Issue : JDK-8004926 >>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>> >>>> >>> >>> >> > > From shanliang.jiang at oracle.com Mon Sep 16 09:17:12 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 16 Sep 2013 18:17:12 +0200 Subject: jmx-dev Codereview request: 8023954 MBean*Info.equals: throw NPE In-Reply-To: <5229D5CC.3030006@oracle.com> References: <5229BB72.4060502@oracle.com> <5229CE47.7080802@oracle.com> <5229D5CC.3030006@oracle.com> Message-ID: <52372F08.9060901@oracle.com> Hi, Still need OK from a code reviewer, thanks Daniel for the review. Web: http://cr.openjdk.java.net/~sjiang/jdk-8023954/01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8023954 Thanks, Shanliang P.S. The bug id is 8023954, not 8023529, I put the wrong bug ID in the previous mails. Shanliang wrote: > Daniel Fuchs wrote: >> On 9/6/13 1:24 PM, shanliang wrote: >>> Hi, >>> >>> Thanks to review the following fix: >>> >>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8023954 >>> >>> Shanliang >>> >> >> Hi Shanliang, >> >> Looks good - but it looks as if some hashCode() will suffer from the >> same issue (for instance MBeanOperationInfo.hashCode) >> >> Do you have an other defect to track that? > We have another bug JDK-8023669 and thank you for having done the code > review :) I am waiting a reviewer's review for push the fix >> >> I have to wonder why we allow to create an MBeanOperationInfo >> with a null name though... I wished the first implementation >> had thrown NPE at construction time. > I had same wondering, but I had no intention to modify it because that > is related to the specification. > The class OpenMBeanOperation does refuse a null or empty class name. > > Shanliang >> >> -- daniel > From david.holmes at oracle.com Mon Sep 16 22:27:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Sep 2013 15:27:18 +1000 Subject: jmx-dev Codereview request: 8023954 MBean*Info.equals: throw NPE In-Reply-To: <52372F08.9060901@oracle.com> References: <5229BB72.4060502@oracle.com> <5229CE47.7080802@oracle.com> <5229D5CC.3030006@oracle.com> <52372F08.9060901@oracle.com> Message-ID: <5237E836.6000202@oracle.com> On 17/09/2013 2:17 AM, shanliang wrote: > Hi, > > Still need OK from a code reviewer, thanks Daniel for the review. Reviewed. (I'd seen this one earlier by mistake :) ) David > Web: http://cr.openjdk.java.net/~sjiang/jdk-8023954/01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8023954 > > Thanks, > Shanliang > > P.S. > The bug id is 8023954, not 8023529, I put the wrong bug ID in the > previous mails. > > Shanliang wrote: >> Daniel Fuchs wrote: >>> On 9/6/13 1:24 PM, shanliang wrote: >>>> Hi, >>>> >>>> Thanks to review the following fix: >>>> >>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023954 >>>> >>>> Shanliang >>>> >>> >>> Hi Shanliang, >>> >>> Looks good - but it looks as if some hashCode() will suffer from the >>> same issue (for instance MBeanOperationInfo.hashCode) >>> >>> Do you have an other defect to track that? >> We have another bug JDK-8023669 and thank you for having done the code >> review :) I am waiting a reviewer's review for push the fix >>> >>> I have to wonder why we allow to create an MBeanOperationInfo >>> with a null name though... I wished the first implementation >>> had thrown NPE at construction time. >> I had same wondering, but I had no intention to modify it because that >> is related to the specification. >> The class OpenMBeanOperation does refuse a null or empty class name. >> >> Shanliang >>> >>> -- daniel >> > From jaroslav.bachorik at oracle.com Thu Sep 19 07:33:20 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 19 Sep 2013 16:33:20 +0200 Subject: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5231DE69.7090309@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> Message-ID: <523B0B30.4020003@oracle.com> The updated webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 I've moved some of the functionality to the testlibrary. -JB - On 12.9.2013 17:31, Jaroslav Bachorik wrote: > On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >> Jaroslav, >> >> CustomLauncherTest.java: >> >> 102: this check could be moved to switch at ll. 108 >> otherwise test fails on "sunos" and "linux" because PLATFORM remains unset. > Good idea. Thanks. > >> 129: I would prefer don't have pattern like this one ever in shell >> script. Could you prepare a list of VM's to check and just loop over it? >> It makes test better readable. Also I think nowdays we can always use >> server VM. > I tried to mirror the original shell test as closely as possible. It > would be nice if we could rely on the "server" vm only. Definitely more > readable. > > -JB- > >> -Dmitry >> >> >> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> You need a copyright notice in the new file. >>>>>> >>>>>> As written this test can only run on a full JDK - so please add it to >>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come >>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>> >>>>>> Is there a reason this test can't run on OSX? I know it would need >>>>>> further modification but was wondering if there is something inherent in >>>>>> the test that makes it inapplicable to OSX. >>>>>> >>>>>> I think the test would be a lot simpler if the jdk tests had the hotspot >>>>>> test library's process tools available. :( >>>>> We have some, is there an obvious gap? >>>>> >>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>> Hm, thanks for the info. I should have used this library instead. >>>> >>>> Please, stand by for the updated webrev. >>> I was able to get rid off the JCMD. Using the testlibrary the target >>> application can recognize its own PID and print it to its stdout. The >>> main application then just reads the stdout to parse the PID. No need >>> for JCMD any more. >>> >>> I could not find a way to remove the dependency on "test.jdk" system >>> property. According to the jtreg web documentation >>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java" >>> system property should be available but in fact is not. But it seems >>> that the testlibrary uses "test.jdk" system property too. >>> >>> The test does not run on OSX because nobody built the launcher binary :) >>> I think it is a kind of DIY so I took the liberty of adding a >>> linux-amd64 launcher while working on the test. >>> >>> While working with the test library I realized I was missing a crucial >>> feature (at least for my purposes) - waiting for a certain message to >>> appear in the stdout/stderr of the launched process. Very often I need >>> to wait for the target process to get to certain point before the test >>> can be allowed to continue - and the point is indicated by a message in >>> stdout/stderr. Currently all the proc tools are designed to work in >>> "batch" mode - the whole stdout/stderr is captured in strings and >>> analyzed after the target process died - and are not suitable for this >>> kind of usage. >>> >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>> >>>> -JB- >>>> >>>>> >>>>> -Chris. >>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>> Please, review the patch for an intermittently failing test. >>>>>>> >>>>>>> The test is a shell test, using files for the interprocess >>>>>>> synchronization. This leads to intermittent failures. >>>>>>> >>>>>>> In order to fix this the test is rewritten in Java - the original >>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>> unfortunately a bit difficult to follow since there is no similarity >>>>>>> between the *.sh and *.java file so one needs to go through the new >>>>>>> source in whole. >>>>>>> >>>>>>> The changes in "launcher" files are all about adding permissions to >>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Issue : JDK-8004926 >>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>> >>>>>>> -JB- >>>>>>> >> From jaroslav.bachorik at oracle.com Fri Sep 20 05:28:59 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 20 Sep 2013 14:28:59 +0200 Subject: jmx-dev RFR: 8024613 javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently Message-ID: <523C3F8B.6080002@oracle.com> Please, review the following change for JDK-8024613 Issue: https://bugs.openjdk.java.net/browse/JDK-8024613 Webrev: http://cr.openjdk.java.net/~jbachorik/8024613/webrev.00/ The patch takes care of intermittent test failures caused by timing issues when starting the RMID process. It could happen that the RMID process hasn't been properly initialized in the timeframe of 5 seconds and the test would fail. The patch replaces the home-brewed RMID process management with the one available in the RMI Testlibrary which is used by more tests and therefore should be more stable. Thanks, -JB- From shanliang.jiang at oracle.com Fri Sep 20 05:54:50 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 20 Sep 2013 14:54:50 +0200 Subject: jmx-dev RFR: 8024613 javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently In-Reply-To: <523C3F8B.6080002@oracle.com> References: <523C3F8B.6080002@oracle.com> Message-ID: <523C459A.3080303@oracle.com> Jaroslav, It is a good idea to use the RMI Testlibrary. Better to call: agent.close(); at Line 55, close the RMIRegistry (rmid.shutdown(rmidPort) Line 55) does not ensure the JMX connector doing full clean, it is always better to do clean within a test. Shanliang Jaroslav Bachorik wrote: > Please, review the following change for JDK-8024613 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8024613 > Webrev: http://cr.openjdk.java.net/~jbachorik/8024613/webrev.00/ > > > The patch takes care of intermittent test failures caused by timing > issues when starting the RMID process. It could happen that the RMID > process hasn't been properly initialized in the timeframe of 5 seconds > and the test would fail. > > The patch replaces the home-brewed RMID process management with the > one available in the RMI Testlibrary which is used by more tests and > therefore should be more stable. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Sep 23 02:40:36 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 23 Sep 2013 11:40:36 +0200 Subject: jmx-dev [ping] Re: RFR: 8002307 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal representation by storing an externally mutable object In-Reply-To: <51E7DB79.2010504@oracle.com> References: <51A4AB45.4070100@oracle.com> <51A4DC90.7050809@oracle.com> <51E7BB6C.6030704@oracle.com> <51E7DB79.2010504@oracle.com> Message-ID: <52400C94.3020803@oracle.com> May I have a reviewer take a look at this, please? -JB- On 18.7.2013 14:11, Daniel Fuchs wrote: > Hi Jaroslav, > > Looks good overall. > > Small nit: > > You should remove the comment lines 322-327 > in ModelMBeanInfoSupport.java since your changes make it obsolete. > > Also the copyright year in ImmutableDataTest should be 2013 (not 2005). > > No need for another round of review. > > -- daniel > > On 7/18/13 11:54 AM, Jaroslav Bachorik wrote: >> Hi, >> >> thanks for the comments. >> >> Here (http://cr.openjdk.java.net/~jbachorik/8002307/webrev.03/) is the >> updated webrev implementing suggestions from Daniel and Shanliang. >> >> -JB- >> >> > From shanliang.jiang at oracle.com Mon Sep 23 04:53:08 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 23 Sep 2013 13:53:08 +0200 Subject: jmx-dev Codereview request: 8025204 Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java Message-ID: <52402BA4.1050708@oracle.com> Hi, The JMX server implementation has not been changed since long time, the test failure must be a waiting time issue, let's have a long timeout, we will need investigation on the server if the test continues failing. webrev: http://cr.openjdk.java.net/~sjiang/8025204jdk/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8025204 Thanks, shanliang From jaroslav.bachorik at oracle.com Mon Sep 23 05:51:18 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 23 Sep 2013 14:51:18 +0200 Subject: jmx-dev Codereview request: 8025204 Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java In-Reply-To: <52402BA4.1050708@oracle.com> References: <52402BA4.1050708@oracle.com> Message-ID: <52403946.20806@oracle.com> Looks good. I wonder what might be happening to cause such slowdowns of test machines from time to time though ... -JB- On 23.9.2013 13:53, shanliang wrote: > Hi, > > The JMX server implementation has not been changed since long time, > the test failure must be a waiting time issue, let's have a long > timeout, we will need investigation on the server if the test > continues failing. > > webrev: http://cr.openjdk.java.net/~sjiang/8025204jdk/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8025204 > > Thanks, > shanliang From shanliang.jiang at oracle.com Mon Sep 23 11:27:42 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 23 Sep 2013 20:27:42 +0200 Subject: jmx-dev Codereview request: 8025207 Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java In-Reply-To: <52402BA4.1050708@oracle.com> References: <52402BA4.1050708@oracle.com> Message-ID: <5240881E.4060204@oracle.com> Hi, Please review this test fix, if the test continues failing, then we need to investigate the Monitor implementation. webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8025207 Thanks, Shanliang From daniel.fuchs at oracle.com Tue Sep 24 02:31:15 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 24 Sep 2013 11:31:15 +0200 Subject: jmx-dev Codereview request: 8025207 Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java In-Reply-To: <5240881E.4060204@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> Message-ID: <52415BE3.1030803@oracle.com> On 9/23/13 8:27 PM, shanliang wrote: > Hi, > > Please review this test fix, if the test continues failing, then we need > to investigate the Monitor implementation. > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8025207 > > Thanks, > Shanliang > Hi Shanliang, There seems to an issue in the exit condition of the loop in the new code. The old code had: 150 if (derivedGaugeValue.intValue() != derivedGauge[i]) the new code has: 155 } while (derivedGaugeValue.intValue() != counter[i]); Also I'm not sure it's good idea to make a println every 100ms... -- daniel From shanliang.jiang at oracle.com Tue Sep 24 04:22:07 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 24 Sep 2013 13:22:07 +0200 Subject: jmx-dev Codereview request: 8025207 Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java In-Reply-To: <52415BE3.1030803@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> Message-ID: <524175DF.1060906@oracle.com> Daniel Fuchs wrote: > On 9/23/13 8:27 PM, shanliang wrote: >> Hi, >> >> Please review this test fix, if the test continues failing, then we need >> to investigate the Monitor implementation. >> >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8025207 >> >> Thanks, >> Shanliang >> > > Hi Shanliang, > > There seems to an issue in the exit condition of the loop in the > new code. > > The old code had: > > 150 if (derivedGaugeValue.intValue() != derivedGauge[i]) > > the new code has: > > 155 } while (derivedGaugeValue.intValue() != counter[i]); Good catch, I changed the code, even they are same today: Here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8025207/01/ > > > Also I'm not sure it's good idea to make a println every 100ms... OK, removed, in some case is useful, but ... Thanks, Shanliang > > -- daniel From shanliang.jiang at oracle.com Wed Sep 25 23:35:58 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 26 Sep 2013 08:35:58 +0200 Subject: jmx-dev Codereview request: 8025205 Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java In-Reply-To: <5240881E.4060204@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> Message-ID: <5243D5CE.3090100@oracle.com> Hi, Simply wait longer time for a broken notif. webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025205/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8025205 Thanks, Shanliang From jaroslav.bachorik at oracle.com Thu Sep 26 01:44:22 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 26 Sep 2013 10:44:22 +0200 Subject: jmx-dev Codereview request: 8025205 Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java In-Reply-To: <5243D5CE.3090100@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <5243D5CE.3090100@oracle.com> Message-ID: <5243F3E6.2010008@oracle.com> Looks good. -JB- On 26.9.2013 08:35, shanliang wrote: > Hi, > > Simply wait longer time for a broken notif. > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025205/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8025205 > > Thanks, > Shanliang From daniel.fuchs at oracle.com Thu Sep 26 02:58:50 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 26 Sep 2013 11:58:50 +0200 Subject: jmx-dev Codereview request: 8025205 Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java In-Reply-To: <5243D5CE.3090100@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <5243D5CE.3090100@oracle.com> Message-ID: <5244055A.7020807@oracle.com> On 9/26/13 8:35 AM, shanliang wrote: > Hi, > > Simply wait longer time for a broken notif. > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025205/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8025205 > > Thanks, > Shanliang Hi Shanliang, Looks good. -- daniel From jaroslav.bachorik at oracle.com Thu Sep 26 14:24:44 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 26 Sep 2013 23:24:44 +0200 Subject: jmx-dev RFR: 8002307 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal representation by storing an externally mutable object In-Reply-To: <5226DE33.9000801@oracle.com> References: <51A4AB45.4070100@oracle.com> <51A4DC90.7050809@oracle.com> <51E7BB6C.6030704@oracle.com> <5226DE33.9000801@oracle.com> Message-ID: <5244A61C.2030102@oracle.com> I've updated the webrev to utilize "readResolve" method to clone the deserialized instance before returning it - as recommended by Eamonn. This way it is possible to keep all the fields final while imposing imutability during the deserialization. The update webrev is at http://cr.openjdk.java.net/~jbachorik/8002307/webrev.04 -JB- On 4.9.2013 09:16, Jaroslav Bachorik wrote: > [ping] > > Thanks for the reviews. I still need a reviewer to take a look at this. > This issue blocks a P2 targeted for JDK8 (JDK-7148504). > > Thanks, > > -JB- > > On 07/18/2013 11:54 AM, Jaroslav Bachorik wrote: >> Hi, >> >> thanks for the comments. >> >> Here (http://cr.openjdk.java.net/~jbachorik/8002307/webrev.03/) is the >> updated webrev implementing suggestions from Daniel and Shanliang. >> >> -JB- >> >> > From eamonn at mcmanus.net Thu Sep 26 14:38:22 2013 From: eamonn at mcmanus.net (Eamonn McManus) Date: Thu, 26 Sep 2013 14:38:22 -0700 Subject: jmx-dev RFR: 8002307 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal representation by storing an externally mutable object In-Reply-To: <5244A61C.2030102@oracle.com> References: <51A4AB45.4070100@oracle.com> <51A4DC90.7050809@oracle.com> <51E7BB6C.6030704@oracle.com> <5226DE33.9000801@oracle.com> <5244A61C.2030102@oracle.com> Message-ID: Reviewed-by: emcmanus The order of the parameters in checkMutableReference and checkReturnMutables is surprising, but otherwise this looks good. ?amonn 2013/9/26 Jaroslav Bachorik > I've updated the webrev to utilize "readResolve" method to clone the > deserialized instance before returning it - as recommended by Eamonn. This > way it is possible to keep all the fields final while imposing imutability > during the deserialization. > > The update webrev is at http://cr.openjdk.java.net/~** > jbachorik/8002307/webrev.04 > > -JB- > > > On 4.9.2013 09:16, Jaroslav Bachorik wrote: > >> [ping] >> >> Thanks for the reviews. I still need a reviewer to take a look at this. >> This issue blocks a P2 targeted for JDK8 (JDK-7148504). >> >> Thanks, >> >> -JB- >> >> On 07/18/2013 11:54 AM, Jaroslav Bachorik wrote: >> >>> Hi, >>> >>> thanks for the comments. >>> >>> Here (http://cr.openjdk.java.net/~**jbachorik/8002307/webrev.03/) >>> is the >>> updated webrev implementing suggestions from Daniel and Shanliang. >>> >>> -JB- >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20130926/b4c1b77e/attachment.html From shanliang.jiang at oracle.com Sun Sep 29 23:55:46 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 30 Sep 2013 08:55:46 +0200 Subject: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java In-Reply-To: <524175DF.1060906@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> <524175DF.1060906@oracle.com> Message-ID: <52492072.60201@oracle.com> Hi, Please review this test fix, I set a much long waiting time to receive a notification, but not simply wait the test timeout, in order to have less modification. webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025206/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8025206 Thanks, Shanliang From jaroslav.bachorik at oracle.com Mon Sep 30 00:27:14 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 30 Sep 2013 09:27:14 +0200 Subject: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java In-Reply-To: <52492072.60201@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> <524175DF.1060906@oracle.com> <52492072.60201@oracle.com> Message-ID: <524927D2.6000900@oracle.com> Hi Shanliang, On 30.9.2013 08:55, shanliang wrote: > Hi, > > Please review this test fix, I set a much long waiting time to receive a > notification, but not simply wait the test timeout, in order to have > less modification. IMO, the change to let the harness terminate the test on timeout was quite readable as well. But you leave more than sufficient buffer for any delays in delivering notifications so I suppose it should be fine. You are missing the debugging echos in places where you extracted the checkReceived() method. And just a small nit - on line 31 you should probably add the @author tag. Cheers, -JB- > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025206/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8025206 > > Thanks, > Shanliang From shanliang.jiang at oracle.com Mon Sep 30 00:46:22 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 30 Sep 2013 09:46:22 +0200 Subject: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java In-Reply-To: <524927D2.6000900@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> <524175DF.1060906@oracle.com> <52492072.60201@oracle.com> <524927D2.6000900@oracle.com> Message-ID: <52492C4E.5090100@oracle.com> Thanks Jaroslav for the review, here is the new version with the debugging info: http://cr.openjdk.java.net/~sjiang/JDK-8025206/01/ Shanliang Jaroslav Bachorik wrote: > Hi Shanliang, > > On 30.9.2013 08:55, shanliang wrote: >> Hi, >> >> Please review this test fix, I set a much long waiting time to receive a >> notification, but not simply wait the test timeout, in order to have >> less modification. > > IMO, the change to let the harness terminate the test on timeout was > quite readable as well. But you leave more than sufficient buffer for > any delays in delivering notifications so I suppose it should be fine. > > You are missing the debugging echos in places where you extracted the > checkReceived() method. > > And just a small nit - on line 31 you should probably add the @author > tag. > > Cheers, > > -JB- > >> >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025206/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8025206 >> >> Thanks, >> Shanliang > From jaroslav.bachorik at oracle.com Mon Sep 30 00:56:02 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 30 Sep 2013 09:56:02 +0200 Subject: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java In-Reply-To: <52492C4E.5090100@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> <524175DF.1060906@oracle.com> <52492072.60201@oracle.com> <524927D2.6000900@oracle.com> <52492C4E.5090100@oracle.com> Message-ID: <52492E92.7090003@oracle.com> Hi, On 30.9.2013 09:46, shanliang wrote: > Thanks Jaroslav for the review, here is the new version with the > debugging info: > http://cr.openjdk.java.net/~sjiang/JDK-8025206/01/ I'm fine with the changes. -JB- > > Shanliang > > Jaroslav Bachorik wrote: >> Hi Shanliang, >> >> On 30.9.2013 08:55, shanliang wrote: >>> Hi, >>> >>> Please review this test fix, I set a much long waiting time to receive a >>> notification, but not simply wait the test timeout, in order to have >>> less modification. >> >> IMO, the change to let the harness terminate the test on timeout was >> quite readable as well. But you leave more than sufficient buffer for >> any delays in delivering notifications so I suppose it should be fine. >> >> You are missing the debugging echos in places where you extracted the >> checkReceived() method. >> >> And just a small nit - on line 31 you should probably add the @author >> tag. >> >> Cheers, >> >> -JB- >> >>> >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025206/00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8025206 >>> >>> Thanks, >>> Shanliang >> > From daniel.fuchs at oracle.com Mon Sep 30 01:25:54 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 30 Sep 2013 10:25:54 +0200 Subject: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java In-Reply-To: <52492072.60201@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> <524175DF.1060906@oracle.com> <52492072.60201@oracle.com> Message-ID: <52493592.1030504@oracle.com> Hi Shanliang, Shouldn't 'messageReceived' be at least declared as volatile? It looks as if this test is a multi-thread test which is not MT-safe. cheers, -- daniel On 9/30/13 8:55 AM, shanliang wrote: > Hi, > > Please review this test fix, I set a much long waiting time to receive a > notification, but not simply wait the test timeout, in order to have > less modification. > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025206/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8025206 > > Thanks, > Shanliang From shanliang.jiang at oracle.com Mon Sep 30 01:33:17 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 30 Sep 2013 10:33:17 +0200 Subject: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java In-Reply-To: <52493592.1030504@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> <524175DF.1060906@oracle.com> <52492072.60201@oracle.com> <52493592.1030504@oracle.com> Message-ID: <5249374D.2070608@oracle.com> Daniel Fuchs wrote: > Hi Shanliang, > > Shouldn't 'messageReceived' be at least declared as volatile? > It looks as if this test is a multi-thread test which > is not MT-safe. Could be better, but the test is patient enough with its timeout :) Shanliang > > cheers, > > -- daniel > > On 9/30/13 8:55 AM, shanliang wrote: >> Hi, >> >> Please review this test fix, I set a much long waiting time to receive a >> notification, but not simply wait the test timeout, in order to have >> less modification. >> >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025206/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8025206 >> >> Thanks, >> Shanliang > From shanliang.jiang at oracle.com Mon Sep 30 02:47:26 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 30 Sep 2013 11:47:26 +0200 Subject: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java In-Reply-To: <52493592.1030504@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> <524175DF.1060906@oracle.com> <52492072.60201@oracle.com> <52493592.1030504@oracle.com> Message-ID: <524948AE.6030003@oracle.com> Daniel Fuchs wrote: > Hi Shanliang, > > Shouldn't 'messageReceived' be at least declared as volatile? > It looks as if this test is a multi-thread test which > is not MT-safe. OK I am convinced: http://cr.openjdk.java.net/~sjiang/JDK-8025206/02/ Thanks, Shanliang > > cheers, > > -- daniel > > On 9/30/13 8:55 AM, shanliang wrote: >> Hi, >> >> Please review this test fix, I set a much long waiting time to receive a >> notification, but not simply wait the test timeout, in order to have >> less modification. >> >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025206/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8025206 >> >> Thanks, >> Shanliang > From daniel.fuchs at oracle.com Mon Sep 30 03:09:10 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 30 Sep 2013 12:09:10 +0200 Subject: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java In-Reply-To: <524948AE.6030003@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> <524175DF.1060906@oracle.com> <52492072.60201@oracle.com> <52493592.1030504@oracle.com> <524948AE.6030003@oracle.com> Message-ID: <52494DC6.7030908@oracle.com> Looks good! -- daniel On 9/30/13 11:47 AM, shanliang wrote: > Daniel Fuchs wrote: >> Hi Shanliang, >> >> Shouldn't 'messageReceived' be at least declared as volatile? >> It looks as if this test is a multi-thread test which >> is not MT-safe. > OK I am convinced: > http://cr.openjdk.java.net/~sjiang/JDK-8025206/02/ > > Thanks, > Shanliang > >> >> cheers, >> >> -- daniel >> >> On 9/30/13 8:55 AM, shanliang wrote: >>> Hi, >>> >>> Please review this test fix, I set a much long waiting time to receive a >>> notification, but not simply wait the test timeout, in order to have >>> less modification. >>> >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025206/00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8025206 >>> >>> Thanks, >>> Shanliang >> > From daniel.fuchs at oracle.com Mon Sep 30 06:05:59 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 30 Sep 2013 15:05:59 +0200 Subject: jmx-dev Codereview request: 8025207 Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java In-Reply-To: <524175DF.1060906@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> <524175DF.1060906@oracle.com> Message-ID: <52497737.2010402@oracle.com> The new version looks good to me. Thanks Shanliang! -- daniel On 9/24/13 1:22 PM, shanliang wrote: > Daniel Fuchs wrote: >> On 9/23/13 8:27 PM, shanliang wrote: >>> Hi, >>> >>> Please review this test fix, if the test continues failing, then we need >>> to investigate the Monitor implementation. >>> >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8025207 >>> >>> Thanks, >>> Shanliang >>> >> >> Hi Shanliang, >> >> There seems to an issue in the exit condition of the loop in the >> new code. >> >> The old code had: >> >> 150 if (derivedGaugeValue.intValue() != derivedGauge[i]) >> >> the new code has: >> >> 155 } while (derivedGaugeValue.intValue() != counter[i]); > Good catch, I changed the code, even they are same today: > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8025207/01/ >> >> >> Also I'm not sure it's good idea to make a println every 100ms... > OK, removed, in some case is useful, but ... > > Thanks, > Shanliang >> >> -- daniel > From jaroslav.bachorik at oracle.com Mon Sep 30 06:08:26 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 30 Sep 2013 15:08:26 +0200 Subject: jmx-dev Codereview request: 8025207 Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java In-Reply-To: <52497737.2010402@oracle.com> References: <52402BA4.1050708@oracle.com> <5240881E.4060204@oracle.com> <52415BE3.1030803@oracle.com> <524175DF.1060906@oracle.com> <52497737.2010402@oracle.com> Message-ID: <524977CA.8010400@oracle.com> +1 -JB- On 30.9.2013 15:05, Daniel Fuchs wrote: > The new version looks good to me. > > Thanks Shanliang! > > -- daniel > > On 9/24/13 1:22 PM, shanliang wrote: >> Daniel Fuchs wrote: >>> On 9/23/13 8:27 PM, shanliang wrote: >>>> Hi, >>>> >>>> Please review this test fix, if the test continues failing, then we >>>> need >>>> to investigate the Monitor implementation. >>>> >>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025207 >>>> >>>> Thanks, >>>> Shanliang >>>> >>> >>> Hi Shanliang, >>> >>> There seems to an issue in the exit condition of the loop in the >>> new code. >>> >>> The old code had: >>> >>> 150 if (derivedGaugeValue.intValue() != derivedGauge[i]) >>> >>> the new code has: >>> >>> 155 } while (derivedGaugeValue.intValue() != counter[i]); >> Good catch, I changed the code, even they are same today: >> Here is the new version: >> http://cr.openjdk.java.net/~sjiang/JDK-8025207/01/ >>> >>> >>> Also I'm not sure it's good idea to make a println every 100ms... >> OK, removed, in some case is useful, but ... >> >> Thanks, >> Shanliang >>> >>> -- daniel >> >