From shanliang.jiang at oracle.com Mon Dec 3 10:09:44 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 03 Dec 2012 19:09:44 +0100 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently Message-ID: <50BCEAE8.9000807@oracle.com> Hi, The test failed because 2 problems happened on a slow machine: 1) the function _get_pid() did not get right pid because the pid was showed too late or 2) the file JMXStartStop.lck was showed too late too The fix is to add a waiting (max 20 seconds) in the function _app_start() to make sure that the pid and JMXStartStop.lck are both well created. This waiting is not entered in a normal and not too charged machine. I modified too the class JMXStartStopDoSomething, it will wake up every 500ms to check running timeout, instead of 1ms, 1ms is not reasonable short. I tested 1) by not running JMXStartStopDoSomething in the function _app_start() I tested 2) by add one second sleep before creating JMXStartStop.lck file in the class JMXStartStopDoSomething. best regards, Shanliang From shanliang.jiang at oracle.com Mon Dec 3 11:34:02 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 03 Dec 2012 20:34:02 +0100 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently In-Reply-To: <50BCEAE8.9000807@oracle.com> References: <50BCEAE8.9000807@oracle.com> Message-ID: <50BCFEAA.7000805@oracle.com> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.00/ shanliang wrote: > Hi, > > The test failed because 2 problems happened on a slow machine: > > 1) the function _get_pid() did not get right pid because the pid was > showed too late > or > 2) the file JMXStartStop.lck was showed too late too > > The fix is to add a waiting (max 20 seconds) in the function > _app_start() to make sure that the pid and JMXStartStop.lck are both > well created. This waiting is not entered in a normal and not too > charged machine. > > I modified too the class JMXStartStopDoSomething, it will wake up > every 500ms to check running timeout, instead of 1ms, 1ms is not > reasonable short. > > I tested 1) by not running JMXStartStopDoSomething in the function > _app_start() > I tested 2) by add one second sleep before creating JMXStartStop.lck > file in the class JMXStartStopDoSomething. > > best regards, > > Shanliang From Alan.Bateman at oracle.com Mon Dec 3 12:00:26 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Dec 2012 20:00:26 +0000 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently In-Reply-To: <50BCFEAA.7000805@oracle.com> References: <50BCEAE8.9000807@oracle.com> <50BCFEAA.7000805@oracle.com> Message-ID: <50BD04DA.8030100@oracle.com> On 03/12/2012 19:34, shanliang wrote: > Webrev: > http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.00/ I haven't reviewed the changes but just an FYI that this test is excluded (see jdk/test/ProblemList.txt) so you need to remove it from the file to re-enable it on all platforms. -Alan From dmitry.samersoff at oracle.com Mon Dec 3 12:05:40 2012 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 04 Dec 2012 00:05:40 +0400 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently In-Reply-To: <50BCFEAA.7000805@oracle.com> References: <50BCEAE8.9000807@oracle.com> <50BCFEAA.7000805@oracle.com> Message-ID: <50BD0614.2040402@oracle.com> Shanliang, Changes looks good for me. Did you test shell changes under Solaris - if my memory is not bogus, solaris /bin/sh doesn't support ((x++))? -Dmitry On 2012-12-03 23:34, shanliang wrote: > Webrev: > http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.00/ > > shanliang wrote: >> Hi, >> >> The test failed because 2 problems happened on a slow machine: >> >> 1) the function _get_pid() did not get right pid because the pid was >> showed too late >> or >> 2) the file JMXStartStop.lck was showed too late too >> >> The fix is to add a waiting (max 20 seconds) in the function >> _app_start() to make sure that the pid and JMXStartStop.lck are both >> well created. This waiting is not entered in a normal and not too >> charged machine. >> >> I modified too the class JMXStartStopDoSomething, it will wake up >> every 500ms to check running timeout, instead of 1ms, 1ms is not >> reasonable short. >> >> I tested 1) by not running JMXStartStopDoSomething in the function >> _app_start() >> I tested 2) by add one second sleep before creating JMXStartStop.lck >> file in the class JMXStartStopDoSomething. >> >> best regards, >> >> Shanliang > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Mon Dec 3 12:36:10 2012 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 04 Dec 2012 00:36:10 +0400 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently In-Reply-To: <50BD04DA.8030100@oracle.com> References: <50BCEAE8.9000807@oracle.com> <50BCFEAA.7000805@oracle.com> <50BD04DA.8030100@oracle.com> Message-ID: <50BD0D3A.7080203@oracle.com> Alan, I would recommend don't do it unless JTREG supports client-server tests natively. -Dmitry On 2012-12-04 00:00, Alan Bateman wrote: > On 03/12/2012 19:34, shanliang wrote: >> Webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.00/ > I haven't reviewed the changes but just an FYI that this test is > excluded (see jdk/test/ProblemList.txt) so you need to remove it from > the file to re-enable it on all platforms. > > -Alan -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From Alan.Bateman at oracle.com Mon Dec 3 13:48:26 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Dec 2012 21:48:26 +0000 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently In-Reply-To: <50BD0D3A.7080203@oracle.com> References: <50BCEAE8.9000807@oracle.com> <50BCFEAA.7000805@oracle.com> <50BD04DA.8030100@oracle.com> <50BD0D3A.7080203@oracle.com> Message-ID: <50BD1E2A.4080202@oracle.com> On 03/12/2012 20:36, Dmitry Samersoff wrote: > Alan, > > I would recommend don't do it unless JTREG supports client-server tests > natively. > > -Dmitry > I don't understand your mail. Are you recommending that we keep it excluded so that it is never run? I don't think jtreg is the issue, it's just a simple way to launch tests. -Alan From shanliang.jiang at oracle.com Tue Dec 4 04:54:10 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 04 Dec 2012 13:54:10 +0100 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently In-Reply-To: <50BD0614.2040402@oracle.com> References: <50BCEAE8.9000807@oracle.com> <50BCFEAA.7000805@oracle.com> <50BD0614.2040402@oracle.com> Message-ID: <50BDF272.9030505@oracle.com> Hi, Here is the new webrev: http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.01/ 1) I changed ((x++) to x=`expr $x + 1` 2) I simplified the test in _app_start(), in fact we need only to check the lock file. Thank, Shanliang Dmitry Samersoff wrote: > Shanliang, > > Changes looks good for me. > > Did you test shell changes under Solaris - if my memory is not bogus, > solaris /bin/sh doesn't support ((x++))? > > -Dmitry > > > On 2012-12-03 23:34, shanliang wrote: > >> Webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.00/ >> >> shanliang wrote: >> >>> Hi, >>> >>> The test failed because 2 problems happened on a slow machine: >>> >>> 1) the function _get_pid() did not get right pid because the pid was >>> showed too late >>> or >>> 2) the file JMXStartStop.lck was showed too late too >>> >>> The fix is to add a waiting (max 20 seconds) in the function >>> _app_start() to make sure that the pid and JMXStartStop.lck are both >>> well created. This waiting is not entered in a normal and not too >>> charged machine. >>> >>> I modified too the class JMXStartStopDoSomething, it will wake up >>> every 500ms to check running timeout, instead of 1ms, 1ms is not >>> reasonable short. >>> >>> I tested 1) by not running JMXStartStopDoSomething in the function >>> _app_start() >>> I tested 2) by add one second sleep before creating JMXStartStop.lck >>> file in the class JMXStartStopDoSomething. >>> >>> best regards, >>> >>> Shanliang >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20121204/9983e8ed/attachment.html From dmitry.samersoff at oracle.com Tue Dec 4 06:11:11 2012 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 04 Dec 2012 18:11:11 +0400 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently In-Reply-To: <50BDF272.9030505@oracle.com> References: <50BCEAE8.9000807@oracle.com> <50BCFEAA.7000805@oracle.com> <50BD0614.2040402@oracle.com> <50BDF272.9030505@oracle.com> Message-ID: <50BE047F.2040607@oracle.com> Looks good for me! -Dmitry On 2012-12-04 16:54, shanliang wrote: > Hi, > > Here is the new webrev: > http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.01/ > > 1) I changed > ((x++) > to > x=`expr $x + 1` > > 2) I simplified the test in _app_start(), in fact we need only to check > the lock file. > > Thank, > > Shanliang > > Dmitry Samersoff wrote: >> Shanliang, >> >> Changes looks good for me. >> >> Did you test shell changes under Solaris - if my memory is not bogus, >> solaris /bin/sh doesn't support ((x++))? >> >> -Dmitry >> >> >> On 2012-12-03 23:34, shanliang wrote: >> >>> Webrev: >>> http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.00/ >>> >>> shanliang wrote: >>> >>>> Hi, >>>> >>>> The test failed because 2 problems happened on a slow machine: >>>> >>>> 1) the function _get_pid() did not get right pid because the pid was >>>> showed too late >>>> or >>>> 2) the file JMXStartStop.lck was showed too late too >>>> >>>> The fix is to add a waiting (max 20 seconds) in the function >>>> _app_start() to make sure that the pid and JMXStartStop.lck are both >>>> well created. This waiting is not entered in a normal and not too >>>> charged machine. >>>> >>>> I modified too the class JMXStartStopDoSomething, it will wake up >>>> every 500ms to check running timeout, instead of 1ms, 1ms is not >>>> reasonable short. >>>> >>>> I tested 1) by not running JMXStartStopDoSomething in the function >>>> _app_start() >>>> I tested 2) by add one second sleep before creating JMXStartStop.lck >>>> file in the class JMXStartStopDoSomething. >>>> >>>> best regards, >>>> >>>> Shanliang >>>> >> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From shanliang.jiang at oracle.com Tue Dec 4 10:05:52 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 04 Dec 2012 19:05:52 +0100 Subject: jmx-dev [PATCH] JDK-7009998: JMX synchronization during connection restart is faulty In-Reply-To: <5087F0F6.40902@oracle.com> References: <5087F0F6.40902@oracle.com> Message-ID: <50BE3B80.6040309@oracle.com> The fix is OK for me. The test is OK too. I would like to test more, for example the first thread throws an IOException when executing the method doStart(), we can check whether the 2 other threads are used to execute doStart(). But this is out of this bug fix. Thanks to fix this bug :) Shanliang Jaroslav Bachorik wrote: > I am looking for a review and patch sponsor. > > Webrev available at > http://cr.openjdk.java.net/~jbachorik/JDK-7009998/webrev.00 > > The issue is about a possible race condition in the > ClientCommunicatorAdmin when the reconnection process may be initiated > by more than one thread (eg. 3). The main reason is that the > re-connection routine logic is split into two synchronized blocks and it > relies on the state staying consistent when transiting from the one > synchronized block to the other. > > The race condition is described by the reporter as: > "In reading the code there is a scenario where the synchronization does > the wrong thing if 3 threads attempt to go through the code at the same > time. Consider the code in > com.sun.jmx.remote.internal.ClientCommunicatorAdmin.restart, the first > thread will set the state to RE_CONNECTING and then leave the > sychronization block, the second thread will find the state to be > RE_CONNECTING and wait on the lock. When thread 1 finishes and sets the > state to CONNECTED, then thread 2 can leave the synchronization block - > but fails to set the state to RE_CONNECTING because that code is > incorrectly in the else branch. Thus thread 2 starts the reconnecting > and thread 3 wakes to find the state not RE_CONNECTING so it believes it > can safely start the reconnect and it also starts reconnecting. The bad > mode is discovered in the preReconnection method." > > The fix is adding a return statement at the end of the first > synchronized block in case when the admin has been successfully > re-connected by the other thread. > > Test in "test/com/sun/jmx/remote/CCAdminReconnectTest.java" tests the > fix. Changes in "make/netbeans/jmx/build.properties" are there for the > NetBeans project to recognize the newly added test. > > > Thanks, > > -JB- > > From Alan.Bateman at oracle.com Fri Dec 14 13:33:05 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Dec 2012 21:33:05 +0000 Subject: jmx-dev 8001048: Allow IIOP transport to be optional Message-ID: <50CB9B11.2080708@oracle.com> I hope this mail doesn't cause ?amonn to choke on his coffee. The JMX Remote API specifies that the RMI connector support the IIOP transport (in addition to the default RMI transport, JRMP). This is highly problematic for our efforts to modularize the platform because of the dependency on CORBA and the CORBA Tie classes in the javax.management.remote.rmi package. It is also problematic for the Compact Profiles [1] effort for JDK 8. This issue has been on the radar for a long time, in fact it is more than 3 years ago when we pushed the changes to separate out the dependencies on CORBA. It's time to move to the next step, and to that end, we are planning to do a Maintenance Release of the JMX Remote API to make support for the IIOP transport optional. The changes proposed here are the first cut at the changes to the javadoc and some minor changes to RMIIIOPServerImpl that we missed when doing the original work to separate out the dependencies. I've also used the opportunity to change the tests so that they run when RMI-IIOP is not present. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8001048/webrev/index.html On RMIIIOPServerImpl then the reason that toStub and the close* methods throw NoSuchObjectException is because that the the IOException that would be thrown if RMI-IIOP were present and the object is not exported. On the tests then I removed System.exit from several tests because this isn't allowed in jtreg tests (we probably didn't notice this because the tests haven't been failing). -Alan. [1] http://openjdk.java.net/jeps/161 From dmitry.samersoff at oracle.com Fri Dec 14 13:38:13 2012 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 15 Dec 2012 01:38:13 +0400 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50CB9B11.2080708@oracle.com> References: <50CB9B11.2080708@oracle.com> Message-ID: <50CB9C45.70607@oracle.com> Alan, Does it make sense to move the check if (!IIOPHelper.isAvailable()) inside IIOPHelper.exportObject/unexportObject ? -Dmitry On 2012-12-15 01:33, Alan Bateman wrote: > > I hope this mail doesn't cause ?amonn to choke on his coffee. > > The JMX Remote API specifies that the RMI connector support the IIOP > transport (in addition to the default RMI transport, JRMP). This is > highly problematic for our efforts to modularize the platform because of > the dependency on CORBA and the CORBA Tie classes in the > javax.management.remote.rmi package. It is also problematic for the > Compact Profiles [1] effort for JDK 8. > > This issue has been on the radar for a long time, in fact it is more > than 3 years ago when we pushed the changes to separate out the > dependencies on CORBA. It's time to move to the next step, and to that > end, we are planning to do a Maintenance Release of the JMX Remote API > to make support for the IIOP transport optional. The changes proposed > here are the first cut at the changes to the javadoc and some minor > changes to RMIIIOPServerImpl that we missed when doing the original > work to separate out the dependencies. I've also used the opportunity to > change the tests so that they run when RMI-IIOP is not present. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8001048/webrev/index.html > > On RMIIIOPServerImpl then the reason that toStub and the close* methods > throw NoSuchObjectException is because that the the IOException that > would be thrown if RMI-IIOP were present and the object is not exported. > > On the tests then I removed System.exit from several tests because this > isn't allowed in jtreg tests (we probably didn't notice this because the > tests haven't been failing). > > -Alan. > > [1] http://openjdk.java.net/jeps/161 -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From Alan.Bateman at oracle.com Fri Dec 14 13:44:29 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Dec 2012 21:44:29 +0000 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50CB9C45.70607@oracle.com> References: <50CB9B11.2080708@oracle.com> <50CB9C45.70607@oracle.com> Message-ID: <50CB9DBD.2020901@oracle.com> On 14/12/2012 21:38, Dmitry Samersoff wrote: > Alan, > > Does it make sense to move the check > > if (!IIOPHelper.isAvailable()) > > inside > > IIOPHelper.exportObject/unexportObject ? > > -Dmitry That would be cleaner, I can do that. The highest priority for now is the javadoc, we need to make sure that the minimal changes proposed are sufficient. -Alan. From stuart.marks at oracle.com Fri Dec 14 15:12:03 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 14 Dec 2012 15:12:03 -0800 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently In-Reply-To: <50BE047F.2040607@oracle.com> References: <50BCEAE8.9000807@oracle.com> <50BCFEAA.7000805@oracle.com> <50BD0614.2040402@oracle.com> <50BDF272.9030505@oracle.com> <50BE047F.2040607@oracle.com> Message-ID: <50CBB243.2010600@oracle.com> Hi, Did this fix ever get pushed? s'marks On 12/4/12 6:11 AM, Dmitry Samersoff wrote: > Looks good for me! > -Dmitry > > On 2012-12-04 16:54, shanliang wrote: >> Hi, >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.01/ >> >> 1) I changed >> ((x++) >> to >> x=`expr $x + 1` >> >> 2) I simplified the test in _app_start(), in fact we need only to check >> the lock file. >> >> Thank, >> >> Shanliang >> >> Dmitry Samersoff wrote: >>> Shanliang, >>> >>> Changes looks good for me. >>> >>> Did you test shell changes under Solaris - if my memory is not bogus, >>> solaris /bin/sh doesn't support ((x++))? >>> >>> -Dmitry >>> >>> >>> On 2012-12-03 23:34, shanliang wrote: >>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.00/ >>>> >>>> shanliang wrote: >>>> >>>>> Hi, >>>>> >>>>> The test failed because 2 problems happened on a slow machine: >>>>> >>>>> 1) the function _get_pid() did not get right pid because the pid was >>>>> showed too late >>>>> or >>>>> 2) the file JMXStartStop.lck was showed too late too >>>>> >>>>> The fix is to add a waiting (max 20 seconds) in the function >>>>> _app_start() to make sure that the pid and JMXStartStop.lck are both >>>>> well created. This waiting is not entered in a normal and not too >>>>> charged machine. >>>>> >>>>> I modified too the class JMXStartStopDoSomething, it will wake up >>>>> every 500ms to check running timeout, instead of 1ms, 1ms is not >>>>> reasonable short. >>>>> >>>>> I tested 1) by not running JMXStartStopDoSomething in the function >>>>> _app_start() >>>>> I tested 2) by add one second sleep before creating JMXStartStop.lck >>>>> file in the class JMXStartStopDoSomething. >>>>> >>>>> best regards, >>>>> >>>>> Shanliang >>>>> >>> >>> >>> >> > > From dmitry.samersoff at oracle.com Fri Dec 14 23:33:10 2012 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 15 Dec 2012 11:33:10 +0400 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently In-Reply-To: <50CBB243.2010600@oracle.com> References: <50BCEAE8.9000807@oracle.com> <50BCFEAA.7000805@oracle.com> <50BD0614.2040402@oracle.com> <50BDF272.9030505@oracle.com> <50BE047F.2040607@oracle.com> <50CBB243.2010600@oracle.com> Message-ID: <50CC27B6.90607@oracle.com> Shanliang, I can sponsor the fix if necessary. -Dmitry On 2012-12-15 03:12, Stuart Marks wrote: > Hi, > > Did this fix ever get pushed? > > s'marks > > On 12/4/12 6:11 AM, Dmitry Samersoff wrote: >> Looks good for me! >> -Dmitry >> >> On 2012-12-04 16:54, shanliang wrote: >>> Hi, >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.01/ >>> >>> 1) I changed >>> ((x++) >>> to >>> x=`expr $x + 1` >>> >>> 2) I simplified the test in _app_start(), in fact we need only to check >>> the lock file. >>> >>> Thank, >>> >>> Shanliang >>> >>> Dmitry Samersoff wrote: >>>> Shanliang, >>>> >>>> Changes looks good for me. >>>> >>>> Did you test shell changes under Solaris - if my memory is not bogus, >>>> solaris /bin/sh doesn't support ((x++))? >>>> >>>> -Dmitry >>>> >>>> >>>> On 2012-12-03 23:34, shanliang wrote: >>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.00/ >>>>> >>>>> shanliang wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> The test failed because 2 problems happened on a slow machine: >>>>>> >>>>>> 1) the function _get_pid() did not get right pid because the pid was >>>>>> showed too late >>>>>> or >>>>>> 2) the file JMXStartStop.lck was showed too late too >>>>>> >>>>>> The fix is to add a waiting (max 20 seconds) in the function >>>>>> _app_start() to make sure that the pid and JMXStartStop.lck are both >>>>>> well created. This waiting is not entered in a normal and not too >>>>>> charged machine. >>>>>> >>>>>> I modified too the class JMXStartStopDoSomething, it will wake up >>>>>> every 500ms to check running timeout, instead of 1ms, 1ms is not >>>>>> reasonable short. >>>>>> >>>>>> I tested 1) by not running JMXStartStopDoSomething in the function >>>>>> _app_start() >>>>>> I tested 2) by add one second sleep before creating JMXStartStop.lck >>>>>> file in the class JMXStartStopDoSomething. >>>>>> >>>>>> best regards, >>>>>> >>>>>> Shanliang >>>>>> >>>> >>>> >>>> >>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From daniel.fuchs at oracle.com Sat Dec 15 04:35:50 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Sat, 15 Dec 2012 13:35:50 +0100 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50CB9B11.2080708@oracle.com> References: <50CB9B11.2080708@oracle.com> Message-ID: <50CC6EA6.4010502@oracle.com> Hi Alan, I have just two small suggestions concerning your changes in the tests: AddressableTest.java: ============== The test used to print a trace: System.out.println(">>> Test successed for "+protocols[i]); and System.out.println(">>> Test failed for "+protocols[i]); These traces seem to have been lost in the translation - maybe they should be restored? IIOPURLTest.java: =========== Line 56 - maybe it would be worth double checking that the reason why MalformedUrlException was fired is because the IIOP classes are indeed absent. Trying to load the iiop tie class could confirm it. Same remark for ProviderTest.java line 79. -- daniel On 12/14/12 10:33 PM, Alan Bateman wrote: > > I hope this mail doesn't cause ?amonn to choke on his coffee. > > The JMX Remote API specifies that the RMI connector support the IIOP > transport (in addition to the default RMI transport, JRMP). This is > highly problematic for our efforts to modularize the platform because > of the dependency on CORBA and the CORBA Tie classes in the > javax.management.remote.rmi package. It is also problematic for the > Compact Profiles [1] effort for JDK 8. > > This issue has been on the radar for a long time, in fact it is more > than 3 years ago when we pushed the changes to separate out the > dependencies on CORBA. It's time to move to the next step, and to that > end, we are planning to do a Maintenance Release of the JMX Remote API > to make support for the IIOP transport optional. The changes proposed > here are the first cut at the changes to the javadoc and some minor > changes to RMIIIOPServerImpl that we missed when doing the original > work to separate out the dependencies. I've also used the opportunity > to change the tests so that they run when RMI-IIOP is not present. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8001048/webrev/index.html > > On RMIIIOPServerImpl then the reason that toStub and the close* > methods throw NoSuchObjectException is because that the the > IOException that would be thrown if RMI-IIOP were present and the > object is not exported. > > On the tests then I removed System.exit from several tests because > this isn't allowed in jtreg tests (we probably didn't notice this > because the tests haven't been failing). > > -Alan. > > [1] http://openjdk.java.net/jeps/161 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20121215/e8ee5725/attachment.html From Alan.Bateman at oracle.com Sat Dec 15 05:18:04 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 15 Dec 2012 13:18:04 +0000 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50CC6EA6.4010502@oracle.com> References: <50CB9B11.2080708@oracle.com> <50CC6EA6.4010502@oracle.com> Message-ID: <50CC788C.4010007@oracle.com> On 15/12/2012 12:35, Daniel Fuchs wrote: > Hi Alan, > > I have just two small suggestions concerning your changes in the tests: > > AddressableTest.java: > ============== > > The test used to print a trace: > System.out.println(">>> Test successed for "+protocols[i]); > and > System.out.println(">>> Test failed for "+protocols[i]); > These traces seem to have been lost in the translation - maybe they > should be restored? I can do, they just seem surplus to requirements as there is already a lot of output when there is test failure. > > IIOPURLTest.java: > =========== > > Line 56 - maybe it would be worth double checking that the reason why > MalformedUrlException was fired is because the IIOP classes are indeed > absent. Trying to load the iiop tie class could confirm it. > > Same remark for ProviderTest.java line 79. Good idea, it serves as an addition check in the event that MalformedURLException is thrown for some other reason. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20121215/32c458e6/attachment-0001.html From Alan.Bateman at oracle.com Mon Dec 17 03:54:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Dec 2012 11:54:25 +0000 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50CB9B11.2080708@oracle.com> References: <50CB9B11.2080708@oracle.com> Message-ID: <50CF07F1.2040703@oracle.com> On 14/12/2012 21:33, Alan Bateman wrote: > > : > > http://cr.openjdk.java.net/~alanb/8001048/webrev/index.html I've refreshed this webrev to take account of some of the comments from Dmitry and Daniel. Specifically, I've changed com.sun.jmx.remote.internal.IIOPHelper (which we added then we originally decoupled the dependency on CORBA/IIOP) so that the exportObject, unexportObject and toStub methods throws exceptions when IIOP is not available. This From Alan.Bateman at oracle.com Mon Dec 17 03:58:45 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Dec 2012 11:58:45 +0000 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50CB9B11.2080708@oracle.com> References: <50CB9B11.2080708@oracle.com> Message-ID: <50CF08F5.9000307@oracle.com> On 14/12/2012 21:33, Alan Bateman wrote: > > : > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/8001048/webrev/index.html I've refreshed this webrev to take account of some of the comments from Dmitry and Daniel. Specifically, I've changed com.sun.jmx.remote.internal.IIOPHelper (which we added then we originally decoupled the dependency on CORBA/IIOP) so that the exportObject, unexportObject and toStub methods throws exceptions when IIOP is not available. This avoids the the code in RMIIIOPServerImpl from doing the checks. I've restored the additional trace messages in AddressableTest that Daniel pointed out. I've also put additional checks in IIOPURLTest and ProviderTest. Otherwise the changes are the same with the most important part to this being the javadoc changes. -Alan From daniel.fuchs at oracle.com Mon Dec 17 06:17:09 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 17 Dec 2012 15:17:09 +0100 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50CF08F5.9000307@oracle.com> References: <50CB9B11.2080708@oracle.com> <50CF08F5.9000307@oracle.com> Message-ID: <50CF2965.1080704@oracle.com> Hi Alan, Looks OK. However I noticed something strange in MissingClassTest.java, which I hadn't seen before. In this test, it seems that the "iiop" protocol is simply skipped (line 114). It was already like that before your changes - but it seems the test was originally written to test iiop too. I'm not sure why "iiop" is skipped. Maybe that was an oversight - or more probably because the test was randomly failing? -- daniel On 12/17/12 12:58 PM, Alan Bateman wrote: > On 14/12/2012 21:33, Alan Bateman wrote: >> >> : >> >> The webrev with the changes is here: >> >> http://cr.openjdk.java.net/~alanb/8001048/webrev/index.html > I've refreshed this webrev to take account of some of the comments from > Dmitry and Daniel. > > Specifically, I've changed com.sun.jmx.remote.internal.IIOPHelper (which > we added then we originally decoupled the dependency on CORBA/IIOP) so > that the exportObject, unexportObject and toStub methods throws > exceptions when IIOP is not available. This avoids the the code in > RMIIIOPServerImpl from doing the checks. > > I've restored the additional trace messages in AddressableTest that > Daniel pointed out. I've also put additional checks in IIOPURLTest and > ProviderTest. > > Otherwise the changes are the same with the most important part to this > being the javadoc changes. > > -Alan From Alan.Bateman at oracle.com Mon Dec 17 06:36:33 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Dec 2012 14:36:33 +0000 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50CF2965.1080704@oracle.com> References: <50CB9B11.2080708@oracle.com> <50CF08F5.9000307@oracle.com> <50CF2965.1080704@oracle.com> Message-ID: <50CF2DF1.4080204@oracle.com> On 17/12/2012 14:17, Daniel Fuchs wrote: > Hi Alan, > > Looks OK. > > However I noticed something strange in MissingClassTest.java, which > I hadn't seen before. In this test, it seems that the "iiop" protocol > is simply skipped (line 114). > > It was already like that before your changes - but it seems the test > was originally written to test iiop too. I'm not sure why > "iiop" is skipped. Maybe that was an oversight - or more probably > because the test was randomly failing? > > -- daniel Well spotted. I don't know the history on this test but it appears to have been disabled a long time ago. I will create a bug for it so that it's not forgotten. -Alan. From shanliang.jiang at oracle.com Mon Dec 17 06:51:13 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 17 Dec 2012 15:51:13 +0100 Subject: jmx-dev Review: JDK-7158614, JMXStartStopTest.sh failing intermittently In-Reply-To: <50CC27B6.90607@oracle.com> References: <50BCEAE8.9000807@oracle.com> <50BCFEAA.7000805@oracle.com> <50BD0614.2040402@oracle.com> <50BDF272.9030505@oracle.com> <50BE047F.2040607@oracle.com> <50CBB243.2010600@oracle.com> <50CC27B6.90607@oracle.com> Message-ID: <50CF3161.5040201@oracle.com> I got others problems with the test, some sh commands refused in 4 Solaris testing machines. Seems that this test was never passed in JPRT (maybe with new added testing machines). The new webrev version is: http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.02/ Thanks Dmitry for reviewing it again. I am going to push, it may take me sometime. Shanliang Dmitry Samersoff wrote: > Shanliang, > > I can sponsor the fix if necessary. > > -Dmitry > > On 2012-12-15 03:12, Stuart Marks wrote: > >> Hi, >> >> Did this fix ever get pushed? >> >> s'marks >> >> On 12/4/12 6:11 AM, Dmitry Samersoff wrote: >> >>> Looks good for me! >>> -Dmitry >>> >>> On 2012-12-04 16:54, shanliang wrote: >>> >>>> Hi, >>>> >>>> Here is the new webrev: >>>> http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.01/ >>>> >>>> 1) I changed >>>> ((x++) >>>> to >>>> x=`expr $x + 1` >>>> >>>> 2) I simplified the test in _app_start(), in fact we need only to check >>>> the lock file. >>>> >>>> Thank, >>>> >>>> Shanliang >>>> >>>> Dmitry Samersoff wrote: >>>> >>>>> Shanliang, >>>>> >>>>> Changes looks good for me. >>>>> >>>>> Did you test shell changes under Solaris - if my memory is not bogus, >>>>> solaris /bin/sh doesn't support ((x++))? >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2012-12-03 23:34, shanliang wrote: >>>>> >>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sjiang/JDK-7158614/webrev.00/ >>>>>> >>>>>> shanliang wrote: >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The test failed because 2 problems happened on a slow machine: >>>>>>> >>>>>>> 1) the function _get_pid() did not get right pid because the pid was >>>>>>> showed too late >>>>>>> or >>>>>>> 2) the file JMXStartStop.lck was showed too late too >>>>>>> >>>>>>> The fix is to add a waiting (max 20 seconds) in the function >>>>>>> _app_start() to make sure that the pid and JMXStartStop.lck are both >>>>>>> well created. This waiting is not entered in a normal and not too >>>>>>> charged machine. >>>>>>> >>>>>>> I modified too the class JMXStartStopDoSomething, it will wake up >>>>>>> every 500ms to check running timeout, instead of 1ms, 1ms is not >>>>>>> reasonable short. >>>>>>> >>>>>>> I tested 1) by not running JMXStartStopDoSomething in the function >>>>>>> _app_start() >>>>>>> I tested 2) by add one second sleep before creating JMXStartStop.lck >>>>>>> file in the class JMXStartStopDoSomething. >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> Shanliang >>>>>>> >>>>>>> >>>>> >>>>> >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20121217/979f0c17/attachment.html From dmitry.samersoff at oracle.com Mon Dec 17 09:37:57 2012 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 17 Dec 2012 21:37:57 +0400 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50CF08F5.9000307@oracle.com> References: <50CB9B11.2080708@oracle.com> <50CF08F5.9000307@oracle.com> Message-ID: <50CF5875.4050205@oracle.com> Alan, Didn't look into tests. JDK changes looks good for me. -Dmitry On 2012-12-17 15:58, Alan Bateman wrote: > On 14/12/2012 21:33, Alan Bateman wrote: >> >> : >> >> The webrev with the changes is here: >> >> http://cr.openjdk.java.net/~alanb/8001048/webrev/index.html > I've refreshed this webrev to take account of some of the comments from > Dmitry and Daniel. > > Specifically, I've changed com.sun.jmx.remote.internal.IIOPHelper (which > we added then we originally decoupled the dependency on CORBA/IIOP) so > that the exportObject, unexportObject and toStub methods throws > exceptions when IIOP is not available. This avoids the the code in > RMIIIOPServerImpl from doing the checks. > > I've restored the additional trace messages in AddressableTest that > Daniel pointed out. I've also put additional checks in IIOPURLTest and > ProviderTest. > > Otherwise the changes are the same with the most important part to this > being the javadoc changes. > > -Alan -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From mandy.chung at oracle.com Mon Dec 17 22:52:28 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 17 Dec 2012 22:52:28 -0800 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50CF08F5.9000307@oracle.com> References: <50CB9B11.2080708@oracle.com> <50CF08F5.9000307@oracle.com> Message-ID: <50D012AC.8090703@oracle.com> On 12/17/2012 3:58 AM, Alan Bateman wrote: > On 14/12/2012 21:33, Alan Bateman wrote: >> >> : >> >> The webrev with the changes is here: >> >> http://cr.openjdk.java.net/~alanb/8001048/webrev/index.html I looked at the source changes that look good to me. I believe RMIConnector.connect() will throw IOException("iiop not supported") if the given JMXServiceURL specifies iiop protocol but the implementation doesn't support iiop. Do you think it's worth clarifying that in RMIConnector spec - the spec for RMIConnector(JMXServiceURL, Map) constructor has service:jmx:iiop://.... listed as a valid URL. Mandy From jaroslav.bachorik at oracle.com Tue Dec 18 07:28:11 2012 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 18 Dec 2012 16:28:11 +0100 Subject: jmx-dev [PATCH] JDK-7146162: javax/management/remote/mandatory/connection/BrokenConnectionTest.java failing intermittently In-Reply-To: <509120B0.6040703@oracle.com> References: <508E8F79.60909@oracle.com> <509120B0.6040703@oracle.com> Message-ID: <50D08B8B.4080904@oracle.com> I've updated the webrev - no additional synchronisation is required. Please, review: http://cr.openjdk.java.net/~jbachorik/JDK-7146162/webrev.04 -JB- On 10/31/2012 01:59 PM, Jaroslav Bachorik wrote: > On 10/30/2012 05:10 PM, Eamonn McManus wrote: >> This area has historically caused a lot of problems and I am not >> surprised to see that there are more. While I don't know what the best >> way to fix the issue at hand is, I don't think this proposed change is >> it. The reason is that the checkConnection and gotIOException methods >> do blocking operations, and it is generally not a good idea to do >> blocking operations in a synchronized block. Is there a way to avoid >> the race condition without that? > > The important part is calling the gotIOException() method even from the > heart-beat checker. I've tried to return the synchronization block back > to the original state and the test passes with the check period of 10ms > which pushes the probability of data races rather high. > > It seems that the worst that can happen would be one additional > checkConnection() call - in case when the state gets set to TERMINATED > by another thread right after it has been checked in the synchronized > block the loop condition might evaluate to true if the state value has > not been flushed yet. > > I could change the "state" variable to be volatile but I am not sure > whether it's worth the hassle. > > -JB- > >> >> ?amonn >> >> >> 2012/10/29 Jaroslav Bachorik : >>> I am looking for a sponsor and reviewers. >>> >>> The webrev is available at >>> http://cr.openjdk.java.net/~jbachorik/JDK-7146162/webrev.03 >>> >>> As explained in the issue the failure is caused by the RMI connection >>> heart-beat thread racing against the thread executing the MBean >>> operation and encountering the IOException. The heart beat thread sets >>> the the admin state to "terminated" but does not send the failure >>> notifications. On the other side the operation thread determines the >>> state to be already terminated and skips the notifications as well. >>> >>> The fix adds the call to handle an ioexception, including sending the >>> failure notifications, to the hear-beat connection failure handler. Also >>> it widens the synchronized block since the whole code block checking for >>> the connection failure and recovering must be run atomically, >>> >>> >>> Thanks, >>> >>> -JB- > From Alan.Bateman at oracle.com Tue Dec 18 08:05:30 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Dec 2012 16:05:30 +0000 Subject: jmx-dev 8001048: Allow IIOP transport to be optional In-Reply-To: <50D012AC.8090703@oracle.com> References: <50CB9B11.2080708@oracle.com> <50CF08F5.9000307@oracle.com> <50D012AC.8090703@oracle.com> Message-ID: <50D0944A.5060303@oracle.com> On 18/12/2012 06:52, Mandy Chung wrote: > > I looked at the source changes that look good to me. I believe > RMIConnector.connect() will throw IOException("iiop not supported") if > the given JMXServiceURL specifies iiop protocol but the implementation > doesn't support iiop. Do you think it's worth clarifying that in > RMIConnector spec - the spec for RMIConnector(JMXServiceURL, Map) > constructor has service:jmx:iiop://.... listed as a valid URL. > > Mandy I mulled over this when doing the changes and concluded it wasn't strictly required, but I can go either way on this. It would really just be overriding the description of the IOException so that it's clear it gets thrown for this case too. (RMIConnectorServer.start is the other one). Do others have an opinion? -Alan. From shanliang.jiang at oracle.com Tue Dec 18 11:21:13 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 18 Dec 2012 20:21:13 +0100 Subject: jmx-dev [PATCH] JDK-7146162: javax/management/remote/mandatory/connection/BrokenConnectionTest.java failing intermittently In-Reply-To: <50D08B8B.4080904@oracle.com> References: <508E8F79.60909@oracle.com> <509120B0.6040703@oracle.com> <50D08B8B.4080904@oracle.com> Message-ID: <50D0C229.2010708@oracle.com> It is good to call gotIOException((IOException)e); but no need to call in next restart((IOException)e); the method "gotIOException" should call "restart" if necessary, otherwise "restart" may be called 2 times and generated 2 times "Reconnection notification". Shanliang Jaroslav Bachorik wrote: > I've updated the webrev - no additional synchronisation is required. > Please, review: http://cr.openjdk.java.net/~jbachorik/JDK-7146162/webrev.04 > > -JB- > > On 10/31/2012 01:59 PM, Jaroslav Bachorik wrote: > >> On 10/30/2012 05:10 PM, Eamonn McManus wrote: >> >>> This area has historically caused a lot of problems and I am not >>> surprised to see that there are more. While I don't know what the best >>> way to fix the issue at hand is, I don't think this proposed change is >>> it. The reason is that the checkConnection and gotIOException methods >>> do blocking operations, and it is generally not a good idea to do >>> blocking operations in a synchronized block. Is there a way to avoid >>> the race condition without that? >>> >> The important part is calling the gotIOException() method even from the >> heart-beat checker. I've tried to return the synchronization block back >> to the original state and the test passes with the check period of 10ms >> which pushes the probability of data races rather high. >> >> It seems that the worst that can happen would be one additional >> checkConnection() call - in case when the state gets set to TERMINATED >> by another thread right after it has been checked in the synchronized >> block the loop condition might evaluate to true if the state value has >> not been flushed yet. >> >> I could change the "state" variable to be volatile but I am not sure >> whether it's worth the hassle. >> >> -JB- >> >> >>> ?amonn >>> >>> >>> 2012/10/29 Jaroslav Bachorik : >>> >>>> I am looking for a sponsor and reviewers. >>>> >>>> The webrev is available at >>>> http://cr.openjdk.java.net/~jbachorik/JDK-7146162/webrev.03 >>>> >>>> As explained in the issue the failure is caused by the RMI connection >>>> heart-beat thread racing against the thread executing the MBean >>>> operation and encountering the IOException. The heart beat thread sets >>>> the the admin state to "terminated" but does not send the failure >>>> notifications. On the other side the operation thread determines the >>>> state to be already terminated and skips the notifications as well. >>>> >>>> The fix adds the call to handle an ioexception, including sending the >>>> failure notifications, to the hear-beat connection failure handler. Also >>>> it widens the synchronized block since the whole code block checking for >>>> the connection failure and recovering must be run atomically, >>>> >>>> >>>> Thanks, >>>> >>>> -JB- >>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20121218/42b26420/attachment.html From jaroslav.bachorik at oracle.com Wed Dec 19 02:00:49 2012 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 19 Dec 2012 11:00:49 +0100 Subject: jmx-dev [PATCH] JDK-7146162: javax/management/remote/mandatory/connection/BrokenConnectionTest.java failing intermittently In-Reply-To: <50D0C229.2010708@oracle.com> References: <508E8F79.60909@oracle.com> <509120B0.6040703@oracle.com> <50D08B8B.4080904@oracle.com> <50D0C229.2010708@oracle.com> Message-ID: <50D19051.2080904@oracle.com> On 12/18/2012 08:21 PM, shanliang wrote: > It is good to call > gotIOException((IOException)e); > > but no need to call in next > restart((IOException)e); > > the method "gotIOException" should call "restart" if necessary, > otherwise "restart" may be called 2 times and generated 2 times > "Reconnection notification". Yes, it seems that the restart() will be called exactly twice or not at all. I will remove the restart() call at the line 199. Updated webrev to http://cr.openjdk.java.net/~jbachorik/JDK-7146162/webrev.05 -JB- > > Shanliang > > Jaroslav Bachorik wrote: >> I've updated the webrev - no additional synchronisation is required. >> Please, review: >> http://cr.openjdk.java.net/~jbachorik/JDK-7146162/webrev.04 >> >> -JB- >> >> On 10/31/2012 01:59 PM, Jaroslav Bachorik wrote: >> >>> On 10/30/2012 05:10 PM, Eamonn McManus wrote: >>> >>>> This area has historically caused a lot of problems and I am not >>>> surprised to see that there are more. While I don't know what the best >>>> way to fix the issue at hand is, I don't think this proposed change is >>>> it. The reason is that the checkConnection and gotIOException methods >>>> do blocking operations, and it is generally not a good idea to do >>>> blocking operations in a synchronized block. Is there a way to avoid >>>> the race condition without that? >>>> >>> The important part is calling the gotIOException() method even from the >>> heart-beat checker. I've tried to return the synchronization block back >>> to the original state and the test passes with the check period of 10ms >>> which pushes the probability of data races rather high. >>> >>> It seems that the worst that can happen would be one additional >>> checkConnection() call - in case when the state gets set to TERMINATED >>> by another thread right after it has been checked in the synchronized >>> block the loop condition might evaluate to true if the state value has >>> not been flushed yet. >>> >>> I could change the "state" variable to be volatile but I am not sure >>> whether it's worth the hassle. >>> >>> -JB- >>> >>> >>>> ?amonn >>>> >>>> >>>> 2012/10/29 Jaroslav Bachorik : >>>> >>>>> I am looking for a sponsor and reviewers. >>>>> >>>>> The webrev is available at >>>>> http://cr.openjdk.java.net/~jbachorik/JDK-7146162/webrev.03 >>>>> >>>>> As explained in the issue the failure is caused by the RMI connection >>>>> heart-beat thread racing against the thread executing the MBean >>>>> operation and encountering the IOException. The heart beat thread sets >>>>> the the admin state to "terminated" but does not send the failure >>>>> notifications. On the other side the operation thread determines the >>>>> state to be already terminated and skips the notifications as well. >>>>> >>>>> The fix adds the call to handle an ioexception, including sending the >>>>> failure notifications, to the hear-beat connection failure handler. >>>>> Also >>>>> it widens the synchronized block since the whole code block >>>>> checking for >>>>> the connection failure and recovering must be run atomically, >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>>> >> >> > > From shanliang.jiang at oracle.com Wed Dec 19 02:53:07 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 19 Dec 2012 11:53:07 +0100 Subject: jmx-dev [PATCH] JDK-7146162: javax/management/remote/mandatory/connection/BrokenConnectionTest.java failing intermittently In-Reply-To: <50D19051.2080904@oracle.com> References: <508E8F79.60909@oracle.com> <509120B0.6040703@oracle.com> <50D08B8B.4080904@oracle.com> <50D0C229.2010708@oracle.com> <50D19051.2080904@oracle.com> Message-ID: <50D19C93.10806@oracle.com> The fix is OK for me. Shanliang Jaroslav Bachorik wrote: > On 12/18/2012 08:21 PM, shanliang wrote: > >> It is good to call >> gotIOException((IOException)e); >> >> but no need to call in next >> restart((IOException)e); >> >> the method "gotIOException" should call "restart" if necessary, >> otherwise "restart" may be called 2 times and generated 2 times >> "Reconnection notification". >> > > Yes, it seems that the restart() will be called exactly twice or not at > all. I will remove the restart() call at the line 199. > > Updated webrev to > http://cr.openjdk.java.net/~jbachorik/JDK-7146162/webrev.05 > > -JB- > > > > >> Shanliang >> >> Jaroslav Bachorik wrote: >> >>> I've updated the webrev - no additional synchronisation is required. >>> Please, review: >>> http://cr.openjdk.java.net/~jbachorik/JDK-7146162/webrev.04 >>> >>> -JB- >>> >>> On 10/31/2012 01:59 PM, Jaroslav Bachorik wrote: >>> >>> >>>> On 10/30/2012 05:10 PM, Eamonn McManus wrote: >>>> >>>> >>>>> This area has historically caused a lot of problems and I am not >>>>> surprised to see that there are more. While I don't know what the best >>>>> way to fix the issue at hand is, I don't think this proposed change is >>>>> it. The reason is that the checkConnection and gotIOException methods >>>>> do blocking operations, and it is generally not a good idea to do >>>>> blocking operations in a synchronized block. Is there a way to avoid >>>>> the race condition without that? >>>>> >>>>> >>>> The important part is calling the gotIOException() method even from the >>>> heart-beat checker. I've tried to return the synchronization block back >>>> to the original state and the test passes with the check period of 10ms >>>> which pushes the probability of data races rather high. >>>> >>>> It seems that the worst that can happen would be one additional >>>> checkConnection() call - in case when the state gets set to TERMINATED >>>> by another thread right after it has been checked in the synchronized >>>> block the loop condition might evaluate to true if the state value has >>>> not been flushed yet. >>>> >>>> I could change the "state" variable to be volatile but I am not sure >>>> whether it's worth the hassle. >>>> >>>> -JB- >>>> >>>> >>>> >>>>> ?amonn >>>>> >>>>> >>>>> 2012/10/29 Jaroslav Bachorik : >>>>> >>>>> >>>>>> I am looking for a sponsor and reviewers. >>>>>> >>>>>> The webrev is available at >>>>>> http://cr.openjdk.java.net/~jbachorik/JDK-7146162/webrev.03 >>>>>> >>>>>> As explained in the issue the failure is caused by the RMI connection >>>>>> heart-beat thread racing against the thread executing the MBean >>>>>> operation and encountering the IOException. The heart beat thread sets >>>>>> the the admin state to "terminated" but does not send the failure >>>>>> notifications. On the other side the operation thread determines the >>>>>> state to be already terminated and skips the notifications as well. >>>>>> >>>>>> The fix adds the call to handle an ioexception, including sending the >>>>>> failure notifications, to the hear-beat connection failure handler. >>>>>> Also >>>>>> it widens the synchronized block since the whole code block >>>>>> checking for >>>>>> the connection failure and recovering must be run atomically, >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20121219/c16d00f0/attachment.html From jaroslav.bachorik at oracle.com Thu Dec 20 04:21:05 2012 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 20 Dec 2012 13:21:05 +0100 Subject: jmx-dev [PATCH] JDK-7199324: IPv6 JMXConnectorServer.getConnectionIDs() return IDs contradicting address grammar Message-ID: <50D302B1.7080203@oracle.com> Looking for reviewers and a sponsor. Webrev is available at http://cr.openjdk.java.net/~jbachorik/JDK-7199324/webrev.00 The issue is about the JMX client connection ID not being generated accordingly to the specification when including an IPv6 address. The specification states that in such case the address must be enclosed in square brackets. The current implementation, however, returns the plain numeric address, contradicting the specification. The fix simply checks for the presence of ":" character in the address part of the connection ID and escapes the address if necessary. Since the ":" can be present only in a numeric IPv6 address this check is sufficient. The change to test just covers for checking proper escaping - I am not sure how to force IPv6 to be used from the test; probably it is not possible. The test will check the IPv6 address escaping when and only when the system setup will cause the JMX client to connect over IPv6. Thanks, -JB- From shanliang.jiang at oracle.com Mon Dec 24 06:08:55 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 24 Dec 2012 15:08:55 +0100 Subject: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException In-Reply-To: <50D302B1.7080203@oracle.com> References: <50D302B1.7080203@oracle.com> Message-ID: <50D861F7.80605@oracle.com> webrev: http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.00/ The test is correct, it was implemented to verify the fix for bug 4911721, but in addition it detects luckily another problem within the method ServerNotifForwarder.snoopOnUnregister The problem was that during a "for" cycle, the set list was modified by anther thread, the solution is to use a unmodifiable set. This fix is important, it not only re-enables a test, but also fixes a concurrent modification bug in the jmx notification. Shanliang From shanliang.jiang at oracle.com Mon Dec 24 06:43:13 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 24 Dec 2012 15:43:13 +0100 Subject: jmx-dev [PATCH] JDK-7199324: IPv6 JMXConnectorServer.getConnectionIDs() return IDs contradicting address grammar In-Reply-To: <50D302B1.7080203@oracle.com> References: <50D302B1.7080203@oracle.com> Message-ID: <50D86A01.2060703@oracle.com> The fix looks OK for me, and I can be sponsor. If possible I think it is better to test the fix in an IPv6 machine. It is said that IPv6 is enabled by default on windows7 (http://pcuserinfo.com/how-to-enable-install-and-configure-ipv6-windows-7/), but need to be installed on XP. Look at the JMXServiceURL, it contains the address at which the connector server is found: //[host[:port]][url-path] we can specify a IPv6 host address here. For example ::1 equivalent to IPv4 127.0.0.1 But I never do it. Shanliang Jaroslav Bachorik wrote: > Looking for reviewers and a sponsor. > > Webrev is available at > http://cr.openjdk.java.net/~jbachorik/JDK-7199324/webrev.00 > > The issue is about the JMX client connection ID not being generated > accordingly to the specification when including an IPv6 address. The > specification states that in such case the address must be enclosed in > square brackets. The current implementation, however, returns the plain > numeric address, contradicting the specification. > > The fix simply checks for the presence of ":" character in the address > part of the connection ID and escapes the address if necessary. Since > the ":" can be present only in a numeric IPv6 address this check is > sufficient. > > The change to test just covers for checking proper escaping - I am not > sure how to force IPv6 to be used from the test; probably it is not > possible. The test will check the IPv6 address escaping when and only > when the system setup will cause the JMX client to connect over IPv6. > > Thanks, > > -JB- > From Alan.Bateman at oracle.com Mon Dec 24 08:06:41 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Dec 2012 16:06:41 +0000 Subject: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException In-Reply-To: <50D861F7.80605@oracle.com> References: <50D302B1.7080203@oracle.com> <50D861F7.80605@oracle.com> Message-ID: <50D87D91.9010607@oracle.com> On 24/12/2012 14:08, shanliang wrote: > webrev: http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.00/ > > The test is correct, it was implemented to verify the fix for bug > 4911721, but in addition it detects luckily another problem within the > method ServerNotifForwarder.snoopOnUnregister > > The problem was that during a "for" cycle, the set list was modified > by anther thread, the solution is to use a unmodifiable set. > > This fix is important, it not only re-enables a test, but also fixes a > concurrent modification bug in the jmx notification. > > Shanliang Are you sure this is right? I don't know this code but from a brief glance then it appears to me that all access to listenerMap requires first synchronizes on it and maybe you need to do this and then take a copy (not a unmodifiable view) of the delegate set before you iterate over it. Apologies if you looked at this in detail, it's just not clear to me how using an unmodifiable view fixes the problem if the issue is actually that other threads are modifying the set. -Alan From shanliang.jiang at oracle.com Wed Dec 26 07:07:03 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 26 Dec 2012 16:07:03 +0100 Subject: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException In-Reply-To: <50D87D91.9010607@oracle.com> References: <50D302B1.7080203@oracle.com> <50D861F7.80605@oracle.com> <50D87D91.9010607@oracle.com> Message-ID: <50DB1297.7020807@oracle.com> Yes should use a cop[y, it is a mistake to use a unmodifiable view. Here is the new webrev: http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.02/ I have added a new test to reproduce the bug in an almost sure way. Thanks, Shanliang Alan Bateman wrote: > On 24/12/2012 14:08, shanliang wrote: >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.00/ >> >> The test is correct, it was implemented to verify the fix for bug >> 4911721, but in addition it detects luckily another problem within >> the method ServerNotifForwarder.snoopOnUnregister >> >> The problem was that during a "for" cycle, the set list was modified >> by anther thread, the solution is to use a unmodifiable set. >> >> This fix is important, it not only re-enables a test, but also fixes >> a concurrent modification bug in the jmx notification. >> >> Shanliang > Are you sure this is right? I don't know this code but from a brief > glance then it appears to me that all access to listenerMap requires > first synchronizes on it and maybe you need to do this and then take a > copy (not a unmodifiable view) of the delegate set before you iterate > over it. Apologies if you looked at this in detail, it's just not > clear to me how using an unmodifiable view fixes the problem if the > issue is actually that other threads are modifying the set. > > -Alan From Alan.Bateman at oracle.com Wed Dec 26 13:14:57 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 26 Dec 2012 21:14:57 +0000 Subject: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException In-Reply-To: <50DB1297.7020807@oracle.com> References: <50D302B1.7080203@oracle.com> <50D861F7.80605@oracle.com> <50D87D91.9010607@oracle.com> <50DB1297.7020807@oracle.com> Message-ID: <50DB68D1.2040704@oracle.com> On 26/12/2012 15:07, shanliang wrote: > Yes should use a cop[y, it is a mistake to use a unmodifiable view. > > Here is the new webrev: > http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.02/ > > I have added a new test to reproduce the bug in an almost sure way. > > Thanks, > > Shanliang Thanks for the update, the synchronization and copy looks right to me. An alternative you be "if (delegateSet == null || delegateSet.isEmpty()) return; " which might be a bit cleaner. I didn't study the new test very closely but I assume you should only catch MalformedURLException at line 122 rather than Exception. As it's a new test then I assume it should have 2012 as the date. You can probably remove the @run as the defaults (compile + run) is right for this test. -Alan From shanliang.jiang at oracle.com Thu Dec 27 03:33:51 2012 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 27 Dec 2012 12:33:51 +0100 Subject: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException In-Reply-To: <50DB68D1.2040704@oracle.com> References: <50D302B1.7080203@oracle.com> <50D861F7.80605@oracle.com> <50D87D91.9010607@oracle.com> <50DB1297.7020807@oracle.com> <50DB68D1.2040704@oracle.com> Message-ID: <50DC321F.2070500@oracle.com> Thanks for all comments, here is the new webrev: http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.03/ Indeed, no need to have @run for the test. Shanliang Alan Bateman wrote: > On 26/12/2012 15:07, shanliang wrote: >> Yes should use a cop[y, it is a mistake to use a unmodifiable view. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.02/ >> >> I have added a new test to reproduce the bug in an almost sure way. >> >> Thanks, >> >> Shanliang > Thanks for the update, the synchronization and copy looks right to me. > An alternative you be "if (delegateSet == null || > delegateSet.isEmpty()) return; " which might be a bit cleaner. > > I didn't study the new test very closely but I assume you should only > catch MalformedURLException at line 122 rather than Exception. As it's > a new test then I assume it should have 2012 as the date. You can > probably remove the @run as the defaults (compile + run) is right for > this test. > > -Alan From Alan.Bateman at oracle.com Thu Dec 27 07:55:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Dec 2012 15:55:25 +0000 Subject: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException In-Reply-To: <50DC321F.2070500@oracle.com> References: <50D302B1.7080203@oracle.com> <50D861F7.80605@oracle.com> <50D87D91.9010607@oracle.com> <50DB1297.7020807@oracle.com> <50DB68D1.2040704@oracle.com> <50DC321F.2070500@oracle.com> Message-ID: <50DC6F6D.5060001@oracle.com> On 27/12/2012 11:33, shanliang wrote: > Thanks for all comments, here is the new webrev: > http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.03/ > > Indeed, no need to have @run for the test. > > Shanliang Thanks, it looks okay to me now. -Alan From stuart.marks at oracle.com Thu Dec 27 10:19:10 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 27 Dec 2012 10:19:10 -0800 Subject: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException In-Reply-To: <50DC321F.2070500@oracle.com> References: <50D302B1.7080203@oracle.com> <50D861F7.80605@oracle.com> <50D87D91.9010607@oracle.com> <50DB1297.7020807@oracle.com> <50DB68D1.2040704@oracle.com> <50DC321F.2070500@oracle.com> Message-ID: <50DC911E.1010100@oracle.com> I hate to contradict Alan on this.... It's true that one can omit the @run tag and single-file tests like this one will get built and run by default. My advice, however, is to use the @run tag even when one isn't strictly required. The reason has to do with jtreg's rules of when it decides to behave as if an @run tag were present, and perhaps more pertinently, when it does NOT. Here's an example. Suppose we have a test that has these tags in a file named MyTest.java: @test @bug 1234567 @summary My simple test. @author Fred Since there are no @run tags, jtreg will implicitly act as if "@run main MyTest" were present. OK so far. Now suppose we modify the test to use a helper class of some sort. We'd need to add an @build tag to ensure this class is built: @test @bug 1234567 @summary My simple test. @author Fred @build Helper The problem here is that "@build Helper" is an abbreviation for "@run build Helper". Since there is now an @run tag present, the implicit "@run main MyTest" behavior no longer occurs, so the test doesn't actually get run! Worse, if you ask jtreg to run the test, it will happily build the Helper and MyTest classes and declare that the test has passed, without actually having run anything!! You have to inspect the test output fairly carefully in order to discover this. This kind of problem is hard to spot. In the JDK regression suite, we've had tests in this state for long periods of time where they would "pass" regularly but nobody noticed that the test wasn't actually running. So, I'd suggest that you add a @run tag anyway if you get a chance before you push the changeset. s'marks On 12/27/12 3:33 AM, shanliang wrote: > Thanks for all comments, here is the new webrev: > http://cr.openjdk.java.net/~sjiang/JDK-7120365/webrev.03/ > > Indeed, no need to have @run for the test. > > Shanliang > > Alan Bateman wrote: >> You can probably remove the >> @run as the defaults (compile + run) is right for this test. >> >> -Alan > From Alan.Bateman at oracle.com Thu Dec 27 14:31:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Dec 2012 22:31:16 +0000 Subject: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException In-Reply-To: <50DC911E.1010100@oracle.com> References: <50D302B1.7080203@oracle.com> <50D861F7.80605@oracle.com> <50D87D91.9010607@oracle.com> <50DB1297.7020807@oracle.com> <50DB68D1.2040704@oracle.com> <50DC321F.2070500@oracle.com> <50DC911E.1010100@oracle.com> Message-ID: <50DCCC34.9080800@oracle.com> On 27/12/2012 18:19, Stuart Marks wrote: > I hate to contradict Alan on this.... > > It's true that one can omit the @run tag and single-file tests like > this one will get built and run by default. My advice, however, is to > use the @run tag even when one isn't strictly required. My comment was on the 3 x @run tags, the "@run clean" appeared odd. In any case, I agree that for anything other than single-class tests then it's really important to be explicit on the classes to compile. For single-class tests then I personally just keep it simple as jtreg will do the right thing once you add @test. -Alan From stuart.marks at oracle.com Thu Dec 27 19:22:12 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 27 Dec 2012 19:22:12 -0800 Subject: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException In-Reply-To: <50DCCC34.9080800@oracle.com> References: <50D302B1.7080203@oracle.com> <50D861F7.80605@oracle.com> <50D87D91.9010607@oracle.com> <50DB1297.7020807@oracle.com> <50DB68D1.2040704@oracle.com> <50DC321F.2070500@oracle.com> <50DC911E.1010100@oracle.com> <50DCCC34.9080800@oracle.com> Message-ID: <50DD1064.9050100@oracle.com> On 12/27/12 2:31 PM, Alan Bateman wrote: > On 27/12/2012 18:19, Stuart Marks wrote: >> It's true that one can omit the @run tag and single-file tests like this one >> will get built and run by default. My advice, however, is to use the @run tag >> even when one isn't strictly required. > My comment was on the 3 x @run tags, the "@run clean" appeared odd. In any > case, I agree that for anything other than single-class tests then it's really > important to be explicit on the classes to compile. For single-class tests then > I personally just keep it simple as jtreg will do the right thing once you add > @test. I agree that all three @run tags were unnecessary. From webrev.02: 29 * @run clean ConcurrentModificationTest 30 * @run build ConcurrentModificationTest 31 * @run main ConcurrentModificationTest I'd suggest that lines 29 and 30 be removed, leaving only the "@run main" from line 31. But in webrev.03 they've all been removed. The test will run and work fine, until somebody adds an @build tag (or other similar tag), which will cause the test to build but not run, but it will still be reported as passing. This has happened before, and it'll happen again. Alan, you've fixed a bunch of tests that were missing @run tags at least twice in the past [1], [2]. I observe that this recent changeset [3] removed an @run tag that was necessary to run the test. It's not quite the same pathology, but it demonstrates that it's pretty easy to get the jtreg tags wrong. Sorry Shanliang, I'm using your changeset as a springboard for this discussion of jtreg tag style. I really do recommend that each test include an explicit @run tag, since the tags are so easy to get wrong. s'marks [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/d5ee8b871362 [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6d934b1d9dd5 [3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/775b0050144a From Alan.Bateman at oracle.com Thu Dec 27 23:39:21 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Dec 2012 07:39:21 +0000 Subject: jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException In-Reply-To: <50DD1064.9050100@oracle.com> References: <50D302B1.7080203@oracle.com> <50D861F7.80605@oracle.com> <50D87D91.9010607@oracle.com> <50DB1297.7020807@oracle.com> <50DB68D1.2040704@oracle.com> <50DC321F.2070500@oracle.com> <50DC911E.1010100@oracle.com> <50DCCC34.9080800@oracle.com> <50DD1064.9050100@oracle.com> Message-ID: <50DD4CA9.2060000@oracle.com> On 28/12/2012 03:22, Stuart Marks wrote: > : > > Alan, you've fixed a bunch of tests that were missing @run tags at > least twice in the past [1], [2]. I observe that this recent changeset > [3] removed an @run tag that was necessary to run the test. It's not > quite the same pathology, but it demonstrates that it's pretty easy to > get the jtreg tags wrong. > > Sorry Shanliang, I'm using your changeset as a springboard for this > discussion of jtreg tag style. I really do recommend that each test > include an explicit @run tag, since the tags are so easy to get wrong. That's fine, my main observation (after fixing several of these) is that the mistake happen once it becomes necessary to use @build or @compile. It is really easy to not observe that the test isn't actually executed if there isn't an @run. Anyway, I think this is something for a regular checking script to check for, it just needs to have a list of the compile-only tests so that it doesn't flag as missing a tag. -Alan From jaroslav.bachorik at oracle.com Mon Dec 31 02:40:40 2012 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 31 Dec 2012 11:40:40 +0100 Subject: jmx-dev [PATCH] JDK-8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows Message-ID: <50E16BA8.40203@oracle.com> Looking for a review and a sponsor. Webrev at: http://cr.openjdk.java.net/~jbachorik/8005472/webrev.00/test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh.sdiff.html JPRT run on windows targets: http://sthjprt.se.oracle.com/archives/2012/12/2012-12-28-123054.jbachorik.openjdk8-tl//JobStatus.txt The issue is about a new test failing when run on windows machines. It seems that the cygwin really does not like removing a non-existent file - to the extent of hanging the script indefinitely. The patch adds a pre-check for the existence of the file to be removed. It does not change the test in any other way. Thanks, -JB-