From jaroslav.bachorik at oracle.com Thu Feb 11 10:39:41 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 11 Feb 2016 11:39:41 +0100 Subject: jmx-dev RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2) Message-ID: <56BC64ED.8000801@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.02 The previous attempt to fix this problem was focused on the fact that the test tend to fail on ARM64 platforms. This is no more true, the failure is reproducible on various platforms if using fastdebug build. It turns out that the test is setting up SSL in a way that only RC4 cipher suites are to be used (the test keys are generated by this algo). These cipher suites, however, has been disabled (JDK-8076221). By all means the test should be failing since the RC4 test suites were excluded. For some reason it started failing intermittently instead. I will leave the exercise of figuring out why to someone with a thorough expertise in SSL handshake. The fix is straightforward - create new keys (and keystore and truststore) using a supported cipher suite. I opted for the default one (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties for the test to request this cipher suite. After this change the test is passing regularly (tried running it 200 times in a loop - without any failure). Thanks, -JB- From jaroslav.bachorik at oracle.com Tue Feb 16 09:41:32 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 16 Feb 2016 10:41:32 +0100 Subject: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2) In-Reply-To: <56BC64ED.8000801@oracle.com> References: <56BC64ED.8000801@oracle.com> Message-ID: <56C2EECC.8050909@oracle.com> On 11.2.2016 11:39, 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.02 > > The previous attempt to fix this problem was focused on the fact that > the test tend to fail on ARM64 platforms. This is no more true, the > failure is reproducible on various platforms if using fastdebug build. > > It turns out that the test is setting up SSL in a way that only RC4 > cipher suites are to be used (the test keys are generated by this algo). > These cipher suites, however, has been disabled (JDK-8076221). > > By all means the test should be failing since the RC4 test suites were > excluded. For some reason it started failing intermittently instead. I > will leave the exercise of figuring out why to someone with a thorough > expertise in SSL handshake. > > The fix is straightforward - create new keys (and keystore and > truststore) using a supported cipher suite. I opted for the default one > (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties for > the test to request this cipher suite. After this change the test is > passing regularly (tried running it 200 times in a loop - without any > failure). > > Thanks, > > -JB- From daniel.fuchs at oracle.com Tue Feb 16 10:56:42 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Feb 2016 11:56:42 +0100 Subject: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2) In-Reply-To: <56C2EECC.8050909@oracle.com> References: <56BC64ED.8000801@oracle.com> <56C2EECC.8050909@oracle.com> Message-ID: <56C3006A.5080703@oracle.com> Hi Jaroslav, I have no objection to this change. Could you add a comment somewhere to explain how you generated the truststore and keystore - in case we need to tweak that again in the future? best regards, -- daniel On 16/02/16 10:41, Jaroslav Bachorik wrote: > On 11.2.2016 11:39, 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.02 >> >> The previous attempt to fix this problem was focused on the fact that >> the test tend to fail on ARM64 platforms. This is no more true, the >> failure is reproducible on various platforms if using fastdebug build. >> >> It turns out that the test is setting up SSL in a way that only RC4 >> cipher suites are to be used (the test keys are generated by this algo). >> These cipher suites, however, has been disabled (JDK-8076221). >> >> By all means the test should be failing since the RC4 test suites were >> excluded. For some reason it started failing intermittently instead. I >> will leave the exercise of figuring out why to someone with a thorough >> expertise in SSL handshake. >> >> The fix is straightforward - create new keys (and keystore and >> truststore) using a supported cipher suite. I opted for the default one >> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties for >> the test to request this cipher suite. After this change the test is >> passing regularly (tried running it 200 times in a loop - without any >> failure). >> >> Thanks, >> >> -JB- > From jaroslav.bachorik at oracle.com Wed Feb 17 12:13:43 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 17 Feb 2016 13:13:43 +0100 Subject: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2) In-Reply-To: <56C3006A.5080703@oracle.com> References: <56BC64ED.8000801@oracle.com> <56C2EECC.8050909@oracle.com> <56C3006A.5080703@oracle.com> Message-ID: <56C463F7.7020806@oracle.com> On 16.2.2016 11:56, Daniel Fuchs wrote: > Hi Jaroslav, > > I have no objection to this change. > > Could you add a comment somewhere to explain how you > generated the truststore and keystore - in case we need > to tweak that again in the future? I've added a simple readme file next to the keystores. http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03 -JB- > > best regards, > > -- daniel > > On 16/02/16 10:41, Jaroslav Bachorik wrote: >> On 11.2.2016 11:39, 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.02 >>> >>> The previous attempt to fix this problem was focused on the fact that >>> the test tend to fail on ARM64 platforms. This is no more true, the >>> failure is reproducible on various platforms if using fastdebug build. >>> >>> It turns out that the test is setting up SSL in a way that only RC4 >>> cipher suites are to be used (the test keys are generated by this algo). >>> These cipher suites, however, has been disabled (JDK-8076221). >>> >>> By all means the test should be failing since the RC4 test suites were >>> excluded. For some reason it started failing intermittently instead. I >>> will leave the exercise of figuring out why to someone with a thorough >>> expertise in SSL handshake. >>> >>> The fix is straightforward - create new keys (and keystore and >>> truststore) using a supported cipher suite. I opted for the default one >>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties for >>> the test to request this cipher suite. After this change the test is >>> passing regularly (tried running it 200 times in a loop - without any >>> failure). >>> >>> Thanks, >>> >>> -JB- >> > From daniel.fuchs at oracle.com Wed Feb 17 13:41:30 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Feb 2016 14:41:30 +0100 Subject: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2) In-Reply-To: <56C463F7.7020806@oracle.com> References: <56BC64ED.8000801@oracle.com> <56C2EECC.8050909@oracle.com> <56C3006A.5080703@oracle.com> <56C463F7.7020806@oracle.com> Message-ID: <56C4788A.4090600@oracle.com> Thanks Jaroslav, that's great! If these certificates have an expiration date then it's possible that we will have to regenerate them from time to time... cheers, -- daniel On 17/02/16 13:13, Jaroslav Bachorik wrote: > On 16.2.2016 11:56, Daniel Fuchs wrote: >> Hi Jaroslav, >> >> I have no objection to this change. >> >> Could you add a comment somewhere to explain how you >> generated the truststore and keystore - in case we need >> to tweak that again in the future? > > I've added a simple readme file next to the keystores. > > http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03 > > -JB- > >> >> best regards, >> >> -- daniel >> >> On 16/02/16 10:41, Jaroslav Bachorik wrote: >>> On 11.2.2016 11:39, 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.02 >>>> >>>> The previous attempt to fix this problem was focused on the fact that >>>> the test tend to fail on ARM64 platforms. This is no more true, the >>>> failure is reproducible on various platforms if using fastdebug build. >>>> >>>> It turns out that the test is setting up SSL in a way that only RC4 >>>> cipher suites are to be used (the test keys are generated by this >>>> algo). >>>> These cipher suites, however, has been disabled (JDK-8076221). >>>> >>>> By all means the test should be failing since the RC4 test suites were >>>> excluded. For some reason it started failing intermittently instead. I >>>> will leave the exercise of figuring out why to someone with a thorough >>>> expertise in SSL handshake. >>>> >>>> The fix is straightforward - create new keys (and keystore and >>>> truststore) using a supported cipher suite. I opted for the default one >>>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties for >>>> the test to request this cipher suite. After this change the test is >>>> passing regularly (tried running it 200 times in a loop - without any >>>> failure). >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Thu Feb 18 08:48:45 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 18 Feb 2016 09:48:45 +0100 Subject: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2) In-Reply-To: <56C4788A.4090600@oracle.com> References: <56BC64ED.8000801@oracle.com> <56C2EECC.8050909@oracle.com> <56C3006A.5080703@oracle.com> <56C463F7.7020806@oracle.com> <56C4788A.4090600@oracle.com> Message-ID: <56C5856D.8060206@oracle.com> Hi, On 17.2.2016 14:41, Daniel Fuchs wrote: > Thanks Jaroslav, that's great! > > If these certificates have an expiration date then > it's possible that we will have to regenerate them > from time to time... Thanks for checking on this. I've update the certificates to have expiration date 100 years from now (should be sufficient for now) and updated the readme with the validity parameter. Also, I've rebased the patch against jdk9/dev since this test has been excluded there and it makes sense to include it back when it is fixed. http://cr.openjdk.java.net/~jbachorik/8145919/webrev.04 -JB- > > cheers, > > -- daniel > > On 17/02/16 13:13, Jaroslav Bachorik wrote: >> On 16.2.2016 11:56, Daniel Fuchs wrote: >>> Hi Jaroslav, >>> >>> I have no objection to this change. >>> >>> Could you add a comment somewhere to explain how you >>> generated the truststore and keystore - in case we need >>> to tweak that again in the future? >> >> I've added a simple readme file next to the keystores. >> >> http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03 >> >> -JB- >> >>> >>> best regards, >>> >>> -- daniel >>> >>> On 16/02/16 10:41, Jaroslav Bachorik wrote: >>>> On 11.2.2016 11:39, 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.02 >>>>> >>>>> The previous attempt to fix this problem was focused on the fact that >>>>> the test tend to fail on ARM64 platforms. This is no more true, the >>>>> failure is reproducible on various platforms if using fastdebug build. >>>>> >>>>> It turns out that the test is setting up SSL in a way that only RC4 >>>>> cipher suites are to be used (the test keys are generated by this >>>>> algo). >>>>> These cipher suites, however, has been disabled (JDK-8076221). >>>>> >>>>> By all means the test should be failing since the RC4 test suites were >>>>> excluded. For some reason it started failing intermittently instead. I >>>>> will leave the exercise of figuring out why to someone with a thorough >>>>> expertise in SSL handshake. >>>>> >>>>> The fix is straightforward - create new keys (and keystore and >>>>> truststore) using a supported cipher suite. I opted for the default >>>>> one >>>>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties >>>>> for >>>>> the test to request this cipher suite. After this change the test is >>>>> passing regularly (tried running it 200 times in a loop - without any >>>>> failure). >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From daniel.fuchs at oracle.com Thu Feb 18 09:40:34 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 18 Feb 2016 10:40:34 +0100 Subject: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2) In-Reply-To: <56C5856D.8060206@oracle.com> References: <56BC64ED.8000801@oracle.com> <56C2EECC.8050909@oracle.com> <56C3006A.5080703@oracle.com> <56C463F7.7020806@oracle.com> <56C4788A.4090600@oracle.com> <56C5856D.8060206@oracle.com> Message-ID: <56C59192.3010803@oracle.com> Hi Jaroslav, Looks good. BTW - shouldn't you take sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java out of the problem list as well? I see that 8147985 is fixed. best regards, -- daniel On 18/02/16 09:48, Jaroslav Bachorik wrote: > Hi, > > On 17.2.2016 14:41, Daniel Fuchs wrote: >> Thanks Jaroslav, that's great! >> >> If these certificates have an expiration date then >> it's possible that we will have to regenerate them >> from time to time... > > Thanks for checking on this. I've update the certificates to have > expiration date 100 years from now (should be sufficient for now) and > updated the readme with the validity parameter. > > Also, I've rebased the patch against jdk9/dev since this test has been > excluded there and it makes sense to include it back when it is fixed. > > http://cr.openjdk.java.net/~jbachorik/8145919/webrev.04 > > -JB- > >> >> cheers, >> >> -- daniel >> >> On 17/02/16 13:13, Jaroslav Bachorik wrote: >>> On 16.2.2016 11:56, Daniel Fuchs wrote: >>>> Hi Jaroslav, >>>> >>>> I have no objection to this change. >>>> >>>> Could you add a comment somewhere to explain how you >>>> generated the truststore and keystore - in case we need >>>> to tweak that again in the future? >>> >>> I've added a simple readme file next to the keystores. >>> >>> http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03 >>> >>> -JB- >>> >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 16/02/16 10:41, Jaroslav Bachorik wrote: >>>>> On 11.2.2016 11:39, 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.02 >>>>>> >>>>>> The previous attempt to fix this problem was focused on the fact that >>>>>> the test tend to fail on ARM64 platforms. This is no more true, the >>>>>> failure is reproducible on various platforms if using fastdebug >>>>>> build. >>>>>> >>>>>> It turns out that the test is setting up SSL in a way that only RC4 >>>>>> cipher suites are to be used (the test keys are generated by this >>>>>> algo). >>>>>> These cipher suites, however, has been disabled (JDK-8076221). >>>>>> >>>>>> By all means the test should be failing since the RC4 test suites >>>>>> were >>>>>> excluded. For some reason it started failing intermittently >>>>>> instead. I >>>>>> will leave the exercise of figuring out why to someone with a >>>>>> thorough >>>>>> expertise in SSL handshake. >>>>>> >>>>>> The fix is straightforward - create new keys (and keystore and >>>>>> truststore) using a supported cipher suite. I opted for the default >>>>>> one >>>>>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties >>>>>> for >>>>>> the test to request this cipher suite. After this change the test is >>>>>> passing regularly (tried running it 200 times in a loop - without any >>>>>> failure). >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Fri Feb 19 11:50:07 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 19 Feb 2016 12:50:07 +0100 Subject: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2) In-Reply-To: <56C59192.3010803@oracle.com> References: <56BC64ED.8000801@oracle.com> <56C2EECC.8050909@oracle.com> <56C3006A.5080703@oracle.com> <56C463F7.7020806@oracle.com> <56C4788A.4090600@oracle.com> <56C5856D.8060206@oracle.com> <56C59192.3010803@oracle.com> Message-ID: <56C7016F.5060200@oracle.com> On 18.2.2016 10:40, Daniel Fuchs wrote: > Hi Jaroslav, > > Looks good. > > BTW - shouldn't you take > sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > out of the problem list as well? > I see that 8147985 is fixed. Sure, but that will have to be a different changeset and a different review. Thanks for reviewing this! -JB- > > best regards, > > -- daniel > > On 18/02/16 09:48, Jaroslav Bachorik wrote: >> Hi, >> >> On 17.2.2016 14:41, Daniel Fuchs wrote: >>> Thanks Jaroslav, that's great! >>> >>> If these certificates have an expiration date then >>> it's possible that we will have to regenerate them >>> from time to time... >> >> Thanks for checking on this. I've update the certificates to have >> expiration date 100 years from now (should be sufficient for now) and >> updated the readme with the validity parameter. >> >> Also, I've rebased the patch against jdk9/dev since this test has been >> excluded there and it makes sense to include it back when it is fixed. >> >> http://cr.openjdk.java.net/~jbachorik/8145919/webrev.04 >> >> -JB- >> >>> >>> cheers, >>> >>> -- daniel >>> >>> On 17/02/16 13:13, Jaroslav Bachorik wrote: >>>> On 16.2.2016 11:56, Daniel Fuchs wrote: >>>>> Hi Jaroslav, >>>>> >>>>> I have no objection to this change. >>>>> >>>>> Could you add a comment somewhere to explain how you >>>>> generated the truststore and keystore - in case we need >>>>> to tweak that again in the future? >>>> >>>> I've added a simple readme file next to the keystores. >>>> >>>> http://cr.openjdk.java.net/~jbachorik/8145919/webrev.03 >>>> >>>> -JB- >>>> >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 16/02/16 10:41, Jaroslav Bachorik wrote: >>>>>> On 11.2.2016 11:39, 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.02 >>>>>>> >>>>>>> The previous attempt to fix this problem was focused on the fact >>>>>>> that >>>>>>> the test tend to fail on ARM64 platforms. This is no more true, the >>>>>>> failure is reproducible on various platforms if using fastdebug >>>>>>> build. >>>>>>> >>>>>>> It turns out that the test is setting up SSL in a way that only RC4 >>>>>>> cipher suites are to be used (the test keys are generated by this >>>>>>> algo). >>>>>>> These cipher suites, however, has been disabled (JDK-8076221). >>>>>>> >>>>>>> By all means the test should be failing since the RC4 test suites >>>>>>> were >>>>>>> excluded. For some reason it started failing intermittently >>>>>>> instead. I >>>>>>> will leave the exercise of figuring out why to someone with a >>>>>>> thorough >>>>>>> expertise in SSL handshake. >>>>>>> >>>>>>> The fix is straightforward - create new keys (and keystore and >>>>>>> truststore) using a supported cipher suite. I opted for the default >>>>>>> one >>>>>>> (TLS_DHE_DSS_WITH_AES_128_GCM_SHA256) and update the ssl properties >>>>>>> for >>>>>>> the test to request this cipher suite. After this change the test is >>>>>>> passing regularly (tried running it 200 times in a loop - without >>>>>>> any >>>>>>> failure). >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Fri Feb 19 11:57:48 2016 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 19 Feb 2016 12:57:48 +0100 Subject: jmx-dev RFR 8147987: Remove sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from problemList Message-ID: <56C7033C.2020809@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8147987 Webrev: http://cr.openjdk.java.net/~jbachorik/8147987/webrev.00 This change removes sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from the ProblemList.txt. The fix for the issue which caused this test to be placed on the problem list (JDK-8146015) has reached jdk9/dev (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e761ecc8f538?revcount=480) and therefore the test can be re-enabled. Thanks! -JB- From staffan.larsen at oracle.com Mon Feb 22 16:40:04 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 22 Feb 2016 08:40:04 -0800 Subject: jmx-dev RFR 8147987: Remove sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from problemList In-Reply-To: <56C7033C.2020809@oracle.com> References: <56C7033C.2020809@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 19 feb. 2016, at 03:57, Jaroslav Bachorik wrote: > > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8147987 > Webrev: http://cr.openjdk.java.net/~jbachorik/8147987/webrev.00 > > This change removes sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from the ProblemList.txt. > > The fix for the issue which caused this test to be placed on the problem list (JDK-8146015) has reached jdk9/dev (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e761ecc8f538?revcount=480) and therefore the test can be re-enabled. > > Thanks! > > -JB-