From jaroslav.bachorik at oracle.com Mon Jan 4 09:05:09 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 4 Jan 2016 10:05:09 +0100 Subject: jmx-dev [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <567A76BF.5090305@oracle.com> References: <567A76BF.5090305@oracle.com> Message-ID: <568A35C5.7020804@oracle.com> Gentle reminder ... On 23.12.2015 11:26, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 > Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 > > The test fails for IPv6 addresses since the RMI expects an IPv6 address > to be properly wrapped in '[]'. In addition to that the logic for > selecting IP addresses to bind is flawed - it does not check for IP > addresses of multiple adapters but for multiple IP addresses assigned to > 'localhost'. In combination with IPv4 & IPv6 this will cause the test to > attempt binding to IPv4 and IPv6 address of the same adapter > simultaneously and the test will fail. > > The fix adds the requested wrapping for IPv6 addresses and adjusts the > IP selection logic to iterate over distinct adapters first and prevent > IPv4 and IPv6 address of the same adapter being treated as two addresses > (for the purposes of the test). > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Jan 4 10:20:28 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 4 Jan 2016 11:20:28 +0100 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java Message-ID: <568A476C.6060101@oracle.com> Please, review the following simple change Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 The patch removes the special path taken when jmxrmi.jar is present on the bootclasspath. There are two reasons for this cleanup: 1. Bootclasspath will not be available (or meaningful) in Jigsaw 2. We haven't been testing with an external jmxrmi.jar for ages - since JMX was included into JDK in JDK 5. The modified test is still passing. -JB- From Alan.Bateman at oracle.com Mon Jan 4 11:09:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 Jan 2016 11:09:03 +0000 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568A476C.6060101@oracle.com> References: <568A476C.6060101@oracle.com> Message-ID: <568A52CF.7060707@oracle.com> On 04/01/2016 10:20, Jaroslav Bachorik wrote: > Please, review the following simple change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 > Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 > > The patch removes the special path taken when jmxrmi.jar is present on > the bootclasspath. There are two reasons for this cleanup: > 1. Bootclasspath will not be available (or meaningful) in Jigsaw > 2. We haven't been testing with an external jmxrmi.jar for ages - > since JMX was included into JDK in JDK 5. > > The modified test is still passing. Does the @summary line need to be updated to drop the mention of "when JMX is bundled"? Otherwise looks okay to me. -Alan From jaroslav.bachorik at oracle.com Mon Jan 4 15:05:13 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 4 Jan 2016 16:05:13 +0100 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568A52CF.7060707@oracle.com> References: <568A476C.6060101@oracle.com> <568A52CF.7060707@oracle.com> Message-ID: <568A8A29.60907@oracle.com> On 4.1.2016 12:09, Alan Bateman wrote: > > > On 04/01/2016 10:20, Jaroslav Bachorik wrote: >> Please, review the following simple change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 >> >> The patch removes the special path taken when jmxrmi.jar is present on >> the bootclasspath. There are two reasons for this cleanup: >> 1. Bootclasspath will not be available (or meaningful) in Jigsaw >> 2. We haven't been testing with an external jmxrmi.jar for ages - >> since JMX was included into JDK in JDK 5. >> >> The modified test is still passing. > Does the @summary line need to be updated to drop the mention of "when > JMX is bundled"? Otherwise looks okay to me. Not sure. With this change in place the test will not even try to detect the situation when JMX is not bundled with JDK. There is another test (jdk/test/javax/management/remote/mandatory/version/ImplVersionTest.java) with the same wording in the summary but not even trying to detest the standalone jmxrmi.jar. If you insist on changing the wording I would prefer changing both of these tests in one go, perhaps as a separate CR? -JB- > > -Alan From Alan.Bateman at oracle.com Mon Jan 4 15:25:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 Jan 2016 15:25:39 +0000 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568A8A29.60907@oracle.com> References: <568A476C.6060101@oracle.com> <568A52CF.7060707@oracle.com> <568A8A29.60907@oracle.com> Message-ID: <568A8EF3.3000704@oracle.com> On 04/01/2016 15:05, Jaroslav Bachorik wrote: > : > > Not sure. With this change in place the test will not even try to > detect the situation when JMX is not bundled with JDK. > > There is another test > (jdk/test/javax/management/remote/mandatory/version/ImplVersionTest.java) > with the same wording in the summary but not even trying to detest the > standalone jmxrmi.jar. > > If you insist on changing the wording I would prefer changing both of > these tests in one go, perhaps as a separate CR? I just wanted to make the point that with the change then the @summary on the test doesn't make sense and it's the opportunity to align it with what the test does. Doing the other test as as separate issue is no problem. -Alan From eamonn at mcmanus.net Mon Jan 4 20:26:47 2016 From: eamonn at mcmanus.net (Eamonn McManus) Date: Mon, 4 Jan 2016 12:26:47 -0800 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568A476C.6060101@oracle.com> References: <568A476C.6060101@oracle.com> Message-ID: I think this test should either be deleted or reduced to a simple check that the MBeanServerDelegate's ImplementationVersion attribute is equal to System.getProperty("java.runtime.version"). The whole business of starting up a separate process and checking things with security managers and so on is completely obsolete. ?amonn 2016-01-04 2:20 GMT-08:00 Jaroslav Bachorik : > Please, review the following simple change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 > Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 > > The patch removes the special path taken when jmxrmi.jar is present on the > bootclasspath. There are two reasons for this cleanup: > 1. Bootclasspath will not be available (or meaningful) in Jigsaw > 2. We haven't been testing with an external jmxrmi.jar for ages - since > JMX was included into JDK in JDK 5. > > The modified test is still passing. > > -JB- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Jan 5 13:52:04 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 5 Jan 2016 14:52:04 +0100 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: References: <568A476C.6060101@oracle.com> Message-ID: <568BCA84.2030401@oracle.com> On 4.1.2016 21:26, Eamonn McManus wrote: > I think this test should either be deleted or reduced to a simple check > that the MBeanServerDelegate's ImplementationVersion attribute is equal > to System.getProperty("java.runtime.version"). The whole business of > starting up a separate process and checking things with security > managers and so on is completely obsolete. I would leave this for SQE to decide. Removing the security manager part would change the semantics of the test. I would suggest dealing with this in a separate issue not to block the effort of removing references to 'sun.boot.class.path' for jigsaw. -JB- > > ?amonn > > 2016-01-04 2:20 GMT-08:00 Jaroslav Bachorik > >: > > Please, review the following simple change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 > Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 > > The patch removes the special path taken when jmxrmi.jar is present > on the bootclasspath. There are two reasons for this cleanup: > 1. Bootclasspath will not be available (or meaningful) in Jigsaw > 2. We haven't been testing with an external jmxrmi.jar for ages - > since JMX was included into JDK in JDK 5. > > The modified test is still passing. > > -JB- > > From Alan.Bateman at oracle.com Tue Jan 5 14:00:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jan 2016 14:00:03 +0000 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568BCA84.2030401@oracle.com> References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> Message-ID: <568BCC63.5030704@oracle.com> On 05/01/2016 13:52, Jaroslav Bachorik wrote: > On 4.1.2016 21:26, Eamonn McManus wrote: >> I think this test should either be deleted or reduced to a simple check >> that the MBeanServerDelegate's ImplementationVersion attribute is equal >> to System.getProperty("java.runtime.version"). The whole business of >> starting up a separate process and checking things with security >> managers and so on is completely obsolete. > > I would leave this for SQE to decide. Removing the security manager > part would change the semantics of the test. > > I would suggest dealing with this in a separate issue not to block the > effort of removing references to 'sun.boot.class.path' for jigsaw. Just to say that sun.boot.class.path is already removed in the jake forest. I created JDK-8143047 to re-examine this test as it looked like it was obsolete and could be deleted. So no urgently fixing this, it's not blocking anything. -Alan From jaroslav.bachorik at oracle.com Tue Jan 5 14:03:55 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 5 Jan 2016 15:03:55 +0100 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568BCC63.5030704@oracle.com> References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> <568BCC63.5030704@oracle.com> Message-ID: <568BCD4B.5070402@oracle.com> On 5.1.2016 15:00, Alan Bateman wrote: > > > On 05/01/2016 13:52, Jaroslav Bachorik wrote: >> On 4.1.2016 21:26, Eamonn McManus wrote: >>> I think this test should either be deleted or reduced to a simple check >>> that the MBeanServerDelegate's ImplementationVersion attribute is equal >>> to System.getProperty("java.runtime.version"). The whole business of >>> starting up a separate process and checking things with security >>> managers and so on is completely obsolete. >> >> I would leave this for SQE to decide. Removing the security manager >> part would change the semantics of the test. >> >> I would suggest dealing with this in a separate issue not to block the >> effort of removing references to 'sun.boot.class.path' for jigsaw. > Just to say that sun.boot.class.path is already removed in the jake > forest. I created JDK-8143047 to re-examine this test as it looked like > it was obsolete and could be deleted. So no urgently fixing this, it's > not blocking anything. Ok. Thanks for the clarification. In this case I downgraded the task priority to P3. -JB- > > -Alan From jaroslav.bachorik at oracle.com Tue Jan 5 14:30:54 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 5 Jan 2016 15:30:54 +0100 Subject: jmx-dev [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <568A35C5.7020804@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> Message-ID: <568BD39E.20305@oracle.com> On 4.1.2016 10:05, Jaroslav Bachorik wrote: > Gentle reminder ... > > On 23.12.2015 11:26, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >> >> The test fails for IPv6 addresses since the RMI expects an IPv6 address >> to be properly wrapped in '[]'. In addition to that the logic for >> selecting IP addresses to bind is flawed - it does not check for IP >> addresses of multiple adapters but for multiple IP addresses assigned to >> 'localhost'. In combination with IPv4 & IPv6 this will cause the test to >> attempt binding to IPv4 and IPv6 address of the same adapter >> simultaneously and the test will fail. >> >> The fix adds the requested wrapping for IPv6 addresses and adjusts the >> IP selection logic to iterate over distinct adapters first and prevent >> IPv4 and IPv6 address of the same adapter being treated as two addresses >> (for the purposes of the test). >> >> Thanks, >> >> -JB- > From eamonn at mcmanus.net Tue Jan 5 15:47:42 2016 From: eamonn at mcmanus.net (Eamonn McManus) Date: Tue, 5 Jan 2016 07:47:42 -0800 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568BCA84.2030401@oracle.com> References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> Message-ID: OK. In that case I would suggest removing the checkVersion variable since it is now always true, along with the logic from ImplVersionCommand for when it is false. ?amonn 2016-01-05 5:52 GMT-08:00 Jaroslav Bachorik : > On 4.1.2016 21:26, Eamonn McManus wrote: > >> I think this test should either be deleted or reduced to a simple check >> that the MBeanServerDelegate's ImplementationVersion attribute is equal >> to System.getProperty("java.runtime.version"). The whole business of >> starting up a separate process and checking things with security >> managers and so on is completely obsolete. >> > > I would leave this for SQE to decide. Removing the security manager part > would change the semantics of the test. > > I would suggest dealing with this in a separate issue not to block the > effort of removing references to 'sun.boot.class.path' for jigsaw. > > -JB- > > >> ?amonn >> >> 2016-01-04 2:20 GMT-08:00 Jaroslav Bachorik >> >: >> >> Please, review the following simple change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 >> >> The patch removes the special path taken when jmxrmi.jar is present >> on the bootclasspath. There are two reasons for this cleanup: >> 1. Bootclasspath will not be available (or meaningful) in Jigsaw >> 2. We haven't been testing with an external jmxrmi.jar for ages - >> since JMX was included into JDK in JDK 5. >> >> The modified test is still passing. >> >> -JB- >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Wed Jan 6 10:21:49 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 6 Jan 2016 11:21:49 +0100 Subject: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials Message-ID: <568CEABD.8000603@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 On AArch64 machines running multiple test rounds involving SSL connections in rapid succession leads to error during SSL handshake. The fix is attempting to workaround this by inserting an arbitrary delay between the test rounds on AArch64 platform. The fix has been verified and makes the test pass reliably. Thanks, -JB- From jaroslav.bachorik at oracle.com Wed Jan 6 11:00:30 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 6 Jan 2016 12:00:30 +0100 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> Message-ID: <568CF3CE.6010806@oracle.com> On 5.1.2016 16:47, Eamonn McManus wrote: > OK. In that case I would suggest removing the checkVersion variable > since it is now always true, along with the logic from > ImplVersionCommand for when it is false. Done. Also updated the test summary wording as suggested by Alan: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.01 -JB- > > ?amonn > > 2016-01-05 5:52 GMT-08:00 Jaroslav Bachorik > >: > > On 4.1.2016 21:26, Eamonn McManus wrote: > > I think this test should either be deleted or reduced to a > simple check > that the MBeanServerDelegate's ImplementationVersion attribute > is equal > to System.getProperty("java.runtime.version"). The whole business of > starting up a separate process and checking things with security > managers and so on is completely obsolete. > > > I would leave this for SQE to decide. Removing the security manager > part would change the semantics of the test. > > I would suggest dealing with this in a separate issue not to block > the effort of removing references to 'sun.boot.class.path' for jigsaw. > > -JB- > > > ?amonn > > 2016-01-04 2:20 GMT-08:00 Jaroslav Bachorik > > >>: > > Please, review the following simple change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8143047 > Webrev: http://cr.openjdk.java.net/~jbachorik/8143047/webrev.00 > > The patch removes the special path taken when jmxrmi.jar is > present > on the bootclasspath. There are two reasons for this cleanup: > 1. Bootclasspath will not be available (or meaningful) in > Jigsaw > 2. We haven't been testing with an external jmxrmi.jar for > ages - > since JMX was included into JDK in JDK 5. > > The modified test is still passing. > > -JB- > > > > From david.holmes at oracle.com Wed Jan 6 11:19:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Jan 2016 21:19:24 +1000 Subject: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials In-Reply-To: <568CEABD.8000603@oracle.com> References: <568CEABD.8000603@oracle.com> Message-ID: <568CF83C.7050804@oracle.com> On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 > Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 > > On AArch64 machines running multiple test rounds involving SSL > connections in rapid succession leads to error during SSL handshake. I can't see how this could be CPU specific. This is more likely an OS issue or an issue with the network hardware/environment of the test machines. David > The fix is attempting to workaround this by inserting an arbitrary delay > between the test rounds on AArch64 platform. The fix has been verified > and makes the test pass reliably. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Wed Jan 6 11:23:31 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 6 Jan 2016 12:23:31 +0100 Subject: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials In-Reply-To: <568CF83C.7050804@oracle.com> References: <568CEABD.8000603@oracle.com> <568CF83C.7050804@oracle.com> Message-ID: <568CF933.8000508@oracle.com> On 6.1.2016 12:19, David Holmes wrote: > On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 >> >> On AArch64 machines running multiple test rounds involving SSL >> connections in rapid succession leads to error during SSL handshake. > > I can't see how this could be CPU specific. This is more likely an OS > issue or an issue with the network hardware/environment of the test > machines. Test is failing on AArch64 linux - various machines. I did more than 20 runs on the test infrastructure and the test is consistently failing on AArch64, no matter which machine takes up the job. I don't have a separate standalone AArch64 hardware to cross-check. Therefore I went down the path of the most obvious solution ... -JB- > > David > >> The fix is attempting to workaround this by inserting an arbitrary delay >> between the test rounds on AArch64 platform. The fix has been verified >> and makes the test pass reliably. >> >> Thanks, >> >> -JB- From Alan.Bateman at oracle.com Wed Jan 6 15:04:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Jan 2016 15:04:11 +0000 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568CF3CE.6010806@oracle.com> References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> <568CF3CE.6010806@oracle.com> Message-ID: <568D2CEB.7010906@oracle.com> On 06/01/2016 11:00, Jaroslav Bachorik wrote: > On 5.1.2016 16:47, Eamonn McManus wrote: >> OK. In that case I would suggest removing the checkVersion variable >> since it is now always true, along with the logic from >> ImplVersionCommand for when it is false. > > Done. Also updated the test summary wording as suggested by Alan: > http://cr.openjdk.java.net/~jbachorik/8143047/webrev.01 @summary looks okay now - thanks! -Alan From eamonn at mcmanus.net Wed Jan 6 15:18:56 2016 From: eamonn at mcmanus.net (Eamonn McManus) Date: Wed, 6 Jan 2016 07:18:56 -0800 Subject: jmx-dev RFR 8143047: Re-examine javax/management/ImplementationVersion/ImplVersionTest.java In-Reply-To: <568D2CEB.7010906@oracle.com> References: <568A476C.6060101@oracle.com> <568BCA84.2030401@oracle.com> <568CF3CE.6010806@oracle.com> <568D2CEB.7010906@oracle.com> Message-ID: Looks good to me (emcmanus) too. ?amonn 2016-01-06 7:04 GMT-08:00 Alan Bateman : > > > On 06/01/2016 11:00, Jaroslav Bachorik wrote: > >> On 5.1.2016 16:47, Eamonn McManus wrote: >> >>> OK. In that case I would suggest removing the checkVersion variable >>> since it is now always true, along with the logic from >>> ImplVersionCommand for when it is false. >>> >> >> Done. Also updated the test summary wording as suggested by Alan: >> http://cr.openjdk.java.net/~jbachorik/8143047/webrev.01 >> > @summary looks okay now - thanks! > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Thu Jan 7 15:02:45 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 7 Jan 2016 16:02:45 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <568BD39E.20305@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> Message-ID: <568E7E15.5020004@oracle.com> On 5.1.2016 15:30, Jaroslav Bachorik wrote: > On 4.1.2016 10:05, Jaroslav Bachorik wrote: >> Gentle reminder ... >> >> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>> >>> The test fails for IPv6 addresses since the RMI expects an IPv6 address >>> to be properly wrapped in '[]'. In addition to that the logic for >>> selecting IP addresses to bind is flawed - it does not check for IP >>> addresses of multiple adapters but for multiple IP addresses assigned to >>> 'localhost'. In combination with IPv4 & IPv6 this will cause the test to >>> attempt binding to IPv4 and IPv6 address of the same adapter >>> simultaneously and the test will fail. >>> >>> The fix adds the requested wrapping for IPv6 addresses and adjusts the >>> IP selection logic to iterate over distinct adapters first and prevent >>> IPv4 and IPv6 address of the same adapter being treated as two addresses >>> (for the purposes of the test). >>> >>> Thanks, >>> >>> -JB- >> > From daniel.fuchs at oracle.com Thu Jan 7 16:32:08 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 7 Jan 2016 17:32:08 +0100 Subject: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials In-Reply-To: <568CF933.8000508@oracle.com> References: <568CEABD.8000603@oracle.com> <568CF83C.7050804@oracle.com> <568CF933.8000508@oracle.com> Message-ID: <568E9308.2040706@oracle.com> On 06/01/16 12:23, Jaroslav Bachorik wrote: > On 6.1.2016 12:19, David Holmes wrote: >> On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 >>> >>> On AArch64 machines running multiple test rounds involving SSL >>> connections in rapid succession leads to error during SSL handshake. >> >> I can't see how this could be CPU specific. This is more likely an OS >> issue or an issue with the network hardware/environment of the test >> machines. > > Test is failing on AArch64 linux - various machines. I did more than 20 > runs on the test infrastructure and the test is consistently failing on > AArch64, no matter which machine takes up the job. I don't have a > separate standalone AArch64 hardware to cross-check. Therefore I went > down the path of the most obvious solution ... Looks good to me. RmiSslBootstrapTest.sh: Is jdk.testlibrary.* and /jdk/testlibrary still needed? It seems the test now only uses jdk.test.lib (unless jdk.testlibrary has classes in the unnamed package?) cheers, -- daniel > > -JB- > >> >> David >> >>> The fix is attempting to workaround this by inserting an arbitrary delay >>> between the test rounds on AArch64 platform. The fix has been verified >>> and makes the test pass reliably. >>> >>> Thanks, >>> >>> -JB- > From daniel.fuchs at oracle.com Thu Jan 7 16:40:29 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 7 Jan 2016 17:40:29 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <568E7E15.5020004@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> Message-ID: <568E94FD.6000206@oracle.com> Hi, This looks OK to me. I'm not sure I understand the full impact of the changes in getAddressesForLocalHost() though - so hopefully someone else will jump in to review that part... best regards, -- daniel On 07/01/16 16:02, Jaroslav Bachorik wrote: > On 5.1.2016 15:30, Jaroslav Bachorik wrote: >> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>> Gentle reminder ... >>> >>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>> >>>> The test fails for IPv6 addresses since the RMI expects an IPv6 address >>>> to be properly wrapped in '[]'. In addition to that the logic for >>>> selecting IP addresses to bind is flawed - it does not check for IP >>>> addresses of multiple adapters but for multiple IP addresses >>>> assigned to >>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>> test to >>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>> simultaneously and the test will fail. >>>> >>>> The fix adds the requested wrapping for IPv6 addresses and adjusts the >>>> IP selection logic to iterate over distinct adapters first and prevent >>>> IPv4 and IPv6 address of the same adapter being treated as two >>>> addresses >>>> (for the purposes of the test). >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Fri Jan 8 09:56:29 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 8 Jan 2016 10:56:29 +0100 Subject: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials In-Reply-To: <568E9308.2040706@oracle.com> References: <568CEABD.8000603@oracle.com> <568CF83C.7050804@oracle.com> <568CF933.8000508@oracle.com> <568E9308.2040706@oracle.com> Message-ID: <568F87CD.4050208@oracle.com> On 7.1.2016 17:32, Daniel Fuchs wrote: > On 06/01/16 12:23, Jaroslav Bachorik wrote: >> On 6.1.2016 12:19, David Holmes wrote: >>> On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 >>>> >>>> On AArch64 machines running multiple test rounds involving SSL >>>> connections in rapid succession leads to error during SSL handshake. >>> >>> I can't see how this could be CPU specific. This is more likely an OS >>> issue or an issue with the network hardware/environment of the test >>> machines. >> >> Test is failing on AArch64 linux - various machines. I did more than 20 >> runs on the test infrastructure and the test is consistently failing on >> AArch64, no matter which machine takes up the job. I don't have a >> separate standalone AArch64 hardware to cross-check. Therefore I went >> down the path of the most obvious solution ... > > Looks good to me. > > RmiSslBootstrapTest.sh: > > Is jdk.testlibrary.* and /jdk/testlibrary still needed? It seems the > test now only uses jdk.test.lib (unless jdk.testlibrary has classes > in the unnamed package?) Correct, thanks. We can remove reference to the jdk specific test library. Updated webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.01 -JB- > > cheers, > > -- daniel > >> >> -JB- >> >>> >>> David >>> >>>> The fix is attempting to workaround this by inserting an arbitrary >>>> delay >>>> between the test rounds on AArch64 platform. The fix has been verified >>>> and makes the test pass reliably. >>>> >>>> Thanks, >>>> >>>> -JB- >> > From daniel.fuchs at oracle.com Fri Jan 8 10:54:24 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 8 Jan 2016 11:54:24 +0100 Subject: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials In-Reply-To: <568F87CD.4050208@oracle.com> References: <568CEABD.8000603@oracle.com> <568CF83C.7050804@oracle.com> <568CF933.8000508@oracle.com> <568E9308.2040706@oracle.com> <568F87CD.4050208@oracle.com> Message-ID: <568F9560.10606@oracle.com> On 08/01/16 10:56, Jaroslav Bachorik wrote: > On 7.1.2016 17:32, Daniel Fuchs wrote: >> On 06/01/16 12:23, Jaroslav Bachorik wrote: >>> On 6.1.2016 12:19, David Holmes wrote: >>>> On 6/01/2016 8:21 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.00 >>>>> >>>>> On AArch64 machines running multiple test rounds involving SSL >>>>> connections in rapid succession leads to error during SSL handshake. >>>> >>>> I can't see how this could be CPU specific. This is more likely an OS >>>> issue or an issue with the network hardware/environment of the test >>>> machines. >>> >>> Test is failing on AArch64 linux - various machines. I did more than 20 >>> runs on the test infrastructure and the test is consistently failing on >>> AArch64, no matter which machine takes up the job. I don't have a >>> separate standalone AArch64 hardware to cross-check. Therefore I went >>> down the path of the most obvious solution ... >> >> Looks good to me. >> >> RmiSslBootstrapTest.sh: >> >> Is jdk.testlibrary.* and /jdk/testlibrary still needed? It seems the >> test now only uses jdk.test.lib (unless jdk.testlibrary has classes >> in the unnamed package?) > > Correct, thanks. We can remove reference to the jdk specific test library. > > Updated webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.01 Looks good. -- daniel > > -JB- > >> >> cheers, >> >> -- daniel >> >>> >>> -JB- >>> >>>> >>>> David >>>> >>>>> The fix is attempting to workaround this by inserting an arbitrary >>>>> delay >>>>> between the test rounds on AArch64 platform. The fix has been verified >>>>> and makes the test pass reliably. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Mon Jan 11 09:21:21 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 11 Jan 2016 10:21:21 +0100 Subject: jmx-dev JDK-8031753 : Review request In-Reply-To: <568F84E3.2040602@oracle.com> References: <568F84E3.2040602@oracle.com> Message-ID: <56937411.5080208@oracle.com> [adding JMX dev list] On 8.1.2016 10:44, Harsha Wardhana B wrote: > Hi All, > > Please review the fix for, > > Issue : JDK-8031753 - JMXServiceURL should not use > getLocalHost or its usage should be enhanced > Webrev : > http://cr.openjdk.java.net/~jbachorik/sponsorship/8031753/webrev.00/ > > The issue can be reproduced by removing entry for hostname in /etc/hosts > (for linux) and running > 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' test. > Hence no new jtreg test case have been written. > > Fix Description: > > If JMXServiceURL is given null host, it tries to resolve hostname via > InetAddress.getLocalHost() and if that fails throws > MalformedURLException. Since JMX Agent will listen on all interfaces > (0.0.0.0) if host is null, the fix handles the exception and assigns > first active non-loopback interface IP address to host. That way we can > have JMXServiceURL with IP address instead of hostname. > > It is possible that we might end up constructing JMXServiceURL with IP > for an interface which clients may not be able to connect (because of > network reachability issues). In that case, the recommendation would be > to try to start JMX Agent with > com.sun.management.jmxremote.host=xx.xx.xx.xx option. That way, the > agent will be started on interface that clients can actually connect to. > > Please review the fix and let me know your comments. The fix requires > amending javadoc with above behavioral change and a CCC review as well > which I will send out later. > > Thanks > Harsha > From serguei.spitsyn at oracle.com Tue Jan 12 10:47:32 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Jan 2016 02:47:32 -0800 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <568E94FD.6000206@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> Message-ID: <5694D9C4.1030901@oracle.com> On 1/7/16 08:40, Daniel Fuchs wrote: > Hi, > > This looks OK to me. > I'm not sure I understand the full impact of the changes > in getAddressesForLocalHost() though - so hopefully someone > else will jump in to review that part... Hi Jaroslav, I do not understand the full impact of the getAddressesForLocalHost() change either so that, please, do not count me as a reviewer. However, I have a question on the fragment: + private static boolean isLocalhost(InetAddress i) { + if (!i.isLoopbackAddress()) { + return i.getHostName().toLowerCase().equals("localhost"); + } + return false; } Should true be returned instead of false if the i.isLoopbackAddress() returns true? Do we normally treat the loopbackAddress case as a localhost variant? Thanks, Serguei > > best regards, > > -- daniel > > On 07/01/16 16:02, Jaroslav Bachorik wrote: >> On 5.1.2016 15:30, Jaroslav Bachorik wrote: >>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>>> Gentle reminder ... >>>> >>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>>> >>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 >>>>> address >>>>> to be properly wrapped in '[]'. In addition to that the logic for >>>>> selecting IP addresses to bind is flawed - it does not check for IP >>>>> addresses of multiple adapters but for multiple IP addresses >>>>> assigned to >>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>>> test to >>>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>>> simultaneously and the test will fail. >>>>> >>>>> The fix adds the requested wrapping for IPv6 addresses and adjusts >>>>> the >>>>> IP selection logic to iterate over distinct adapters first and >>>>> prevent >>>>> IPv4 and IPv6 address of the same adapter being treated as two >>>>> addresses >>>>> (for the purposes of the test). >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Jan 12 11:49:08 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 12 Jan 2016 12:49:08 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <5694D9C4.1030901@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> Message-ID: <5694E834.9020502@oracle.com> On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: > On 1/7/16 08:40, Daniel Fuchs wrote: >> Hi, >> >> This looks OK to me. >> I'm not sure I understand the full impact of the changes >> in getAddressesForLocalHost() though - so hopefully someone >> else will jump in to review that part... > > Hi Jaroslav, > > I do not understand the full impact of the getAddressesForLocalHost() > change either > so that, please, do not count me as a reviewer. Looks like > > However, I have a question on the fragment: > > + private static boolean isLocalhost(InetAddress i) { > + if (!i.isLoopbackAddress()) { > + return i.getHostName().toLowerCase().equals("localhost"); > + } > + return false; > } > > > Should true be returned instead of false if the i.isLoopbackAddress() > returns true? > Do we normally treat the loopbackAddress case as a localhost variant? Ok, maybe the method name is missing a bit - the idea is to get all 'true' localhosts - a localhost defined on a real non-loopback adapter (as it doesn't make sense to bind JMX remote connector to a loopback address). I just couldn't come up with more describing name not being excessively long :( I'm open to any suggestions. -JB- > > Thanks, > Serguei > > >> >> best regards, >> >> -- daniel >> >> On 07/01/16 16:02, Jaroslav Bachorik wrote: >>> On 5.1.2016 15:30, Jaroslav Bachorik wrote: >>>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>>>> Gentle reminder ... >>>>> >>>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>>>> Please, review the following test change >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>>>> >>>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 >>>>>> address >>>>>> to be properly wrapped in '[]'. In addition to that the logic for >>>>>> selecting IP addresses to bind is flawed - it does not check for IP >>>>>> addresses of multiple adapters but for multiple IP addresses >>>>>> assigned to >>>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>>>> test to >>>>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>>>> simultaneously and the test will fail. >>>>>> >>>>>> The fix adds the requested wrapping for IPv6 addresses and adjusts >>>>>> the >>>>>> IP selection logic to iterate over distinct adapters first and >>>>>> prevent >>>>>> IPv4 and IPv6 address of the same adapter being treated as two >>>>>> addresses >>>>>> (for the purposes of the test). >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Tue Jan 12 11:55:57 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Jan 2016 03:55:57 -0800 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <5694E834.9020502@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> Message-ID: <5694E9CD.9040409@oracle.com> On 1/12/16 03:49, Jaroslav Bachorik wrote: > On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: >> On 1/7/16 08:40, Daniel Fuchs wrote: >>> Hi, >>> >>> This looks OK to me. >>> I'm not sure I understand the full impact of the changes >>> in getAddressesForLocalHost() though - so hopefully someone >>> else will jump in to review that part... >> >> Hi Jaroslav, >> >> I do not understand the full impact of the getAddressesForLocalHost() >> change either >> so that, please, do not count me as a reviewer. > > Looks like > >> >> However, I have a question on the fragment: >> >> + private static boolean isLocalhost(InetAddress i) { >> + if (!i.isLoopbackAddress()) { >> + return i.getHostName().toLowerCase().equals("localhost"); >> + } >> + return false; >> } >> >> >> Should true be returned instead of false if the i.isLoopbackAddress() >> returns true? >> Do we normally treat the loopbackAddress case as a localhost variant? > > Ok, maybe the method name is missing a bit - the idea is to get all > 'true' localhosts - a localhost defined on a real non-loopback adapter > (as it doesn't make sense to bind JMX remote connector to a loopback > address). Got it. Thank you for the explanation. > > I just couldn't come up with more describing name not being > excessively long :( I'm open to any suggestions. The name looks Ok to me. I'd suggest to add a short comment with your explanation above. Thanks, Serguei > > -JB- > >> >> Thanks, >> Serguei >> >> >>> >>> best regards, >>> >>> -- daniel >>> >>> On 07/01/16 16:02, Jaroslav Bachorik wrote: >>>> On 5.1.2016 15:30, Jaroslav Bachorik wrote: >>>>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>>>>> Gentle reminder ... >>>>>> >>>>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>>>>> Please, review the following test change >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>>>>> >>>>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 >>>>>>> address >>>>>>> to be properly wrapped in '[]'. In addition to that the logic for >>>>>>> selecting IP addresses to bind is flawed - it does not check for IP >>>>>>> addresses of multiple adapters but for multiple IP addresses >>>>>>> assigned to >>>>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>>>>> test to >>>>>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>>>>> simultaneously and the test will fail. >>>>>>> >>>>>>> The fix adds the requested wrapping for IPv6 addresses and adjusts >>>>>>> the >>>>>>> IP selection logic to iterate over distinct adapters first and >>>>>>> prevent >>>>>>> IPv4 and IPv6 address of the same adapter being treated as two >>>>>>> addresses >>>>>>> (for the purposes of the test). >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Wed Jan 13 11:16:21 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 13 Jan 2016 12:16:21 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <5694E9CD.9040409@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> Message-ID: <56963205.5000505@oracle.com> On 12.1.2016 12:55, serguei.spitsyn at oracle.com wrote: > On 1/12/16 03:49, Jaroslav Bachorik wrote: >> On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: >>> On 1/7/16 08:40, Daniel Fuchs wrote: >>>> Hi, >>>> >>>> This looks OK to me. >>>> I'm not sure I understand the full impact of the changes >>>> in getAddressesForLocalHost() though - so hopefully someone >>>> else will jump in to review that part... >>> >>> Hi Jaroslav, >>> >>> I do not understand the full impact of the getAddressesForLocalHost() >>> change either >>> so that, please, do not count me as a reviewer. >> >> Looks like >> >>> >>> However, I have a question on the fragment: >>> >>> + private static boolean isLocalhost(InetAddress i) { >>> + if (!i.isLoopbackAddress()) { >>> + return i.getHostName().toLowerCase().equals("localhost"); >>> + } >>> + return false; >>> } >>> >>> >>> Should true be returned instead of false if the i.isLoopbackAddress() >>> returns true? >>> Do we normally treat the loopbackAddress case as a localhost variant? >> >> Ok, maybe the method name is missing a bit - the idea is to get all >> 'true' localhosts - a localhost defined on a real non-loopback adapter >> (as it doesn't make sense to bind JMX remote connector to a loopback >> address). > > Got it. > Thank you for the explanation. > > >> >> I just couldn't come up with more describing name not being >> excessively long :( I'm open to any suggestions. > > The name looks Ok to me. > I'd suggest to add a short comment with your explanation above. Thanks. I've added the explanation and also disambiguated the method name a bit. http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 It looks like no one else is going to jump in and verify the getAddressesForLocalHost() change (basically, excluding the loopback localhost addresses as they are not suitable for binding the remote JMX connector to) :/ Maybe Severing could comment, as the orignal author? I would like to integrate this change ASAP since the test is failing 100% in nightly runs. -JB- > > > Thanks, > Serguei > > >> >> -JB- >> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 07/01/16 16:02, Jaroslav Bachorik wrote: >>>>> On 5.1.2016 15:30, Jaroslav Bachorik wrote: >>>>>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>>>>>> Gentle reminder ... >>>>>>> >>>>>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>>>>>> Please, review the following test change >>>>>>>> >>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>>>>>> >>>>>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 >>>>>>>> address >>>>>>>> to be properly wrapped in '[]'. In addition to that the logic for >>>>>>>> selecting IP addresses to bind is flawed - it does not check for IP >>>>>>>> addresses of multiple adapters but for multiple IP addresses >>>>>>>> assigned to >>>>>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>>>>>> test to >>>>>>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>>>>>> simultaneously and the test will fail. >>>>>>>> >>>>>>>> The fix adds the requested wrapping for IPv6 addresses and adjusts >>>>>>>> the >>>>>>>> IP selection logic to iterate over distinct adapters first and >>>>>>>> prevent >>>>>>>> IPv4 and IPv6 address of the same adapter being treated as two >>>>>>>> addresses >>>>>>>> (for the purposes of the test). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>>> >>>>>> >>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Wed Jan 13 12:00:22 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Jan 2016 13:00:22 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <56963205.5000505@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> Message-ID: <56963C56.9090209@oracle.com> On 13/01/16 12:16, Jaroslav Bachorik wrote: > Thanks. I've added the explanation and also disambiguated the method > name a bit. > > http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 > > It looks like no one else is going to jump in and verify the > getAddressesForLocalHost() change (basically, excluding the loopback > localhost addresses as they are not suitable for binding the remote JMX > connector to) :/ Maybe Severing could comment, as the orignal author? > > I would like to integrate this change ASAP since the test is failing > 100% in nightly runs. > Looks to me Jaroslav :-) -- daniel From jaroslav.bachorik at oracle.com Wed Jan 13 12:13:21 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 13 Jan 2016 13:13:21 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <56963C56.9090209@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> <56963C56.9090209@oracle.com> Message-ID: <56963F61.2040508@oracle.com> On 13.1.2016 13:00, Daniel Fuchs wrote: > On 13/01/16 12:16, Jaroslav Bachorik wrote: >> Thanks. I've added the explanation and also disambiguated the method >> name a bit. >> >> http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 >> >> It looks like no one else is going to jump in and verify the >> getAddressesForLocalHost() change (basically, excluding the loopback >> localhost addresses as they are not suitable for binding the remote JMX >> connector to) :/ Maybe Severing could comment, as the orignal author? >> >> I would like to integrate this change ASAP since the test is failing >> 100% in nightly runs. >> > > Looks to me Jaroslav :-) Thanks :) It's nice that this kind of change is named after me ;) -JB- > > -- daniel From serguei.spitsyn at oracle.com Wed Jan 13 18:51:07 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Jan 2016 10:51:07 -0800 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <56963205.5000505@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> Message-ID: <56969C9B.1080104@oracle.com> On 1/13/16 03:16, Jaroslav Bachorik wrote: > On 12.1.2016 12:55, serguei.spitsyn at oracle.com wrote: >> On 1/12/16 03:49, Jaroslav Bachorik wrote: >>> On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: >>>> On 1/7/16 08:40, Daniel Fuchs wrote: >>>>> Hi, >>>>> >>>>> This looks OK to me. >>>>> I'm not sure I understand the full impact of the changes >>>>> in getAddressesForLocalHost() though - so hopefully someone >>>>> else will jump in to review that part... >>>> >>>> Hi Jaroslav, >>>> >>>> I do not understand the full impact of the getAddressesForLocalHost() >>>> change either >>>> so that, please, do not count me as a reviewer. >>> >>> Looks like >>> >>>> >>>> However, I have a question on the fragment: >>>> >>>> + private static boolean isLocalhost(InetAddress i) { >>>> + if (!i.isLoopbackAddress()) { >>>> + return i.getHostName().toLowerCase().equals("localhost"); >>>> + } >>>> + return false; >>>> } >>>> >>>> >>>> Should true be returned instead of false if the i.isLoopbackAddress() >>>> returns true? >>>> Do we normally treat the loopbackAddress case as a localhost variant? >>> >>> Ok, maybe the method name is missing a bit - the idea is to get all >>> 'true' localhosts - a localhost defined on a real non-loopback adapter >>> (as it doesn't make sense to bind JMX remote connector to a loopback >>> address). >> >> Got it. >> Thank you for the explanation. >> >> >>> >>> I just couldn't come up with more describing name not being >>> excessively long :( I'm open to any suggestions. >> >> The name looks Ok to me. >> I'd suggest to add a short comment with your explanation above. > > Thanks. I've added the explanation and also disambiguated the method > name a bit. > > http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 > > It looks like no one else is going to jump in and verify the > getAddressesForLocalHost() change (basically, excluding the loopback > localhost addresses as they are not suitable for binding the remote > JMX connector to) :/ Maybe Severing could comment, as the orignal author? > > I would like to integrate this change ASAP since the test is failing > 100% in nightly runs. Ok. I looked to the getAddressesForLocalHost() part and think this fix is fine. Thumbs up from me. Thanks, Serguei > > -JB- > >> >> >> Thanks, >> Serguei >> >> >>> >>> -JB- >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 07/01/16 16:02, Jaroslav Bachorik wrote: >>>>>> On 5.1.2016 15:30, Jaroslav Bachorik wrote: >>>>>>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: >>>>>>>> Gentle reminder ... >>>>>>>> >>>>>>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: >>>>>>>>> Please, review the following test change >>>>>>>>> >>>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 >>>>>>>>> >>>>>>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 >>>>>>>>> address >>>>>>>>> to be properly wrapped in '[]'. In addition to that the logic for >>>>>>>>> selecting IP addresses to bind is flawed - it does not check >>>>>>>>> for IP >>>>>>>>> addresses of multiple adapters but for multiple IP addresses >>>>>>>>> assigned to >>>>>>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the >>>>>>>>> test to >>>>>>>>> attempt binding to IPv4 and IPv6 address of the same adapter >>>>>>>>> simultaneously and the test will fail. >>>>>>>>> >>>>>>>>> The fix adds the requested wrapping for IPv6 addresses and >>>>>>>>> adjusts >>>>>>>>> the >>>>>>>>> IP selection logic to iterate over distinct adapters first and >>>>>>>>> prevent >>>>>>>>> IPv4 and IPv6 address of the same adapter being treated as two >>>>>>>>> addresses >>>>>>>>> (for the purposes of the test). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sgehwolf at redhat.com Thu Jan 14 16:23:07 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Jan 2016 17:23:07 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <56969C9B.1080104@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> <56969C9B.1080104@oracle.com> Message-ID: <1452788587.3685.29.camel@redhat.com> Hi, On Wed, 2016-01-13 at 10:51 -0800, serguei.spitsyn at oracle.com wrote: > On 1/13/16 03:16, Jaroslav Bachorik wrote: > > On 12.1.2016 12:55, serguei.spitsyn at oracle.com wrote: > > > On 1/12/16 03:49, Jaroslav Bachorik wrote: > > > > On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: > > > > > On 1/7/16 08:40, Daniel Fuchs wrote: > > > > > > Hi, > > > > > > > > > > > > This looks OK to me. > > > > > > I'm not sure I understand the full impact of the changes > > > > > > in getAddressesForLocalHost() though - so hopefully someone > > > > > > else will jump in to review that part... > > > > > > > > > > Hi Jaroslav, > > > > > > > > > > I do not understand the full impact of the getAddressesForLocalHost() > > > > > change either > > > > > so that, please, do not count me as a reviewer. > > > > > > > > Looks like > > > > > > > > > > > > > > However, I have a question on the fragment: > > > > > > > > > > + private static boolean isLocalhost(InetAddress i) { > > > > > + if (!i.isLoopbackAddress()) { > > > > > + return i.getHostName().toLowerCase().equals("localhost"); > > > > > + } > > > > > + return false; > > > > > ??????} > > > > > > > > > > > > > > > Should true be returned instead of false if the i.isLoopbackAddress() > > > > > returns true? > > > > > Do we normally treat the loopbackAddress case as a localhost variant? > > > > > > > > Ok, maybe the method name is missing a bit - the idea is to get all > > > > 'true' localhosts - a localhost defined on a real non-loopback adapter > > > > (as it doesn't make sense to bind JMX remote connector to a loopback > > > > address). > > > > > > Got it. > > > Thank you for the explanation. > > > > > > > > > > > > > > I just couldn't come up with more describing name not being > > > > excessively long :( I'm open to any suggestions. > > > > > > The name looks Ok to me. > > > I'd suggest to add a short comment with your explanation above. > > > > Thanks. I've added the explanation and also disambiguated the method? > > name a bit. > > > > http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 > > > > It looks like no one else is going to jump in and verify the? > > getAddressesForLocalHost() change (basically, excluding the loopback? > > localhost addresses as they are not suitable for binding the remote? > > JMX connector to) :/ Maybe Severing could comment, as the orignal author? Sorry for being late in the game with this.? +????private static List getAddressesForLocalHost() { + ?????????try { -????????????addrs = InetAddress.getAllByName("localhost"); -????????} catch (UnknownHostException e) { +????????????return NetworkInterface.networkInterfaces() +????????????????.flatMap(NetworkInterface::inetAddresses) +????????????????.filter(JMXInterfaceBindingTest::isNonloopbackLocalhost) +????????????????.collect(Collectors.toList()); I wonder if this does what you claim it does. It looks like it's getting all the addresses per adapter (IPv4 or IPv6) and then filters addresses out which have "localhost" as name and aren't loopback. It's not really what you said it does: """" The fix adds the requested wrapping for IPv6 addresses and adjusts the? IP selection logic to iterate over distinct adapters first and prevent? IPv4 and IPv6 address of the same adapter being treated as two addresses """" How is it preventing IPv4 and IPv6 addresses *both* being used for one adapter? Could it be that this fix works because loopback was the only one with IPv4 and IPv6 address config on the test server? Say one has the following /etc/hosts config: 192.168.1.14 ? ? ? ? ? ? ?localhost fe80::56ee:75ff:fe35:d1d4 localhost with the following adapter info (from ifconfig): enp0s25: flags=4163??mtu 1500 ????????inet 192.168.1.14??netmask 255.255.255.0??broadcast 192.168.1.255 ????????inet6 fe80::56ee:75ff:fe35:d1d4 I.e. for adapter enp0s25 I specify the IP addresses 192.168.1.14 and fe80::56ee:75ff:fe35:d1d4 to be "localhost". I'd expect the test to still fail after this patch. +????// we need 'real' localhost addresses only (eg. not loopback ones) +????// so we can bind the remote JMX connector to them +????private static boolean isNonloopbackLocalhost(InetAddress i) { +????????if (!i.isLoopbackAddress()) { +????????????return i.getHostName().toLowerCase().equals("localhost"); +????????} +????????return false; TBH, I don't understand why this comment is there. Particularly, the loopback exclusion. Yet, this may be platform specific. It worked for me under linux. It was fine with binding to IPv4 loopback (127.0.0.1) and some interface address (e.g. 192.168.1.x). Looking at the bug it seems the main issue was a conflict of binding to IPv4 loopback + IPv6 loopback. So the gist would be to not use both IPv4 *and* IPv6 addresses of the same adapter for the binding. How about using something like this for a filter: private static boolean isIpV4Address(InetAddress i) { ? ?return i instanceof Inet4Address; } Thoughts? Anyway, looks like it's too late now :-/ Cheers, Severin > > I would like to integrate this change ASAP since the test is failing? > > 100% in nightly runs. > > Ok. I looked??to the getAddressesForLocalHost() part and think this fix? > is fine. > Thumbs up from me. > > Thanks, > Serguei > > > > > -JB- > > > > > > > > > > > Thanks, > > > Serguei > > > > > > > > > > > > > > -JB- > > > > > > > > > > > > > > Thanks, > > > > > Serguei > > > > > > > > > > > > > > > > > > > > > > best regards, > > > > > > > > > > > > -- daniel > > > > > > > > > > > > On 07/01/16 16:02, Jaroslav Bachorik wrote: > > > > > > > On 5.1.2016 15:30, Jaroslav Bachorik wrote: > > > > > > > > On 4.1.2016 10:05, Jaroslav Bachorik wrote: > > > > > > > > > Gentle reminder ... > > > > > > > > > > > > > > > > > > On 23.12.2015 11:26, Jaroslav Bachorik wrote: > > > > > > > > > > Please, review the following test change > > > > > > > > > > > > > > > > > > > > Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 > > > > > > > > > > Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 > > > > > > > > > > > > > > > > > > > > The test fails for IPv6 addresses since the RMI expects an IPv6 > > > > > > > > > > address > > > > > > > > > > to be properly wrapped in '[]'. In addition to that the logic for > > > > > > > > > > selecting IP addresses to bind is flawed - it does not check? > > > > > > > > > > for IP > > > > > > > > > > addresses of multiple adapters but for multiple IP addresses > > > > > > > > > > assigned to > > > > > > > > > > 'localhost'. In combination with IPv4 & IPv6 this will cause the > > > > > > > > > > test to > > > > > > > > > > attempt binding to IPv4 and IPv6 address of the same adapter > > > > > > > > > > simultaneously and the test will fail. > > > > > > > > > > > > > > > > > > > > The fix adds the requested wrapping for IPv6 addresses and? > > > > > > > > > > adjusts > > > > > > > > > > the > > > > > > > > > > IP selection logic to iterate over distinct adapters first and > > > > > > > > > > prevent > > > > > > > > > > IPv4 and IPv6 address of the same adapter being treated as two > > > > > > > > > > addresses > > > > > > > > > > (for the purposes of the test). > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > -JB- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From jaroslav.bachorik at oracle.com Fri Jan 15 08:50:58 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 15 Jan 2016 09:50:58 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <1452788587.3685.29.camel@redhat.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> <56969C9B.1080104@oracle.com> <1452788587.3685.29.camel@redhat.com> Message-ID: <5698B2F2.5030602@oracle.com> On 14.1.2016 17:23, Severin Gehwolf wrote: > Hi, > > On Wed, 2016-01-13 at 10:51 -0800, serguei.spitsyn at oracle.com wrote: > > On 1/13/16 03:16, Jaroslav Bachorik wrote: > >> On 12.1.2016 12:55, serguei.spitsyn at oracle.com wrote: > >>> On 1/12/16 03:49, Jaroslav Bachorik wrote: > >>>> On 12.1.2016 11:47, serguei.spitsyn at oracle.com wrote: > >>>>> On 1/7/16 08:40, Daniel Fuchs wrote: > >>>>>> Hi, > >>>>>> > >>>>>> This looks OK to me. > >>>>>> I'm not sure I understand the full impact of the changes > >>>>>> in getAddressesForLocalHost() though - so hopefully someone > >>>>>> else will jump in to review that part... > >>>>> > >>>>> Hi Jaroslav, > >>>>> > >>>>> I do not understand the full impact of the getAddressesForLocalHost() > >>>>> change either > >>>>> so that, please, do not count me as a reviewer. > >>>> > >>>> Looks like > >>>> > >>>>> > >>>>> However, I have a question on the fragment: > >>>>> > >>>>> + private static boolean isLocalhost(InetAddress i) { > >>>>> + if (!i.isLoopbackAddress()) { > >>>>> + return i.getHostName().toLowerCase().equals("localhost"); > >>>>> + } > >>>>> + return false; > >>>>> } > >>>>> > >>>>> > >>>>> Should true be returned instead of false if the i.isLoopbackAddress() > >>>>> returns true? > >>>>> Do we normally treat the loopbackAddress case as a localhost variant? > >>>> > >>>> Ok, maybe the method name is missing a bit - the idea is to get all > >>>> 'true' localhosts - a localhost defined on a real non-loopback adapter > >>>> (as it doesn't make sense to bind JMX remote connector to a loopback > >>>> address). > >>> > >>> Got it. > >>> Thank you for the explanation. > >>> > >>> > >>>> > >>>> I just couldn't come up with more describing name not being > >>>> excessively long :( I'm open to any suggestions. > >>> > >>> The name looks Ok to me. > >>> I'd suggest to add a short comment with your explanation above. > >> > >> Thanks. I've added the explanation and also disambiguated the method > >> name a bit. > >> > >> http://cr.openjdk.java.net/~jbachorik/8146015/webrev.01 > >> > >> It looks like no one else is going to jump in and verify the > >> getAddressesForLocalHost() change (basically, excluding the loopback > >> localhost addresses as they are not suitable for binding the remote > >> JMX connector to) :/ Maybe Severing could comment, as the orignal author? > > Sorry for being late in the game with this. > > + private static List getAddressesForLocalHost() { > + > try { > - addrs = InetAddress.getAllByName("localhost"); > - } catch (UnknownHostException e) { > + return NetworkInterface.networkInterfaces() > + .flatMap(NetworkInterface::inetAddresses) > + .filter(JMXInterfaceBindingTest::isNonloopbackLocalhost) > + .collect(Collectors.toList()); > > I wonder if this does what you claim it does. It looks like it's > getting all the addresses per adapter (IPv4 or IPv6) and then filters > addresses out which have "localhost" as name and aren't loopback. It's > not really what you said it does: > > """" > The fix adds the requested wrapping for IPv6 addresses and adjusts the > IP selection logic to iterate over distinct adapters first and prevent > IPv4 and IPv6 address of the same adapter being treated as two > addresses > """" > > How is it preventing IPv4 and IPv6 addresses *both* being used for one > adapter? Could it be that this fix works because loopback was the only > one with IPv4 and IPv6 address config on the test server? > > Say one has the following /etc/hosts config: > 192.168.1.14 localhost > fe80::56ee:75ff:fe35:d1d4 localhost > > with the following adapter info (from ifconfig): > > enp0s25: flags=4163 mtu 1500 > inet 192.168.1.14 netmask 255.255.255.0 broadcast 192.168.1.255 > inet6 fe80::56ee:75ff:fe35:d1d4 > > I.e. for adapter enp0s25 I specify the IP addresses 192.168.1.14 and > fe80::56ee:75ff:fe35:d1d4 to be "localhost". I'd expect the test to > still fail after this patch. > > + // we need 'real' localhost addresses only (eg. not loopback ones) > + // so we can bind the remote JMX connector to them > + private static boolean isNonloopbackLocalhost(InetAddress i) { > + if (!i.isLoopbackAddress()) { > + return i.getHostName().toLowerCase().equals("localhost"); > + } > + return false; > > TBH, I don't understand why this comment is there. Particularly, the > loopback exclusion. Yet, this may be platform specific. It worked for > me under linux. It was fine with binding to IPv4 loopback (127.0.0.1) > and some interface address (e.g. 192.168.1.x). Looking at the bug it > seems the main issue was a conflict of binding to IPv4 loopback + IPv6 > loopback. You can have problems also with a configuration with several loopbacks. The test considers such a setup as a machine with multiple interfaces while it is, in fact, only one interface. Also, it does not really make any sense to test binding to a loopback address - we are starting a remote JMX connector and loopback address is not accessible from outside, anyway. > > So the gist would be to not use both IPv4 *and* IPv6 addresses of the > same adapter for the binding. How about using something like this for a > filter: > private static boolean isIpV4Address(InetAddress i) { > return i instanceof Inet4Address; > } > > Thoughts? > > Anyway, looks like it's too late now :-/ Yep. But feel free to open a new issue, with the reproducer description, and, hopefully a proposed patch :) I will sponsor the push happily. -JB- > > Cheers, > Severin > > >> I would like to integrate this change ASAP since the test is failing > >> 100% in nightly runs. > > > > Ok. I looked to the getAddressesForLocalHost() part and think this fix > > is fine. > > Thumbs up from me. > > > > Thanks, > > Serguei > > > >> > >> -JB- > >> > >>> > >>> > >>> Thanks, > >>> Serguei > >>> > >>> > >>>> > >>>> -JB- > >>>> > >>>>> > >>>>> Thanks, > >>>>> Serguei > >>>>> > >>>>> > >>>>>> > >>>>>> best regards, > >>>>>> > >>>>>> -- daniel > >>>>>> > >>>>>> On 07/01/16 16:02, Jaroslav Bachorik wrote: > >>>>>>> On 5.1.2016 15:30, Jaroslav Bachorik wrote: > >>>>>>>> On 4.1.2016 10:05, Jaroslav Bachorik wrote: > >>>>>>>>> Gentle reminder ... > >>>>>>>>> > >>>>>>>>> On 23.12.2015 11:26, Jaroslav Bachorik wrote: > >>>>>>>>>> Please, review the following test change > >>>>>>>>>> > >>>>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 > >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 > >>>>>>>>>> > >>>>>>>>>> The test fails for IPv6 addresses since the RMI expects an IPv6 > >>>>>>>>>> address > >>>>>>>>>> to be properly wrapped in '[]'. In addition to that the logic for > >>>>>>>>>> selecting IP addresses to bind is flawed - it does not check > >>>>>>>>>> for IP > >>>>>>>>>> addresses of multiple adapters but for multiple IP addresses > >>>>>>>>>> assigned to > >>>>>>>>>> 'localhost'. In combination with IPv4 & IPv6 this will cause the > >>>>>>>>>> test to > >>>>>>>>>> attempt binding to IPv4 and IPv6 address of the same adapter > >>>>>>>>>> simultaneously and the test will fail. > >>>>>>>>>> > >>>>>>>>>> The fix adds the requested wrapping for IPv6 addresses and > >>>>>>>>>> adjusts > >>>>>>>>>> the > >>>>>>>>>> IP selection logic to iterate over distinct adapters first and > >>>>>>>>>> prevent > >>>>>>>>>> IPv4 and IPv6 address of the same adapter being treated as two > >>>>>>>>>> addresses > >>>>>>>>>> (for the purposes of the test). > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> -JB- > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From sgehwolf at redhat.com Fri Jan 15 09:24:29 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Jan 2016 10:24:29 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <5698B2F2.5030602@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> <56969C9B.1080104@oracle.com> <1452788587.3685.29.camel@redhat.com> <5698B2F2.5030602@oracle.com> Message-ID: <1452849869.3564.11.camel@redhat.com> Hi, On Fri, 2016-01-15 at 09:50 +0100, Jaroslav Bachorik wrote: > > Sorry for being late in the game with this. > > > > +????private static List getAddressesForLocalHost() { > > + > > ??????????try { > > -????????????addrs = InetAddress.getAllByName("localhost"); > > -????????} catch (UnknownHostException e) { > > +????????????return NetworkInterface.networkInterfaces() > > +????????????????.flatMap(NetworkInterface::inetAddresses) > > +????????????????.filter(JMXInterfaceBindingTest::isNonloopbackLocalhost) > > +????????????????.collect(Collectors.toList()); > > > > I wonder if this does what you claim it does. It looks like it's > > getting all the addresses per adapter (IPv4 or IPv6) and then filters > > addresses out which have "localhost" as name and aren't loopback. It's > > not really what you said it does: > > > > """" > > The fix adds the requested wrapping for IPv6 addresses and adjusts the > > IP selection logic to iterate over distinct adapters first and prevent > > IPv4 and IPv6 address of the same adapter being treated as two > > addresses > > """" > > > > How is it preventing IPv4 and IPv6 addresses *both* being used for one > > adapter? Could it be that this fix works because loopback was the only > > one with IPv4 and IPv6 address config on the test server? > > > > Say one has the following /etc/hosts config: > > 192.168.1.14??????????????localhost > > fe80::56ee:75ff:fe35:d1d4 localhost > > > > with the following adapter info (from ifconfig): > > > > enp0s25: flags=4163??mtu 1500 > > ?????????inet 192.168.1.14??netmask 255.255.255.0??broadcast 192.168.1.255 > > ?????????inet6 fe80::56ee:75ff:fe35:d1d4 > > > > I.e. for adapter enp0s25 I specify the IP addresses 192.168.1.14 and > > fe80::56ee:75ff:fe35:d1d4 to be "localhost". I'd expect the test to > > still fail after this patch. > > > > +????// we need 'real' localhost addresses only (eg. not loopback ones) > > +????// so we can bind the remote JMX connector to them > > +????private static boolean isNonloopbackLocalhost(InetAddress i) { > > +????????if (!i.isLoopbackAddress()) { > > +????????????return i.getHostName().toLowerCase().equals("localhost"); > > +????????} > > +????????return false; > > > > TBH, I don't understand why this comment is there. Particularly, the > > loopback exclusion. Yet, this may be platform specific. It worked for > > me under linux. It was fine with binding to IPv4 loopback (127.0.0.1) > > and some interface address (e.g. 192.168.1.x). Looking at the bug it > > seems the main issue was a conflict of binding to IPv4 loopback + IPv6 > > loopback. > You can have problems also with a configuration with several > loopbacks. The test considers such a setup as a machine with multiple > interfaces while it is, in fact, only one interface. Right. For the purpose of the test it would still be acceptable to bind to loopback, no? One of the reasons why I'd think it would be useful is that it wouldn't require the test to be run on a machine with > 1 adapters/virtual adapters. > Also, it does not really make any?sense to test binding to a loopback > address - we are starting a remote JMX connector and loopback address > is not accessible from outside, anyway. Conceptually yes, but due to lack of configure options (AFAIK) for the local JMX agent it might still be useful. > > > > So the gist would be to not use both IPv4 *and* IPv6 addresses of the > > same adapter for the binding. How about using something like this for a > > filter: > > private static boolean isIpV4Address(InetAddress i) { > > ????return i instanceof Inet4Address; > > } > > > > Thoughts? > > > > Anyway, looks like it's too late now :-/ > > Yep. But feel free to open a new issue, with the reproducer > description, and, hopefully a proposed patch :) Sure, not a problem. I'll see what I can do. > I will sponsor the push happily. Thank you! Cheers, Severin From jaroslav.bachorik at oracle.com Fri Jan 15 09:28:05 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 15 Jan 2016 10:28:05 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <1452849869.3564.11.camel@redhat.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> <56969C9B.1080104@oracle.com> <1452788587.3685.29.camel@redhat.com> <5698B2F2.5030602@oracle.com> <1452849869.3564.11.camel@redhat.com> Message-ID: <5698BBA5.6020800@oracle.com> On 15.1.2016 10:24, Severin Gehwolf wrote: > Hi, > > On Fri, 2016-01-15 at 09:50 +0100, Jaroslav Bachorik wrote: >>> Sorry for being late in the game with this. >>> >>> + private static List getAddressesForLocalHost() { >>> + >>> try { >>> - addrs = InetAddress.getAllByName("localhost"); >>> - } catch (UnknownHostException e) { >>> + return NetworkInterface.networkInterfaces() >>> + .flatMap(NetworkInterface::inetAddresses) >>> + .filter(JMXInterfaceBindingTest::isNonloopbackLocalhost) >>> + .collect(Collectors.toList()); >>> >>> I wonder if this does what you claim it does. It looks like it's >>> getting all the addresses per adapter (IPv4 or IPv6) and then filters >>> addresses out which have "localhost" as name and aren't loopback. It's >>> not really what you said it does: >>> >>> """" >>> The fix adds the requested wrapping for IPv6 addresses and adjusts the >>> IP selection logic to iterate over distinct adapters first and prevent >>> IPv4 and IPv6 address of the same adapter being treated as two >>> addresses >>> """" >>> >>> How is it preventing IPv4 and IPv6 addresses *both* being used for one >>> adapter? Could it be that this fix works because loopback was the only >>> one with IPv4 and IPv6 address config on the test server? >>> >>> Say one has the following /etc/hosts config: >>> 192.168.1.14 localhost >>> fe80::56ee:75ff:fe35:d1d4 localhost >>> >>> with the following adapter info (from ifconfig): >>> >>> enp0s25: flags=4163 mtu 1500 >>> inet 192.168.1.14 netmask 255.255.255.0 broadcast 192.168.1.255 >>> inet6 fe80::56ee:75ff:fe35:d1d4 >>> >>> I.e. for adapter enp0s25 I specify the IP addresses 192.168.1.14 and >>> fe80::56ee:75ff:fe35:d1d4 to be "localhost". I'd expect the test to >>> still fail after this patch. >>> >>> + // we need 'real' localhost addresses only (eg. not loopback ones) >>> + // so we can bind the remote JMX connector to them >>> + private static boolean isNonloopbackLocalhost(InetAddress i) { >>> + if (!i.isLoopbackAddress()) { >>> + return i.getHostName().toLowerCase().equals("localhost"); >>> + } >>> + return false; >>> >>> TBH, I don't understand why this comment is there. Particularly, the >>> loopback exclusion. Yet, this may be platform specific. It worked for >>> me under linux. It was fine with binding to IPv4 loopback (127.0.0.1) >>> and some interface address (e.g. 192.168.1.x). Looking at the bug it >>> seems the main issue was a conflict of binding to IPv4 loopback + IPv6 >>> loopback. > >> You can have problems also with a configuration with several >> loopbacks. The test considers such a setup as a machine with multiple >> interfaces while it is, in fact, only one interface. > > Right. For the purpose of the test it would still be acceptable to bind > to loopback, no? One of the reasons why I'd think it would be useful is > that it wouldn't require the test to be run on a machine with > 1 > adapters/virtual adapters. You should test this config first. If I remember correctly I had some problems using multiple loopback addresses. -JB- > >> Also, it does not really make any sense to test binding to a loopback >> address - we are starting a remote JMX connector and loopback address >> is not accessible from outside, anyway. > > Conceptually yes, but due to lack of configure options (AFAIK) for the > local JMX agent it might still be useful. > >>> >>> So the gist would be to not use both IPv4 *and* IPv6 addresses of the >>> same adapter for the binding. How about using something like this for a >>> filter: >>> private static boolean isIpV4Address(InetAddress i) { >>> return i instanceof Inet4Address; >>> } >>> >>> Thoughts? >>> >>> Anyway, looks like it's too late now :-/ >> >> Yep. But feel free to open a new issue, with the reproducer >> description, and, hopefully a proposed patch :) > > Sure, not a problem. I'll see what I can do. > >> I will sponsor the push happily. > > Thank you! > > Cheers, > Severin > From sgehwolf at redhat.com Fri Jan 15 09:30:50 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Jan 2016 10:30:50 +0100 Subject: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses In-Reply-To: <5698BBA5.6020800@oracle.com> References: <567A76BF.5090305@oracle.com> <568A35C5.7020804@oracle.com> <568BD39E.20305@oracle.com> <568E7E15.5020004@oracle.com> <568E94FD.6000206@oracle.com> <5694D9C4.1030901@oracle.com> <5694E834.9020502@oracle.com> <5694E9CD.9040409@oracle.com> <56963205.5000505@oracle.com> <56969C9B.1080104@oracle.com> <1452788587.3685.29.camel@redhat.com> <5698B2F2.5030602@oracle.com> <1452849869.3564.11.camel@redhat.com> <5698BBA5.6020800@oracle.com> Message-ID: <1452850250.3564.13.camel@redhat.com> On Fri, 2016-01-15 at 10:28 +0100, Jaroslav Bachorik wrote: > On 15.1.2016 10:24, Severin Gehwolf wrote: > > Hi, > > > > On Fri, 2016-01-15 at 09:50 +0100, Jaroslav Bachorik wrote: > > > > Sorry for being late in the game with this. > > > > > > > > +????private static List getAddressesForLocalHost() { > > > > + > > > > ???????????try { > > > > -????????????addrs = InetAddress.getAllByName("localhost"); > > > > -????????} catch (UnknownHostException e) { > > > > +????????????return NetworkInterface.networkInterfaces() > > > > +????????????????.flatMap(NetworkInterface::inetAddresses) > > > > +????????????????.filter(JMXInterfaceBindingTest::isNonloopbackLocalhost) > > > > +????????????????.collect(Collectors.toList()); > > > > > > > > I wonder if this does what you claim it does. It looks like it's > > > > getting all the addresses per adapter (IPv4 or IPv6) and then filters > > > > addresses out which have "localhost" as name and aren't loopback. It's > > > > not really what you said it does: > > > > > > > > """" > > > > The fix adds the requested wrapping for IPv6 addresses and adjusts the > > > > IP selection logic to iterate over distinct adapters first and prevent > > > > IPv4 and IPv6 address of the same adapter being treated as two > > > > addresses > > > > """" > > > > > > > > How is it preventing IPv4 and IPv6 addresses *both* being used for one > > > > adapter? Could it be that this fix works because loopback was the only > > > > one with IPv4 and IPv6 address config on the test server? > > > > > > > > Say one has the following /etc/hosts config: > > > > 192.168.1.14??????????????localhost > > > > fe80::56ee:75ff:fe35:d1d4 localhost > > > > > > > > with the following adapter info (from ifconfig): > > > > > > > > enp0s25: flags=4163??mtu 1500 > > > > ??????????inet 192.168.1.14??netmask 255.255.255.0??broadcast 192.168.1.255 > > > > ??????????inet6 fe80::56ee:75ff:fe35:d1d4 > > > > > > > > I.e. for adapter enp0s25 I specify the IP addresses 192.168.1.14 and > > > > fe80::56ee:75ff:fe35:d1d4 to be "localhost". I'd expect the test to > > > > still fail after this patch. > > > > > > > > +????// we need 'real' localhost addresses only (eg. not loopback ones) > > > > +????// so we can bind the remote JMX connector to them > > > > +????private static boolean isNonloopbackLocalhost(InetAddress i) { > > > > +????????if (!i.isLoopbackAddress()) { > > > > +????????????return i.getHostName().toLowerCase().equals("localhost"); > > > > +????????} > > > > +????????return false; > > > > > > > > TBH, I don't understand why this comment is there. Particularly, the > > > > loopback exclusion. Yet, this may be platform specific. It worked for > > > > me under linux. It was fine with binding to IPv4 loopback (127.0.0.1) > > > > and some interface address (e.g. 192.168.1.x). Looking at the bug it > > > > seems the main issue was a conflict of binding to IPv4 loopback + IPv6 > > > > loopback. > > > > > You can have problems also with a configuration with several > > > loopbacks. The test considers such a setup as a machine with multiple > > > interfaces while it is, in fact, only one interface. > > > > Right. For the purpose of the test it would still be acceptable to bind > > to loopback, no? One of the reasons why I'd think it would be useful is > > that it wouldn't require the test to be run on a machine with > 1 > > adapters/virtual adapters. > > You should test this config first. If I remember correctly I had some? > problems using multiple loopback addresses. OK. Thanks for the heads-up. Cheers, Severin From sgehwolf at redhat.com Thu Jan 21 10:30:09 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 21 Jan 2016 11:30:09 +0100 Subject: jmx-dev [8] RFR(S): 8147857: RMIConnector logs attribute names incorrectly Message-ID: <1453372209.4628.9.camel@redhat.com> Hi, Could somebody please review and sponsor this small 8u bugfix? This bug has been introduced with the January 2016 CPU fixes (JDK-8130710) and I've not seen this code in JDK 9 (yet?). Hence, posting this here. Bug:?https://bugs.openjdk.java.net/browse/JDK-8147857 webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147857/webrev.01/ The fix for non-public bug JDK-8130710 uses Collectors.joining() for assembling the list of attribute names when they get logged. However, the arguments are passed in to Collectors.joining() incorrectly, which results in log messages like this: attribute names=', FirstName[LastName]' where it should be this: attribute names='[FirstName, LastName]' The fix is to swap the arg for the delimiter and the prefix args. I've included a regression test. Testing done: jdk_jmx tests fail without the fix and pass after. Thoughts? Thanks, Severin From jaroslav.bachorik at oracle.com Thu Jan 21 11:01:26 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 21 Jan 2016 12:01:26 +0100 Subject: jmx-dev [8] RFR(S): 8147857: RMIConnector logs attribute names incorrectly In-Reply-To: <1453372209.4628.9.camel@redhat.com> References: <1453372209.4628.9.camel@redhat.com> Message-ID: <56A0BA86.20306@oracle.com> On 21.1.2016 11:30, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor this small 8u bugfix? This bug > has been introduced with the January 2016 CPU fixes (JDK-8130710) and > I've not seen this code in JDK 9 (yet?). Hence, posting this here. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147857 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147857/webrev.01/ > > The fix for non-public bug JDK-8130710 uses Collectors.joining() for > assembling the list of attribute names when they get logged. However, > the arguments are passed in to Collectors.joining() incorrectly, which > results in log messages like this: > > attribute names=', FirstName[LastName]' > > where it should be this: > > attribute names='[FirstName, LastName]' > > The fix is to swap the arg for the delimiter and the prefix args. I've > included a regression test. > > Testing done: jdk_jmx tests fail without the fix and pass after. > > Thoughts? Nice catch. And good work fixing it with a nice test! Looks good, not a JDK 8 *R*eviewer, though. -JB- > > Thanks, > Severin > From sgehwolf at redhat.com Thu Jan 21 14:20:56 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 21 Jan 2016 15:20:56 +0100 Subject: jmx-dev [8] RFR(S): 8147857: RMIConnector logs attribute names incorrectly In-Reply-To: <56A0BA86.20306@oracle.com> References: <1453372209.4628.9.camel@redhat.com> <56A0BA86.20306@oracle.com> Message-ID: <1453386056.4628.29.camel@redhat.com> Thanks, Jaroslav. Any JDK 8 reviewer willing to have a look at this? Thanks, Severin On Thu, 2016-01-21 at 12:01 +0100, Jaroslav Bachorik wrote: > On 21.1.2016 11:30, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review and sponsor this small 8u bugfix? This bug > > has been introduced with the January 2016 CPU fixes (JDK-8130710) and > > I've not seen this code in JDK 9 (yet?). Hence, posting this here. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147857 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147857/webrev.01/ > > > > The fix for non-public bug JDK-8130710 uses Collectors.joining() for > > assembling the list of attribute names when they get logged. However, > > the arguments are passed in to Collectors.joining() incorrectly, which > > results in log messages like this: > > > > attribute names=', FirstName[LastName]' > > > > where it should be this: > > > > attribute names='[FirstName, LastName]' > > > > The fix is to swap the arg for the delimiter and the prefix args. I've > > included a regression test. > > > > Testing done: jdk_jmx tests fail without the fix and pass after. > > > > Thoughts? > > Nice catch. And good work fixing it with a nice test! > Looks good, not a JDK 8 *R*eviewer, though. > > -JB- > > > > > Thanks, > > Severin > > > From daniel.fuchs at oracle.com Thu Jan 21 17:03:43 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 21 Jan 2016 18:03:43 +0100 Subject: jmx-dev [8] RFR(S): 8147857: RMIConnector logs attribute names incorrectly In-Reply-To: <1453386056.4628.29.camel@redhat.com> References: <1453372209.4628.9.camel@redhat.com> <56A0BA86.20306@oracle.com> <1453386056.4628.29.camel@redhat.com> Message-ID: <56A10F6F.7000601@oracle.com> On 21/01/16 15:20, Severin Gehwolf wrote: > Thanks, Jaroslav. Any JDK 8 reviewer willing to have a look at this? Looks good to me Severin. best regards, -- daniel > > Thanks, > Severin > > On Thu, 2016-01-21 at 12:01 +0100, Jaroslav Bachorik wrote: >> On 21.1.2016 11:30, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review and sponsor this small 8u bugfix? This bug >>> has been introduced with the January 2016 CPU fixes (JDK-8130710) and >>> I've not seen this code in JDK 9 (yet?). Hence, posting this here. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147857 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147857/webrev.01/ >>> >>> The fix for non-public bug JDK-8130710 uses Collectors.joining() for >>> assembling the list of attribute names when they get logged. However, >>> the arguments are passed in to Collectors.joining() incorrectly, which >>> results in log messages like this: >>> >>> attribute names=', FirstName[LastName]' >>> >>> where it should be this: >>> >>> attribute names='[FirstName, LastName]' >>> >>> The fix is to swap the arg for the delimiter and the prefix args. I've >>> included a regression test. >>> >>> Testing done: jdk_jmx tests fail without the fix and pass after. >>> >>> Thoughts? >> >> Nice catch. And good work fixing it with a nice test! >> Looks good, not a JDK 8 *R*eviewer, though. >> >> -JB- >> >>> >>> Thanks, >>> Severin >>> >> > From sgehwolf at redhat.com Fri Jan 22 08:58:35 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 22 Jan 2016 09:58:35 +0100 Subject: jmx-dev [8] RFR(S): 8147857: RMIConnector logs attribute names incorrectly In-Reply-To: <56A10F6F.7000601@oracle.com> References: <1453372209.4628.9.camel@redhat.com> <56A0BA86.20306@oracle.com> <1453386056.4628.29.camel@redhat.com> <56A10F6F.7000601@oracle.com> Message-ID: <1453453115.3769.3.camel@redhat.com> On Thu, 2016-01-21 at 18:03 +0100, Daniel Fuchs wrote: > On 21/01/16 15:20, Severin Gehwolf wrote: > > Thanks, Jaroslav. Any JDK 8 reviewer willing to have a look at this? > > Looks good to me Severin. Thank you, Daniel! Cheers, Severin > best regards, > > -- daniel > > > > Thanks, > > Severin > > > > On Thu, 2016-01-21 at 12:01 +0100, Jaroslav Bachorik wrote: > > > On 21.1.2016 11:30, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could somebody please review and sponsor this small 8u bugfix? This bug > > > > has been introduced with the January 2016 CPU fixes (JDK-8130710) and > > > > I've not seen this code in JDK 9 (yet?). Hence, posting this here. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8147857 > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8147857/webrev.01/ > > > > > > > > The fix for non-public bug JDK-8130710 uses Collectors.joining() for > > > > assembling the list of attribute names when they get logged. However, > > > > the arguments are passed in to Collectors.joining() incorrectly, which > > > > results in log messages like this: > > > > > > > > attribute names=', FirstName[LastName]' > > > > > > > > where it should be this: > > > > > > > > attribute names='[FirstName, LastName]' > > > > > > > > The fix is to swap the arg for the delimiter and the prefix args. I've > > > > included a regression test. > > > > > > > > Testing done: jdk_jmx tests fail without the fix and pass after. > > > > > > > > Thoughts? > > > > > > Nice catch. And good work fixing it with a nice test! > > > Looks good, not a JDK 8 *R*eviewer, though. > > > > > > -JB- > > > > > > > > > > > Thanks, > > > > Severin > > > > > > > > > > From jaroslav.bachorik at oracle.com Wed Jan 27 10:17:20 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 27 Jan 2016 11:17:20 +0100 Subject: jmx-dev JDK-8031753 : Review request In-Reply-To: <56A89747.6000600@oracle.com> References: <568F84E3.2040602@oracle.com> <56937411.5080208@oracle.com> <56971E45.5010305@oracle.com> <56A89747.6000600@oracle.com> Message-ID: <56A89930.9020305@oracle.com> Hi Harsha, On 27.1.2016 11:09, Harsha Wardhana B wrote: > Hello All, > > For the below fix, I have made appropriate javadoc changes and uploaded > new webrev at below location. > > http://cr.openjdk.java.net/~hb/8031753/webrev.00/ > > > Please review and let me know your comments. I'm a bit uneasy by introducing rather involved logic into supposedly simple value holder type JMXServiceURL. On the other hand, there already are some pieces of non-trivial code to deduce defaults there so we might just continue on this path. Here are some nits: src/java.management/share/classes/javax/management/remote/JMXServiceURL.java L309-319: Indentation seem to be corrupted here L365-366: The opening curly bracket should be on the same line Missing reg test. Cheers, -JB- > > Thanks > Harsha > > On Thursday 14 January 2016 09:34 AM, Harsha Wardhana B wrote: >> Gentle reminder :) >> >> On Monday 11 January 2016 02:51 PM, Jaroslav Bachorik wrote: >>> [adding JMX dev list] >>> >>> On 8.1.2016 10:44, Harsha Wardhana B wrote: >>>> Hi All, >>>> >>>> Please review the fix for, >>>> >>>> Issue : JDK-8031753 - JMXServiceURL should not use >>>> getLocalHost or its usage should be enhanced >>>> Webrev : >>>> http://cr.openjdk.java.net/~jbachorik/sponsorship/8031753/webrev.00/ >>>> >>>> The issue can be reproduced by removing entry for hostname in >>>> /etc/hosts >>>> (for linux) and running >>>> 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' >>>> test. >>>> Hence no new jtreg test case have been written. >>>> >>>> Fix Description: >>>> >>>> If JMXServiceURL is given null host, it tries to resolve hostname via >>>> InetAddress.getLocalHost() and if that fails throws >>>> MalformedURLException. Since JMX Agent will listen on all interfaces >>>> (0.0.0.0) if host is null, the fix handles the exception and assigns >>>> first active non-loopback interface IP address to host. That way we can >>>> have JMXServiceURL with IP address instead of hostname. >>>> >>>> It is possible that we might end up constructing JMXServiceURL with IP >>>> for an interface which clients may not be able to connect (because of >>>> network reachability issues). In that case, the recommendation would be >>>> to try to start JMX Agent with >>>> com.sun.management.jmxremote.host=xx.xx.xx.xx option. That way, the >>>> agent will be started on interface that clients can actually connect >>>> to. >>>> >>>> Please review the fix and let me know your comments. The fix requires >>>> amending javadoc with above behavioral change and a CCC review as well >>>> which I will send out later. >>>> >>>> Thanks >>>> Harsha >>>> >>> >> > From harsha.wardhana.b at oracle.com Thu Jan 14 04:04:21 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 14 Jan 2016 09:34:21 +0530 Subject: jmx-dev JDK-8031753 : Review request In-Reply-To: <56937411.5080208@oracle.com> References: <568F84E3.2040602@oracle.com> <56937411.5080208@oracle.com> Message-ID: <56971E45.5010305@oracle.com> Gentle reminder :) On Monday 11 January 2016 02:51 PM, Jaroslav Bachorik wrote: > [adding JMX dev list] > > On 8.1.2016 10:44, Harsha Wardhana B wrote: >> Hi All, >> >> Please review the fix for, >> >> Issue : JDK-8031753 - JMXServiceURL should not use >> getLocalHost or its usage should be enhanced >> Webrev : >> http://cr.openjdk.java.net/~jbachorik/sponsorship/8031753/webrev.00/ >> >> The issue can be reproduced by removing entry for hostname in /etc/hosts >> (for linux) and running >> 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' test. >> Hence no new jtreg test case have been written. >> >> Fix Description: >> >> If JMXServiceURL is given null host, it tries to resolve hostname via >> InetAddress.getLocalHost() and if that fails throws >> MalformedURLException. Since JMX Agent will listen on all interfaces >> (0.0.0.0) if host is null, the fix handles the exception and assigns >> first active non-loopback interface IP address to host. That way we can >> have JMXServiceURL with IP address instead of hostname. >> >> It is possible that we might end up constructing JMXServiceURL with IP >> for an interface which clients may not be able to connect (because of >> network reachability issues). In that case, the recommendation would be >> to try to start JMX Agent with >> com.sun.management.jmxremote.host=xx.xx.xx.xx option. That way, the >> agent will be started on interface that clients can actually connect to. >> >> Please review the fix and let me know your comments. The fix requires >> amending javadoc with above behavioral change and a CCC review as well >> which I will send out later. >> >> Thanks >> Harsha >> > From harsha.wardhana.b at oracle.com Wed Jan 27 10:09:11 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 27 Jan 2016 15:39:11 +0530 Subject: jmx-dev JDK-8031753 : Review request In-Reply-To: <56971E45.5010305@oracle.com> References: <568F84E3.2040602@oracle.com> <56937411.5080208@oracle.com> <56971E45.5010305@oracle.com> Message-ID: <56A89747.6000600@oracle.com> Hello All, For the below fix, I have made appropriate javadoc changes and uploaded new webrev at below location. http://cr.openjdk.java.net/~hb/8031753/webrev.00/ Please review and let me know your comments. Thanks Harsha On Thursday 14 January 2016 09:34 AM, Harsha Wardhana B wrote: > Gentle reminder :) > > On Monday 11 January 2016 02:51 PM, Jaroslav Bachorik wrote: >> [adding JMX dev list] >> >> On 8.1.2016 10:44, Harsha Wardhana B wrote: >>> Hi All, >>> >>> Please review the fix for, >>> >>> Issue : JDK-8031753 - JMXServiceURL should not use >>> getLocalHost or its usage should be enhanced >>> Webrev : >>> http://cr.openjdk.java.net/~jbachorik/sponsorship/8031753/webrev.00/ >>> >>> The issue can be reproduced by removing entry for hostname in >>> /etc/hosts >>> (for linux) and running >>> 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' >>> test. >>> Hence no new jtreg test case have been written. >>> >>> Fix Description: >>> >>> If JMXServiceURL is given null host, it tries to resolve hostname via >>> InetAddress.getLocalHost() and if that fails throws >>> MalformedURLException. Since JMX Agent will listen on all interfaces >>> (0.0.0.0) if host is null, the fix handles the exception and assigns >>> first active non-loopback interface IP address to host. That way we can >>> have JMXServiceURL with IP address instead of hostname. >>> >>> It is possible that we might end up constructing JMXServiceURL with IP >>> for an interface which clients may not be able to connect (because of >>> network reachability issues). In that case, the recommendation would be >>> to try to start JMX Agent with >>> com.sun.management.jmxremote.host=xx.xx.xx.xx option. That way, the >>> agent will be started on interface that clients can actually connect >>> to. >>> >>> Please review the fix and let me know your comments. The fix requires >>> amending javadoc with above behavioral change and a CCC review as well >>> which I will send out later. >>> >>> Thanks >>> Harsha >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Wed Jan 27 14:30:13 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 27 Jan 2016 20:00:13 +0530 Subject: jmx-dev JDK-8031753 : Review request In-Reply-To: <56A89930.9020305@oracle.com> References: <568F84E3.2040602@oracle.com> <56937411.5080208@oracle.com> <56971E45.5010305@oracle.com> <56A89747.6000600@oracle.com> <56A89930.9020305@oracle.com> Message-ID: <56A8D475.7030000@oracle.com> Hi Jaroslav, Below is the updated webrev with minor line alignment fixes. http://cr.openjdk.java.net/~hb/8031753/webrev.01/ The issue can be reproduced by removing entry for hostname in /etc/hosts (for linux) and running 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' test. Hence no new jtreg test case have been written. Agreed that we are putting involved logic into a container object. The alternative would be remove all the involved logic from JMXServiceURL and create new a helper classes that can do URL validation. But that would be a API/Design change that can break compatibility with existing applications. Since the bug is not critical, I think we can make do with adding little more involved logic into existing validations. I would welcome more comments and discussions around this change. Please do review and let me know your thoughts. Thanks Harsha On Wednesday 27 January 2016 03:47 PM, Jaroslav Bachorik wrote: > Hi Harsha, > > On 27.1.2016 11:09, Harsha Wardhana B wrote: >> Hello All, >> >> For the below fix, I have made appropriate javadoc changes and uploaded >> new webrev at below location. >> >> http://cr.openjdk.java.net/~hb/8031753/webrev.00/ >> >> >> Please review and let me know your comments. > > I'm a bit uneasy by introducing rather involved logic into supposedly > simple value holder type JMXServiceURL. On the other hand, there > already are some pieces of non-trivial code to deduce defaults there > so we might just continue on this path. > > Here are some nits: > > src/java.management/share/classes/javax/management/remote/JMXServiceURL.java > > L309-319: Indentation seem to be corrupted here > L365-366: The opening curly bracket should be on the same line > > Missing reg test. > > Cheers, > > -JB- > >> >> Thanks >> Harsha >> >> On Thursday 14 January 2016 09:34 AM, Harsha Wardhana B wrote: >>> Gentle reminder :) >>> >>> On Monday 11 January 2016 02:51 PM, Jaroslav Bachorik wrote: >>>> [adding JMX dev list] >>>> >>>> On 8.1.2016 10:44, Harsha Wardhana B wrote: >>>>> Hi All, >>>>> >>>>> Please review the fix for, >>>>> >>>>> Issue : JDK-8031753 - JMXServiceURL should >>>>> not use >>>>> getLocalHost or its usage should be enhanced >>>>> Webrev : >>>>> http://cr.openjdk.java.net/~jbachorik/sponsorship/8031753/webrev.00/ >>>>> >>>>> The issue can be reproduced by removing entry for hostname in >>>>> /etc/hosts >>>>> (for linux) and running >>>>> 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' >>>>> test. >>>>> Hence no new jtreg test case have been written. >>>>> >>>>> Fix Description: >>>>> >>>>> If JMXServiceURL is given null host, it tries to resolve hostname via >>>>> InetAddress.getLocalHost() and if that fails throws >>>>> MalformedURLException. Since JMX Agent will listen on all interfaces >>>>> (0.0.0.0) if host is null, the fix handles the exception and assigns >>>>> first active non-loopback interface IP address to host. That way >>>>> we can >>>>> have JMXServiceURL with IP address instead of hostname. >>>>> >>>>> It is possible that we might end up constructing JMXServiceURL >>>>> with IP >>>>> for an interface which clients may not be able to connect (because of >>>>> network reachability issues). In that case, the recommendation >>>>> would be >>>>> to try to start JMX Agent with >>>>> com.sun.management.jmxremote.host=xx.xx.xx.xx option. That way, the >>>>> agent will be started on interface that clients can actually connect >>>>> to. >>>>> >>>>> Please review the fix and let me know your comments. The fix requires >>>>> amending javadoc with above behavioral change and a CCC review as >>>>> well >>>>> which I will send out later. >>>>> >>>>> Thanks >>>>> Harsha >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Wed Jan 27 15:24:42 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 27 Jan 2016 16:24:42 +0100 Subject: jmx-dev JDK-8031753 : Review request In-Reply-To: <56A8D475.7030000@oracle.com> References: <568F84E3.2040602@oracle.com> <56937411.5080208@oracle.com> <56971E45.5010305@oracle.com> <56A89747.6000600@oracle.com> <56A89930.9020305@oracle.com> <56A8D475.7030000@oracle.com> Message-ID: <56A8E13A.80405@oracle.com> Hi Harsha, On 27.1.2016 15:30, Harsha Wardhana B wrote: > Hi Jaroslav, > > Below is the updated webrev with minor line alignment fixes. > > http://cr.openjdk.java.net/~hb/8031753/webrev.01/ > > > The issue can be reproduced by removing entry for hostname in > /etc/hosts (for linux) and running > 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' > test. > Hence no new jtreg test case have been written. > > Agreed that we are putting involved logic into a container object. The > alternative would be remove all the involved logic from JMXServiceURL > and create new a helper classes that can do URL validation. But that > would be a API/Design change that can break compatibility with existing > applications. Since the bug is not critical, I think we can make do with > adding little more involved logic into existing validations. I see. Probably this is acceptable. > > I would welcome more comments and discussions around this change. Please > do review and let me know your thoughts. (R)eviewed. Thanks! -JB- > > Thanks > Harsha > > On Wednesday 27 January 2016 03:47 PM, Jaroslav Bachorik wrote: >> Hi Harsha, >> >> On 27.1.2016 11:09, Harsha Wardhana B wrote: >>> Hello All, >>> >>> For the below fix, I have made appropriate javadoc changes and uploaded >>> new webrev at below location. >>> >>> http://cr.openjdk.java.net/~hb/8031753/webrev.00/ >>> >>> >>> Please review and let me know your comments. >> >> I'm a bit uneasy by introducing rather involved logic into supposedly >> simple value holder type JMXServiceURL. On the other hand, there >> already are some pieces of non-trivial code to deduce defaults there >> so we might just continue on this path. >> >> Here are some nits: >> >> src/java.management/share/classes/javax/management/remote/JMXServiceURL.java >> >> L309-319: Indentation seem to be corrupted here >> L365-366: The opening curly bracket should be on the same line >> >> Missing reg test. >> >> Cheers, >> >> -JB- >> >>> >>> Thanks >>> Harsha >>> >>> On Thursday 14 January 2016 09:34 AM, Harsha Wardhana B wrote: >>>> Gentle reminder :) >>>> >>>> On Monday 11 January 2016 02:51 PM, Jaroslav Bachorik wrote: >>>>> [adding JMX dev list] >>>>> >>>>> On 8.1.2016 10:44, Harsha Wardhana B wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review the fix for, >>>>>> >>>>>> Issue : JDK-8031753 - JMXServiceURL should >>>>>> not use >>>>>> getLocalHost or its usage should be enhanced >>>>>> Webrev : >>>>>> http://cr.openjdk.java.net/~jbachorik/sponsorship/8031753/webrev.00/ >>>>>> >>>>>> The issue can be reproduced by removing entry for hostname in >>>>>> /etc/hosts >>>>>> (for linux) and running >>>>>> 'javax/management/remote/mandatory/connection/RMIConnectionIdTest' >>>>>> test. >>>>>> Hence no new jtreg test case have been written. >>>>>> >>>>>> Fix Description: >>>>>> >>>>>> If JMXServiceURL is given null host, it tries to resolve hostname via >>>>>> InetAddress.getLocalHost() and if that fails throws >>>>>> MalformedURLException. Since JMX Agent will listen on all interfaces >>>>>> (0.0.0.0) if host is null, the fix handles the exception and assigns >>>>>> first active non-loopback interface IP address to host. That way >>>>>> we can >>>>>> have JMXServiceURL with IP address instead of hostname. >>>>>> >>>>>> It is possible that we might end up constructing JMXServiceURL >>>>>> with IP >>>>>> for an interface which clients may not be able to connect (because of >>>>>> network reachability issues). In that case, the recommendation >>>>>> would be >>>>>> to try to start JMX Agent with >>>>>> com.sun.management.jmxremote.host=xx.xx.xx.xx option. That way, the >>>>>> agent will be started on interface that clients can actually connect >>>>>> to. >>>>>> >>>>>> Please review the fix and let me know your comments. The fix requires >>>>>> amending javadoc with above behavioral change and a CCC review as >>>>>> well >>>>>> which I will send out later. >>>>>> >>>>>> Thanks >>>>>> Harsha >>>>>> >>>>> >>>> >>> >> >