From Alan.Bateman at oracle.com Fri Jan 1 11:18:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 1 Jan 2016 11:18:02 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3A8A611@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B5D306@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B60D9B@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> Message-ID: <5686606A.5050100@oracle.com> On 21/12/2015 17:53, Lu, Yingqi wrote: > Hi All, > > Sorry for the late reply. Here is the link to the most recent reversion of the patch (version #6). http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.06/ > > In this version, we have done following modifications based on the feedback we received. Please review and let us know if there is anything missing. Thank you very much! > > I went through the latest webrev and it is look quite good. One thing that doesn't seem quite right is SocketImpl::isReusePortAvailable. Whether SO_REUSEPORT is supported or not depends on the concrete implementation of the SocketImpl. So I think this needs to be moved down to AbstractPlainSocketImpl. In net_util_md.h then SO_REUSEPORT is defined as 0x0200 on "unknown" platforms. I wonder if it would be better to not set it and instead have reuseport_supported return JNI_FALSE when SO_REUSEPORT is not defined. StandardSocketOptions.SO_REUSEPORT is referenced in shared code (sun/nio/ch/*Impl.java) so shouldn't it be defined to something on all platforms? I ask because genSocketOptionRegistry.c open emits a definition on non-Windows builds. Maybe it needs to emit it with a value of 0 on Windows. Also like net_util_md.c then maybe it should be emitted as 0 rather than 0x0200 when the value is not known. The javadoc looks good, a minor nit is that SocketOptions.SO_REUSEPORT needs @since 9. A few other minor nits in passing: - src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java indentation doesn't look right. - sun.nio.ch.Net.checkedReusePort - shouldn't be a need to initialize the volatile boolean to its default value (there is a patch in progress to remove many of these). - SdpSupport.convert0 - I assume this should only use getsockopt when the socket option is supported. I think this means it will need #ifdef SO_REUSEPORT. - A place uses have "//SO.." when "// SO..." would be more consistent. I think that's it. -Alan From yingqi.lu at intel.com Fri Jan 1 23:37:35 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 1 Jan 2016 23:37:35 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <5686606A.5050100@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3A8A611@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B5D306@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B60D9B@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA3B8923C@ORSMSX113.amr.corp.intel.com> Hi Alan, Happy New Year!! Thanks very much for your time reviewing the patch. I will make the changes regarding your comments and send them back here soon. Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Friday, January 01, 2016 3:18 AM To: Lu, Yingqi Cc: Viswanathan, Sandhya ; net-dev at openjdk.java.net; Kharbas, Kishor ; Aundhe, Shirish ; Kaczmarek, Eric Subject: Re: Patch for adding SO_REUSEPORT socket option On 21/12/2015 17:53, Lu, Yingqi wrote: > Hi All, > > Sorry for the late reply. Here is the link to the most recent > reversion of the patch (version #6). > http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.06/ > > In this version, we have done following modifications based on the feedback we received. Please review and let us know if there is anything missing. Thank you very much! > > I went through the latest webrev and it is look quite good. One thing that doesn't seem quite right is SocketImpl::isReusePortAvailable. Whether SO_REUSEPORT is supported or not depends on the concrete implementation of the SocketImpl. So I think this needs to be moved down to AbstractPlainSocketImpl. In net_util_md.h then SO_REUSEPORT is defined as 0x0200 on "unknown" platforms. I wonder if it would be better to not set it and instead have reuseport_supported return JNI_FALSE when SO_REUSEPORT is not defined. StandardSocketOptions.SO_REUSEPORT is referenced in shared code (sun/nio/ch/*Impl.java) so shouldn't it be defined to something on all platforms? I ask because genSocketOptionRegistry.c open emits a definition on non-Windows builds. Maybe it needs to emit it with a value of 0 on Windows. Also like net_util_md.c then maybe it should be emitted as 0 rather than 0x0200 when the value is not known. The javadoc looks good, a minor nit is that SocketOptions.SO_REUSEPORT needs @since 9. A few other minor nits in passing: - src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java indentation doesn't look right. - sun.nio.ch.Net.checkedReusePort - shouldn't be a need to initialize the volatile boolean to its default value (there is a patch in progress to remove many of these). - SdpSupport.convert0 - I assume this should only use getsockopt when the socket option is supported. I think this means it will need #ifdef SO_REUSEPORT. - A place uses have "//SO.." when "// SO..." would be more consistent. I think that's it. -Alan From Alan.Bateman at oracle.com Sat Jan 2 07:40:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 2 Jan 2016 07:40:44 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <56853BED.2070007@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> <5645DB41.8000704@oracle.com> <56853BED.2070007@oracle.com> Message-ID: <56877EFC.2000505@oracle.com> On 31/12/2015 14:30, Mark Sheppard wrote: > Hi > please oblige and review the current version of the fix for > https://bugs.openjdk.java.net/browse/JDK-8134577 > > at > http://cr.openjdk.java.net/~msheppar/8134577/webrev.05/ > > which is based on feedback from the second review. I looked through the latest webrev and I think this is starting to look good. Having the hosts file be the same format (albeit a subset) as /etc/hosts is a big improvement on previous iterations. InetAddress.nameServices is still a List but the List will always have one element, should this be changed to InetAddress.nameService (singular)? I think it would be cleaner if NameService were changed to an interface with two implementations, say PlatformNameService and HostsFileNameService. That way you could eliminate the useLocalHostsFileLookup and hostsFileName fields from InetAddress and HostsFileNameService could encapsulate the parsing of the hosts file rather than NameService trying to support both ways. The property name jdk.net.hosts.file is good but if set to a file that doesn't exist then the current patch falls back to use the platform name service. I assume this is not the original intention. The Scanner is created without specifying a charset, is this deliberate because the platform /etc/hosts is in platform encoding? For tests then it might be better to use UTF-8 because these hosts file will be used on several different platforms. Is there any reason to use legacy StringTokenizer in createAddressByteArray? In other areas of the patch then it using Scanner or String.split so it seems inconsistent to see legacy StringTokenizer in use too. You mentioned in the mail about # supported as a comment when the first character. It doesn't seem to be much effort to just drop everything after the # so that it is more consistent with the platform hosts file. UHE is thrown in a few places without any exception message. For the hosts file then it would be useful to include some message to make configuration issues easier to diagnose. The comment in NameService has a historical reference to the JNDI DNS provider, I assume that is not needed. I also looked through the test changes. Several tests set test.src and not clear that this is needed. I assume that what you really want is: String testSrc = System.getProperty("test.src", "."); addMappingToHostsFile is added to a number of tests. It would be good if this could use try-with-resources to avoid leaving a file open then the write fails (say a test machine with a full file system). sun/security/x509/URICertStore/ExtensionsWithLDAP.java has been added to the exclude list with JDK-8134577 as the issue number. Is there is a different issue number for this? Are all of the tests in test/sun/net/InetAddress/nameservice still needed? Some of these tests, as least in the 'dns' directory, are tests for the JNDI DNS provider and maybe they should be deleted. The update to KDC means that any test using this library will need to run in othervm mode. That may be true already but we should check. Related to this is that setting the system property in the main method might be fragile in that it's possible for code to execute before the main method that triggers the initialization of InetAddress. Something to keep in mind as we might have to re-visit these tests again. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Mon Jan 4 10:28:24 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 4 Jan 2016 10:28:24 +0000 Subject: [9] RFR: 8138990: Implementation of HTTP Digest authentication may be more flexible In-Reply-To: <56834DDF.40407@oracle.com> References: <56617BF2.2090306@oracle.com> <56795729.6040608@oracle.com> <56834DDF.40407@oracle.com> Message-ID: <568A4948.1040901@oracle.com> On 30/12/15 03:22, Artem Smotrakov wrote: > Hi Michael, > > Thanks for review, it looks like BNF notation uses only a comma as a > separator > > http://www.w3.org/Notation.html > > ... > #element > > indicating at least l and at most m elements, each separated by one or > more commas (","). > ... > Hi Artem, The BNF definitions used in RFC 2617 come from section 2.1 of RFC 2616 which allows linear white space between tokens. #rule A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "#element" indicating at least and at most elements, each separated by one or more commas (",") and OPTIONAL linear white space (LWS). So, I think we should be conservative and check for white-space. - Michael. Michael > And here is "qop" definition from https://tools.ietf.org/html/rfc2617 > > ... > qop-options = "qop" "=" <"> 1#qop-value <"> > qop-value = "auth" | "auth-int" | token > ... > > Please take a look at updated webrev: > > http://cr.openjdk.java.net/~asmotrak/http_auth_digest/webrev.01/ > > Artem > > On 12/22/2015 05:59 AM, Michael McMahon wrote: >> Hi Artem, >> >> >> On 04/12/15 11:41, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review this small fix for DigestAuthentication class. >>> >>> 1. Added a check in DigestAuthentication.setNonce(String) that nonce >>> is not null. NPE may happen if a buggy HTTP server returns >>> "WWW-Authenticate" header which doesn't contain a "nonce" field. >>> According to RFCs 2069 [1] and 2617 [2], this is not expected >>> behaviour, but it would be better if an HTTP client threw a checked >>> IOException instead of NPE. >>> >> >> That's fine. >> >>> 2. Updated DigestAuthentication.setQop(String) method to accept both >>> a whitespace and a comma as a delimiter. RFC 2617 [2] says that >>> "qop" may contain more than one token, but it doesn't specify a >>> delimiter for "qop" field in "WWW-Authenticate" header. There is an >>> example of "WWW-Authenticate" header in RFC 2617 [2] where a comma >>> is used as a delimiter of value in "qop" field. >>> >> >> It looks like the BNF specification mandates a comma and optional >> linear white space. >> So, the old code was buggy, but we didn't see the problem because >> there is typically >> only at most ever one value used for the qop field. But, to be >> strictly correct, we would >> have to check for TABs also. So, I think the correct behavior is to >> delimit using comma >> and remove any white space >> >> - Michael. >> >>> 3. Added a test for Digest authentication. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138990 >>> Webrev: http://cr.openjdk.java.net/~asmotrak/http_auth_digest/webrev.00/ >>> >>> [1] https://tools.ietf.org/html/rfc2069 >>> [2] https://tools.ietf.org/html/rfc2617 >>> >>> Artem >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Mon Jan 4 18:39:26 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 4 Jan 2016 10:39:26 -0800 Subject: [9] RFR: 8138990: Implementation of HTTP Digest authentication may be more flexible In-Reply-To: <568A4948.1040901@oracle.com> References: <56617BF2.2090306@oracle.com> <56795729.6040608@oracle.com> <56834DDF.40407@oracle.com> <568A4948.1040901@oracle.com> Message-ID: <568ABC5E.1010707@oracle.com> Hi Michael, On 01/04/2016 02:28 AM, Michael McMahon wrote: > On 30/12/15 03:22, Artem Smotrakov wrote: >> Hi Michael, >> >> Thanks for review, it looks like BNF notation uses only a comma as a >> separator >> >> http://www.w3.org/Notation.html >> >> ... >> #element >> >> indicating at least l and at most m elements, each separated by one >> or more commas (","). >> ... >> > > Hi Artem, > > The BNF definitions used in RFC 2617 come from section 2.1 of RFC 2616 > which allows linear white space between tokens. > > #rule > A construct "#" is defined, similar to "*", for defining lists of > elements. The full form is "#element" indicating at least > and at most elements, each separated by one or more commas > (",") and OPTIONAL linear white space (LWS). If I read it correctly, it means that a comma is used as a separator, but there also may be a linear whitespace after a comma. So for example "auth,auth-int" and "auth, auth-int" are equal, and should result to a list of two elements. Current version of webrev seems to follow it (first, it splits a string by a comma, and then ignores white spaces): http://cr.openjdk.java.net/~asmotrak/http_auth_digest/webrev.01/ Am I missing something? Artem > > So, I think we should be conservative and check for white-space. > > - Michael. > Michael >> And here is "qop" definition from https://tools.ietf.org/html/rfc2617 >> >> ... >> qop-options = "qop" "=" <"> 1#qop-value <"> >> qop-value = "auth" | "auth-int" | token >> ... >> >> Please take a look at updated webrev: >> >> http://cr.openjdk.java.net/~asmotrak/http_auth_digest/webrev.01/ >> >> Artem >> >> On 12/22/2015 05:59 AM, Michael McMahon wrote: >>> Hi Artem, >>> >>> >>> On 04/12/15 11:41, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> Please review this small fix for DigestAuthentication class. >>>> >>>> 1. Added a check in DigestAuthentication.setNonce(String) that >>>> nonce is not null. NPE may happen if a buggy HTTP server returns >>>> "WWW-Authenticate" header which doesn't contain a "nonce" field. >>>> According to RFCs 2069 [1] and 2617 [2], this is not expected >>>> behaviour, but it would be better if an HTTP client threw a checked >>>> IOException instead of NPE. >>>> >>> >>> That's fine. >>> >>>> 2. Updated DigestAuthentication.setQop(String) method to accept >>>> both a whitespace and a comma as a delimiter. RFC 2617 [2] says >>>> that "qop" may contain more than one token, but it doesn't specify >>>> a delimiter for "qop" field in "WWW-Authenticate" header. There is >>>> an example of "WWW-Authenticate" header in RFC 2617 [2] where a >>>> comma is used as a delimiter of value in "qop" field. >>>> >>> >>> It looks like the BNF specification mandates a comma and optional >>> linear white space. >>> So, the old code was buggy, but we didn't see the problem because >>> there is typically >>> only at most ever one value used for the qop field. But, to be >>> strictly correct, we would >>> have to check for TABs also. So, I think the correct behavior is to >>> delimit using comma >>> and remove any white space >>> >>> - Michael. >>> >>>> 3. Added a test for Digest authentication. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138990 >>>> Webrev: >>>> http://cr.openjdk.java.net/~asmotrak/http_auth_digest/webrev.00/ >>>> >>>> [1] https://tools.ietf.org/html/rfc2069 >>>> [2] https://tools.ietf.org/html/rfc2617 >>>> >>>> Artem >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Mon Jan 4 18:43:23 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Jan 2016 19:43:23 +0100 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <5686606A.5050100@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3A8A611@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B5D306@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B60D9B@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> Message-ID: Hi Lucy, Alan, I'm back from vacation so here we go :) On Fri, Jan 1, 2016 at 12:18 PM, Alan Bateman wrote: > > On 21/12/2015 17:53, Lu, Yingqi wrote: >> >> Hi All, >> >> Sorry for the late reply. Here is the link to the most recent reversion of the patch (version #6). http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.06/ >> >> In this version, we have done following modifications based on the feedback we received. Please review and let us know if there is anything missing. Thank you very much! >> >> > I went through the latest webrev and it is look quite good. > > One thing that doesn't seem quite right is SocketImpl::isReusePortAvailable. Whether SO_REUSEPORT is supported or not depends on the concrete implementation of the SocketImpl. So I think this needs to be moved down to AbstractPlainSocketImpl. > > In net_util_md.h then SO_REUSEPORT is defined as 0x0200 on "unknown" platforms. I wonder if it would be better to not set it and instead have reuseport_supported return JNI_FALSE when SO_REUSEPORT is not defined. > > > StandardSocketOptions.SO_REUSEPORT is referenced in shared code (sun/nio/ch/*Impl.java) so shouldn't it be defined to something on all platforms? I ask because genSocketOptionRegistry.c open emits a definition on non-Windows builds. Maybe it needs to emit it with a value of 0 on Windows. Also like net_util_md.c then maybe it should be emitted as 0 rather than 0x0200 when the value is not known. > Alan, what do you mean by "unknown" platform? Currently, as far as I know, 0x0200 is used by AIX and MacOS X. Do you suggest to name these platforms explicitly and set it to 0 otherwise? Leaving the default at 0x0200 has the advantage that it would implicitly work on other platforms like HPUX at the risk that it may be the wrong value on other, yet still unknown platforms. So in general I'm not against setting it to 0 on unknown platfroms (as this is the most secure setting) but in that case we should definitely name AIX and MacOS X as "known" platforms. I'm also a bit concerned about the following code in net_util_md.c 451 rv = setsockopt(s, SOL_SOCKET, SO_REUSEPORT, (void *)&one, sizeof(one)); 452 if (rv != 0 && errno == ENOPROTOOPT) { 453 rv = JNI_FALSE; 454 } else { 455 rv = JNI_TRUE; 456 } Why do we need the extra check for 'ENOPROTOOPT'? If the setsockopt() call, for whatever reason, returns with an error code other than 'ENOPROTOOPT' we will still return JNI_TRUE which I think would be bad. I think it would be more robust to always return JNI_FALSE if setsockopt() returns an error. Some tests I'm just running are still pending, but I think the rest looks pretty good. Regards, Volker > The javadoc looks good, a minor nit is that SocketOptions.SO_REUSEPORT needs @since 9. > > A few other minor nits in passing: > > - src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java indentation doesn't look right. > > - sun.nio.ch.Net.checkedReusePort - shouldn't be a need to initialize the volatile boolean to its default value (there is a patch in progress to remove many of these). > > - SdpSupport.convert0 - I assume this should only use getsockopt when the socket option is supported. I think this means it will need #ifdef SO_REUSEPORT. > > - A place uses have "//SO.." when "// SO..." would be more consistent. > > I think that's it. > > -Alan > > > From yingqi.lu at intel.com Mon Jan 4 19:02:16 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Mon, 4 Jan 2016 19:02:16 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA3A8A611@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B5D306@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B60D9B@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA3B8A896@ORSMSX113.amr.corp.intel.com> Hi Volker, Happy New Year and welcome back! Based on the feedback from you and Alan, here is what I plan to do. Please let me know if you have any concerns. 1. I will make HPUX, MACOSX and AIX as known and set them to 0x0200. As previous, Linux is set to 15 and Solaris is set to 0x100. The rest of the unix based OSes will be treated as unknown and will be set to 0. Windows will be set to 0 as well. 2. Regarding to the code snippet in net_util_md.c, the reason I check for ENOPROTOOPT is to enable SO_REUSEPORT in the situation that the feature is supported but something else happens during setsocksopts call. I totally agree this is much less safer than just disable the feature whenever the setsockopts returns error. Alan, please let me know what your take on this is. I can quick change it if you both think it is more appropriate to remove the ENOPROTOOPT check. Again, really appreciate the quick responses and helpful feedback from both of you :-) Thanks, Lucy -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Monday, January 04, 2016 10:43 AM To: Alan Bateman Cc: Lu, Yingqi ; Kaczmarek, Eric ; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; net-dev at openjdk.java.net Subject: Re: Patch for adding SO_REUSEPORT socket option Hi Lucy, Alan, I'm back from vacation so here we go :) On Fri, Jan 1, 2016 at 12:18 PM, Alan Bateman wrote: > > On 21/12/2015 17:53, Lu, Yingqi wrote: >> >> Hi All, >> >> Sorry for the late reply. Here is the link to the most recent >> reversion of the patch (version #6). >> http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.06/ >> >> In this version, we have done following modifications based on the feedback we received. Please review and let us know if there is anything missing. Thank you very much! >> >> > I went through the latest webrev and it is look quite good. > > One thing that doesn't seem quite right is SocketImpl::isReusePortAvailable. Whether SO_REUSEPORT is supported or not depends on the concrete implementation of the SocketImpl. So I think this needs to be moved down to AbstractPlainSocketImpl. > > In net_util_md.h then SO_REUSEPORT is defined as 0x0200 on "unknown" platforms. I wonder if it would be better to not set it and instead have reuseport_supported return JNI_FALSE when SO_REUSEPORT is not defined. > > > StandardSocketOptions.SO_REUSEPORT is referenced in shared code (sun/nio/ch/*Impl.java) so shouldn't it be defined to something on all platforms? I ask because genSocketOptionRegistry.c open emits a definition on non-Windows builds. Maybe it needs to emit it with a value of 0 on Windows. Also like net_util_md.c then maybe it should be emitted as 0 rather than 0x0200 when the value is not known. > Alan, what do you mean by "unknown" platform? Currently, as far as I know, 0x0200 is used by AIX and MacOS X. Do you suggest to name these platforms explicitly and set it to 0 otherwise? Leaving the default at 0x0200 has the advantage that it would implicitly work on other platforms like HPUX at the risk that it may be the wrong value on other, yet still unknown platforms. So in general I'm not against setting it to 0 on unknown platfroms (as this is the most secure setting) but in that case we should definitely name AIX and MacOS X as "known" platforms. I'm also a bit concerned about the following code in net_util_md.c 451 rv = setsockopt(s, SOL_SOCKET, SO_REUSEPORT, (void *)&one, sizeof(one)); 452 if (rv != 0 && errno == ENOPROTOOPT) { 453 rv = JNI_FALSE; 454 } else { 455 rv = JNI_TRUE; 456 } Why do we need the extra check for 'ENOPROTOOPT'? If the setsockopt() call, for whatever reason, returns with an error code other than 'ENOPROTOOPT' we will still return JNI_TRUE which I think would be bad. I think it would be more robust to always return JNI_FALSE if setsockopt() returns an error. Some tests I'm just running are still pending, but I think the rest looks pretty good. Regards, Volker > The javadoc looks good, a minor nit is that SocketOptions.SO_REUSEPORT needs @since 9. > > A few other minor nits in passing: > > - src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java indentation doesn't look right. > > - sun.nio.ch.Net.checkedReusePort - shouldn't be a need to initialize the volatile boolean to its default value (there is a patch in progress to remove many of these). > > - SdpSupport.convert0 - I assume this should only use getsockopt when the socket option is supported. I think this means it will need #ifdef SO_REUSEPORT. > > - A place uses have "//SO.." when "// SO..." would be more consistent. > > I think that's it. > > -Alan > > > From Alan.Bateman at oracle.com Mon Jan 4 19:24:16 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 Jan 2016 19:24:16 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B5D306@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B60D9B@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> Message-ID: <568AC6E0.9050807@oracle.com> On 04/01/2016 18:43, Volker Simonis wrote: > : > Alan, what do you mean by "unknown" platform? Currently, as far as I > know, 0x0200 is used by AIX and MacOS X. Do you suggest to name these > platforms explicitly and set it to 0 otherwise? Leaving the default at > 0x0200 has the advantage that it would implicitly work on other > platforms like HPUX at the risk that it may be the wrong value on > other, yet still unknown platforms. So in general I'm not against > setting it to 0 on unknown platfroms (as this is the most secure > setting) but in that case we should definitely name AIX and MacOS X as > "known" platforms. My concern with defaulting to 0x0200 is that it might be used on a platform where this is not the right value. Defaulting to 0 makes it easier to catch the issue and allows us to includes assertion that the socket option is != 0. If we build on versions of AIX and OSX that don't have SO_REUSEPORT defined then it would be good to get those into the known platform list. -Alan From volker.simonis at gmail.com Mon Jan 4 19:24:04 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Jan 2016 20:24:04 +0100 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA3B8A896@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3A8A611@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B5D306@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B60D9B@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8A896@ORSMSX113.amr.corp.intel.com> Message-ID: On Mon, Jan 4, 2016 at 8:02 PM, Lu, Yingqi wrote: > Hi Volker, > > Happy New Year and welcome back! Based on the feedback from you and Alan, here is what I plan to do. Please let me know if you have any concerns. > > 1. I will make HPUX, MACOSX and AIX as known and set them to 0x0200. As previous, Linux is set to 15 and Solaris is set to 0x100. The rest of the unix based OSes will be treated as unknown and will be set to 0. Windows will be set to 0 as well. > > 2. Regarding to the code snippet in net_util_md.c, the reason I check for ENOPROTOOPT is to enable SO_REUSEPORT in the situation that the feature is supported but something else happens during setsocksopts call. I totally agree this is much less safer than just disable the feature whenever the setsockopts returns error. Alan, please let me know what your take on this is. I can quick change it if you both think it is more appropriate to remove the ENOPROTOOPT check. > I just think we should play safe here. You also return JNI_FALSE when the call to socket() just before the one to setsockopt() fails. But lets here what's Alan's opinion. > Again, really appreciate the quick responses and helpful feedback from both of you :-) > > Thanks, > Lucy > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Monday, January 04, 2016 10:43 AM > To: Alan Bateman > Cc: Lu, Yingqi ; Kaczmarek, Eric ; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; net-dev at openjdk.java.net > Subject: Re: Patch for adding SO_REUSEPORT socket option > > Hi Lucy, Alan, > > I'm back from vacation so here we go :) > > On Fri, Jan 1, 2016 at 12:18 PM, Alan Bateman wrote: >> >> On 21/12/2015 17:53, Lu, Yingqi wrote: >>> >>> Hi All, >>> >>> Sorry for the late reply. Here is the link to the most recent >>> reversion of the patch (version #6). >>> http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.06/ >>> >>> In this version, we have done following modifications based on the feedback we received. Please review and let us know if there is anything missing. Thank you very much! >>> >>> >> I went through the latest webrev and it is look quite good. >> >> One thing that doesn't seem quite right is SocketImpl::isReusePortAvailable. Whether SO_REUSEPORT is supported or not depends on the concrete implementation of the SocketImpl. So I think this needs to be moved down to AbstractPlainSocketImpl. >> >> In net_util_md.h then SO_REUSEPORT is defined as 0x0200 on "unknown" platforms. I wonder if it would be better to not set it and instead have reuseport_supported return JNI_FALSE when SO_REUSEPORT is not defined. >> >> >> StandardSocketOptions.SO_REUSEPORT is referenced in shared code (sun/nio/ch/*Impl.java) so shouldn't it be defined to something on all platforms? I ask because genSocketOptionRegistry.c open emits a definition on non-Windows builds. Maybe it needs to emit it with a value of 0 on Windows. Also like net_util_md.c then maybe it should be emitted as 0 rather than 0x0200 when the value is not known. >> > > Alan, what do you mean by "unknown" platform? Currently, as far as I know, 0x0200 is used by AIX and MacOS X. Do you suggest to name these platforms explicitly and set it to 0 otherwise? Leaving the default at > 0x0200 has the advantage that it would implicitly work on other platforms like HPUX at the risk that it may be the wrong value on other, yet still unknown platforms. So in general I'm not against setting it to 0 on unknown platfroms (as this is the most secure > setting) but in that case we should definitely name AIX and MacOS X as "known" platforms. > > > I'm also a bit concerned about the following code in net_util_md.c > > 451 rv = setsockopt(s, SOL_SOCKET, SO_REUSEPORT, (void *)&one, > sizeof(one)); > 452 if (rv != 0 && errno == ENOPROTOOPT) { > 453 rv = JNI_FALSE; > 454 } else { > 455 rv = JNI_TRUE; > 456 } > > Why do we need the extra check for 'ENOPROTOOPT'? If the setsockopt() call, for whatever reason, returns with an error code other than 'ENOPROTOOPT' we will still return JNI_TRUE which I think would be bad. I think it would be more robust to always return JNI_FALSE if > setsockopt() returns an error. > > Some tests I'm just running are still pending, but I think the rest looks pretty good. > > Regards, > Volker > >> The javadoc looks good, a minor nit is that SocketOptions.SO_REUSEPORT needs @since 9. >> >> A few other minor nits in passing: >> >> - src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java indentation doesn't look right. >> >> - sun.nio.ch.Net.checkedReusePort - shouldn't be a need to initialize the volatile boolean to its default value (there is a patch in progress to remove many of these). >> >> - SdpSupport.convert0 - I assume this should only use getsockopt when the socket option is supported. I think this means it will need #ifdef SO_REUSEPORT. >> >> - A place uses have "//SO.." when "// SO..." would be more consistent. >> >> I think that's it. >> >> -Alan >> >> >> From volker.simonis at gmail.com Mon Jan 4 19:26:17 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Jan 2016 20:26:17 +0100 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <568AC6E0.9050807@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B5D306@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B60D9B@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> Message-ID: On Mon, Jan 4, 2016 at 8:24 PM, Alan Bateman wrote: > > > On 04/01/2016 18:43, Volker Simonis wrote: >> >> : >> Alan, what do you mean by "unknown" platform? Currently, as far as I >> know, 0x0200 is used by AIX and MacOS X. Do you suggest to name these >> platforms explicitly and set it to 0 otherwise? Leaving the default at >> 0x0200 has the advantage that it would implicitly work on other >> platforms like HPUX at the risk that it may be the wrong value on >> other, yet still unknown platforms. So in general I'm not against >> setting it to 0 on unknown platfroms (as this is the most secure >> setting) but in that case we should definitely name AIX and MacOS X as >> "known" platforms. > > My concern with defaulting to 0x0200 is that it might be used on a platform > where this is not the right value. Defaulting to 0 makes it easier to catch > the issue and allows us to includes assertion that the socket option is != > 0. If we build on versions of AIX and OSX that don't have SO_REUSEPORT > defined then it would be good to get those into the known platform list. > Agree! Lucy, please add the MacOs and AIX cases. No need to do it for HPUX as this is not an official OpenJDK platform yet (we'll do that in our internal port). Thanks, Volker > -Alan From yingqi.lu at intel.com Mon Jan 4 23:30:10 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Mon, 4 Jan 2016 23:30:10 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B5D306@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B60D9B@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> One more question, we tried to move the isReusePortAvailable() from SocketImpl.java to AbstractPlainSocketImpl.java. However, we found out the static block (attached below) inside the AbstractPlainSocketImpl.java never being executed when the AbstractPlainSocketImpl.isReusePortAvailable() is called which leads to an unsatisfiedlinkerror (net library is not loaded). We created a small testing java program which has an abstract class. The static block inside the abstract class is executed no problem at all. What did we miss here? static { java.security.AccessController.doPrivileged( new java.security.PrivilegedAction<>() { public Void run() { System.loadLibrary("net"); return null; } }); } Thanks, Lucy -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Monday, January 04, 2016 11:26 AM To: Alan Bateman Cc: Lu, Yingqi ; Kaczmarek, Eric ; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; net-dev at openjdk.java.net Subject: Re: Patch for adding SO_REUSEPORT socket option On Mon, Jan 4, 2016 at 8:24 PM, Alan Bateman wrote: > > > On 04/01/2016 18:43, Volker Simonis wrote: >> >> : >> Alan, what do you mean by "unknown" platform? Currently, as far as I >> know, 0x0200 is used by AIX and MacOS X. Do you suggest to name these >> platforms explicitly and set it to 0 otherwise? Leaving the default >> at >> 0x0200 has the advantage that it would implicitly work on other >> platforms like HPUX at the risk that it may be the wrong value on >> other, yet still unknown platforms. So in general I'm not against >> setting it to 0 on unknown platfroms (as this is the most secure >> setting) but in that case we should definitely name AIX and MacOS X >> as "known" platforms. > > My concern with defaulting to 0x0200 is that it might be used on a > platform where this is not the right value. Defaulting to 0 makes it > easier to catch the issue and allows us to includes assertion that the > socket option is != 0. If we build on versions of AIX and OSX that > don't have SO_REUSEPORT defined then it would be good to get those into the known platform list. > Agree! Lucy, please add the MacOs and AIX cases. No need to do it for HPUX as this is not an official OpenJDK platform yet (we'll do that in our internal port). Thanks, Volker > -Alan From mark.sheppard at oracle.com Tue Jan 5 00:54:24 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 5 Jan 2016 00:54:24 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <56877EFC.2000505@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> <5645DB41.8000704@oracle.com> <56853BED.2070007@oracle.com> <56877EFC.2000505@oracle.com> Message-ID: <568B1440.6040404@oracle.com> Hi, as per feedback below webrev has been updated http://cr.openjdk.java.net/~msheppar/8134577/webrev.06/ change summary: * List nameServices replaced with Nameservice nameService * references to nameServices removed * private interface NameService added, with two implementation PlatformNameService and HostsFileNameService * Scanner created with UTF-8 charset * removed StringTokenizer, replaced with String.split() * comment handling extended, handling comments on line with mapping entry * try with resources added to addMappingToHostsFile method in tests regards Mark On 02/01/2016 07:40, Alan Bateman wrote: > On 31/12/2015 14:30, Mark Sheppard wrote: >> Hi >> please oblige and review the current version of the fix for >> https://bugs.openjdk.java.net/browse/JDK-8134577 >> >> at >> http://cr.openjdk.java.net/~msheppar/8134577/webrev.05/ >> >> which is based on feedback from the second review. > I looked through the latest webrev and I think this is starting to > look good. Having the hosts file be the same format (albeit a subset) > as /etc/hosts is a big improvement on previous iterations. > > InetAddress.nameServices is still a List but the List > will always have one element, should this be changed to > InetAddress.nameService (singular)? > > I think it would be cleaner if NameService were changed to an > interface with two implementations, say PlatformNameService and > HostsFileNameService. That way you could eliminate the > useLocalHostsFileLookup and hostsFileName fields from InetAddress and > HostsFileNameService could encapsulate the parsing of the hosts file > rather than NameService trying to support both ways. > > The property name jdk.net.hosts.file is good but if set to a file that > doesn't exist then the current patch falls back to use the platform > name service. I assume this is not the original intention. > > The Scanner is created without specifying a charset, is this > deliberate because the platform /etc/hosts is in platform encoding? > For tests then it might be better to use UTF-8 because these hosts > file will be used on several different platforms. > > Is there any reason to use legacy StringTokenizer in > createAddressByteArray? In other areas of the patch then it using > Scanner or String.split so it seems inconsistent to see legacy > StringTokenizer in use too. > > You mentioned in the mail about # supported as a comment when the > first character. It doesn't seem to be much effort to just drop > everything after the # so that it is more consistent with the platform > hosts file. > > UHE is thrown in a few places without any exception message. For the > hosts file then it would be useful to include some message to make > configuration issues easier to diagnose. > > The comment in NameService has a historical reference to the JNDI DNS > provider, I assume that is not needed. > > I also looked through the test changes. Several tests set test.src and > not clear that this is needed. I assume that what you really want is: > String testSrc = System.getProperty("test.src", "."); > > addMappingToHostsFile is added to a number of tests. It would be good > if this could use try-with-resources to avoid leaving a file open then > the write fails (say a test machine with a full file system). > > sun/security/x509/URICertStore/ExtensionsWithLDAP.java has been added > to the exclude list with JDK-8134577 as the issue number. Is there is > a different issue number for this? > > Are all of the tests in test/sun/net/InetAddress/nameservice still > needed? Some of these tests, as least in the 'dns' directory, are > tests for the JNDI DNS provider and maybe they should be deleted. > > The update to KDC means that any test using this library will need to > run in othervm mode. That may be true already but we should check. > Related to this is that setting the system property in the main method > might be fragile in that it's possible for code to execute before the > main method that triggers the initialization of InetAddress. Something > to keep in mind as we might have to re-visit these tests again. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Tue Jan 5 04:32:06 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Tue, 5 Jan 2016 04:32:06 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B5D306@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B60D9B@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> Hi Alan/Volker, I just found out that the code works by adding the same static block (net library loading) into SocketImpl.java although isReusePortAvailable() is being defined in its subclass AbstractPlainSocketIml.java. I use a print statement to confirm that both static blocks from SocketImpl and AbstractSocketImpl are being executed. Is this a reasonable way to implement? Or, we can remove the block from AbstractPlainSocketImpl, only have it in SocketImpl if you think that is better. Please let us know. Thanks, Lucy -----Original Message----- From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Lu, Yingqi Sent: Monday, January 04, 2016 3:30 PM To: Volker Simonis ; Alan Bateman Cc: net-dev at openjdk.java.net; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; Kaczmarek, Eric Subject: RE: Patch for adding SO_REUSEPORT socket option One more question, we tried to move the isReusePortAvailable() from SocketImpl.java to AbstractPlainSocketImpl.java. However, we found out the static block (attached below) inside the AbstractPlainSocketImpl.java never being executed when the AbstractPlainSocketImpl.isReusePortAvailable() is called which leads to an unsatisfiedlinkerror (net library is not loaded). We created a small testing java program which has an abstract class. The static block inside the abstract class is executed no problem at all. What did we miss here? static { java.security.AccessController.doPrivileged( new java.security.PrivilegedAction<>() { public Void run() { System.loadLibrary("net"); return null; } }); } Thanks, Lucy -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Monday, January 04, 2016 11:26 AM To: Alan Bateman Cc: Lu, Yingqi ; Kaczmarek, Eric ; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; net-dev at openjdk.java.net Subject: Re: Patch for adding SO_REUSEPORT socket option On Mon, Jan 4, 2016 at 8:24 PM, Alan Bateman wrote: > > > On 04/01/2016 18:43, Volker Simonis wrote: >> >> : >> Alan, what do you mean by "unknown" platform? Currently, as far as I >> know, 0x0200 is used by AIX and MacOS X. Do you suggest to name these >> platforms explicitly and set it to 0 otherwise? Leaving the default >> at >> 0x0200 has the advantage that it would implicitly work on other >> platforms like HPUX at the risk that it may be the wrong value on >> other, yet still unknown platforms. So in general I'm not against >> setting it to 0 on unknown platfroms (as this is the most secure >> setting) but in that case we should definitely name AIX and MacOS X >> as "known" platforms. > > My concern with defaulting to 0x0200 is that it might be used on a > platform where this is not the right value. Defaulting to 0 makes it > easier to catch the issue and allows us to includes assertion that the > socket option is != 0. If we build on versions of AIX and OSX that > don't have SO_REUSEPORT defined then it would be good to get those into the known platform list. > Agree! Lucy, please add the MacOs and AIX cases. No need to do it for HPUX as this is not an official OpenJDK platform yet (we'll do that in our internal port). Thanks, Volker > -Alan From Alan.Bateman at oracle.com Tue Jan 5 13:10:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jan 2016 13:10:30 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <568B1440.6040404@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> <5645DB41.8000704@oracle.com> <56853BED.2070007@oracle.com> <56877EFC.2000505@oracle.com> <568B1440.6040404@oracle.com> Message-ID: <568BC0C6.4050600@oracle.com> On 05/01/2016 00:54, Mark Sheppard wrote: > Hi, > as per feedback below webrev has been updated > > http://cr.openjdk.java.net/~msheppar/8134577/webrev.06/ > > change summary: > > * List nameServices replaced with Nameservice nameService > > * references to nameServices removed > > * private interface NameService added, with two implementation > PlatformNameService and HostsFileNameService > > * Scanner created with UTF-8 charset > > * removed StringTokenizer, replaced with String.split() > > * comment handling extended, handling comments on line with mapping entry > > * try with resources added to addMappingToHostsFile method in tests I think this is starting to look good. A few small comments: - instantiateNameService (would createNameService be nicer?) still falls back to PlatformNameService when the hosts file doesn't exist. Is that expected? - HostsFileNameService.hostsFile can be final. - in removeComments then I assume you can just use indexOf and check for -1 rather than contains + indexOf. - it would be nice if NameService had some javadoc. Also the methods don't need to be declared public. - it would be nice if PlatformnameService and HostsFileNameService could use /** */ style javadoc rather than //, just to keep the code consistent. - ExtensionsWithLDAP.java is added to the exclude list with JDK-8134577, is there is separate issue for this? - formatting. There are a few places where the indention is messed up (5 spaces instead of 4 in a few places). Also some of the throws XXX are intended in many different ways. Blank lines can help readability but seem to be inconsistently used here. There's clearly been a lot of revisions on this issue and maybe the simplest is to just reformat this section of the file in the IDE. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 5 13:19:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jan 2016 13:19:21 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8A896@ORSMSX113.amr.corp.intel.com> Message-ID: <568BC2D9.4090005@oracle.com> On 04/01/2016 19:24, Volker Simonis wrote: > On Mon, Jan 4, 2016 at 8:02 PM, Lu, Yingqi wrote: >> : >> >> 2. Regarding to the code snippet in net_util_md.c, the reason I check for ENOPROTOOPT is to enable SO_REUSEPORT in the situation that the feature is supported but something else happens during setsocksopts call. I totally agree this is much less safer than just disable the feature whenever the setsockopts returns error. Alan, please let me know what your take on this is. I can quick change it if you both think it is more appropriate to remove the ENOPROTOOPT check. >> > I just think we should play safe here. You also return JNI_FALSE when > the call to socket() just before the one to setsockopt() fails. But > lets here what's Alan's opinion. > I agree, it makes it simpler too. -Alan From Alan.Bateman at oracle.com Tue Jan 5 15:59:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jan 2016 15:59:34 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> Message-ID: <568BE866.2060306@oracle.com> On 05/01/2016 04:32, Lu, Yingqi wrote: > Hi Alan/Volker, > > I just found out that the code works by adding the same static block (net library loading) into SocketImpl.java although isReusePortAvailable() is being defined in its subclass AbstractPlainSocketIml.java. I use a print statement to confirm that both static blocks from SocketImpl and AbstractSocketImpl are being executed. > > Is this a reasonable way to implement? Or, we can remove the block from AbstractPlainSocketImpl, only have it in SocketImpl if you think that is better. Please let us know. > I'm not sure that I understand the issue you are seeing. When a Socket is created then it will invoke setImpl to set the underlying SocketImpl and that should cause the configured SocketImpl to be loaded and initialize. Are you saying that the initializer isn't run? BTW: The reason for putting this into the concrete implementation of SocketImpl is that the Socket API is somewhat pluggable via the legacy (and probably rarely used) SocketImplFactory mechanism. This means that some SocketImpl implementations might know about the new socket options, some might not. -Alan From volker.simonis at gmail.com Tue Jan 5 16:10:38 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Jan 2016 17:10:38 +0100 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <568BC2D9.4090005@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8A896@ORSMSX113.amr.corp.intel.com> <568BC2D9.4090005@oracle.com> Message-ID: Hi Lucy, I've just looked at the javadoc of MulticastSocket. It has this sentence: * When the socket is created the * {@link DatagramSocket#setReuseAddress(boolean)} method is * called to enable the SO_REUSEADDR socket option. but it doesn't mention SO_REUSEPORT. Could you please add something similar for SO_REUSEPORT: * When the socket is created and SO_REUSPORT is supported the * {@link DatagramSocket#setOption(...)} method is * called to enable the SO_REUSPORT socket option. Thanks, Volker On Tue, Jan 5, 2016 at 2:19 PM, Alan Bateman wrote: > > > On 04/01/2016 19:24, Volker Simonis wrote: >> >> On Mon, Jan 4, 2016 at 8:02 PM, Lu, Yingqi wrote: >>> >>> : >>> >>> 2. Regarding to the code snippet in net_util_md.c, the reason I check for >>> ENOPROTOOPT is to enable SO_REUSEPORT in the situation that the feature is >>> supported but something else happens during setsocksopts call. I totally >>> agree this is much less safer than just disable the feature whenever the >>> setsockopts returns error. Alan, please let me know what your take on this >>> is. I can quick change it if you both think it is more appropriate to remove >>> the ENOPROTOOPT check. >>> >> I just think we should play safe here. You also return JNI_FALSE when >> the call to socket() just before the one to setsockopt() fails. But >> lets here what's Alan's opinion. >> > I agree, it makes it simpler too. > > -Alan From volker.simonis at gmail.com Tue Jan 5 17:49:33 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Jan 2016 18:49:33 +0100 Subject: RFR(XS): 8146482: [TESTBUG] java/net/SocketOption/OptionTest should only use multicast capable interfaces for multicast tests Message-ID: Hi, can somebody please review this small test fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8146482/ https://bugs.openjdk.java.net/browse/JDK-8146482 The java/net/SocketOption/OptionTest test chooses the first network interface returned by NetworkInterface.getNetworkInterfaces() for doing some tests on multicast sockets. But it may be that the chosen interface does not even support multicasting. So better iterate over all interfaces and only choose one if NetworkInterface.supportsMulticast() returns true. Thanks, Volker From yingqi.lu at intel.com Tue Jan 5 18:56:23 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Tue, 5 Jan 2016 18:56:23 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <568BE866.2060306@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B67A22@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> <568BE866.2060306@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA3B8F021@ORSMSX113.amr.corp.intel.com> Hi Alan, Sorry for the confusion. Let me be more detailed on the issue. In previous version of the patch, I added an initializer in SocketImpl.java to load the libnet.so since the isReusePortAvailable and its native implementation were there. Then, this time, I tried to move isReusePortAvailable and its native implementation declaration down to AbstractPlainSocketImpl therefore I removed the initializer block from SocketImpl.java as well. Inside AbstractPlainSocketImpl.java, there is already an initializer there by default to load the libnet.so. I was assuming it would just load the library and the code would work. However, I found out the initializer inside the AbstractPlainSocketimpl does not execute. After I add back the initializer to SocketImpl, the code works. My question is: Is this a reasonable approach to do it by keeping both initializers? Thanks very much for your help, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, January 05, 2016 8:00 AM To: Lu, Yingqi ; Volker Simonis Cc: net-dev at openjdk.java.net; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; Kaczmarek, Eric Subject: Re: Patch for adding SO_REUSEPORT socket option On 05/01/2016 04:32, Lu, Yingqi wrote: > Hi Alan/Volker, > > I just found out that the code works by adding the same static block (net library loading) into SocketImpl.java although isReusePortAvailable() is being defined in its subclass AbstractPlainSocketIml.java. I use a print statement to confirm that both static blocks from SocketImpl and AbstractSocketImpl are being executed. > > Is this a reasonable way to implement? Or, we can remove the block from AbstractPlainSocketImpl, only have it in SocketImpl if you think that is better. Please let us know. > I'm not sure that I understand the issue you are seeing. When a Socket is created then it will invoke setImpl to set the underlying SocketImpl and that should cause the configured SocketImpl to be loaded and initialize. Are you saying that the initializer isn't run? BTW: The reason for putting this into the concrete implementation of SocketImpl is that the Socket API is somewhat pluggable via the legacy (and probably rarely used) SocketImplFactory mechanism. This means that some SocketImpl implementations might know about the new socket options, some might not. -Alan From claes.redestad at oracle.com Tue Jan 5 22:47:45 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 05 Jan 2016 23:47:45 +0100 Subject: RFR: 8146526: Improve java.net.URI$Parser startup characteristics Message-ID: <568C4811.6040300@oracle.com> Hi, please review this patch to cleanup URI$Parser to help URI construction when run with the interpreter, mostly by inlining wrapping methods: Bug: https://bugs.openjdk.java.net/browse/JDK-8146526 Webrev: http://cr.openjdk.java.net/~redestad/8146526/webrev.01 This is motivated by Jigsaw where URIs might be created unconditionally during startup, and this trivial patch is extracted from an experiment to address observed inefficiencies in java.net.URI[1]. Around half the improvement detailed in [1] can be attributed to this patch, while it does not impact compiled code performance. Thanks! /Claes [1]http://cr.openjdk.java.net/~redestad/scratch/URIParserBench.java From brian.burkhalter at oracle.com Wed Jan 6 02:22:42 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 5 Jan 2016 18:22:42 -0800 Subject: RFC on 8146041: java.net.URLConnection.guessContentTypeFromStream() does not recognize TIFF streams Message-ID: This core-libs-dev RFR http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037847.html was already approved on core-libs-dev but I would like to make sure there is no objection from the net-dev community. Thanks, Brian From felix.yang at oracle.com Wed Jan 6 05:09:34 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 6 Jan 2016 13:09:34 +0800 Subject: RFR 8140472/9, java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use In-Reply-To: <566E6759.4090607@oracle.com> References: <566E6759.4090607@oracle.com> Message-ID: <568CA18E.6050904@oracle.com> Hi all, please review the fix for java/net/ipv6tests/TcpTest.java, which replaces hard-coded ports with dynamic free ports on runtime. Bug: https://bugs.openjdk.java.net/browse/JDK-8140472 Webrev: http://cr.openjdk.java.net/~xiaofeya/8140472/webrev.00 Thanks, Felix From chris.hegarty at oracle.com Wed Jan 6 05:49:40 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Jan 2016 05:49:40 +0000 Subject: RFR 8140472/9, java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use In-Reply-To: <568CA18E.6050904@oracle.com> References: <566E6759.4090607@oracle.com> <568CA18E.6050904@oracle.com> Message-ID: <1C80CB8B-E48A-4902-919A-55C54EE677CB@oracle.com> Hi Felix, On 6 Jan 2016, at 05:09, Felix Yang wrote: > Hi all, > please review the fix for java/net/ipv6tests/TcpTest.java, which replaces hard-coded ports with dynamic free ports on runtime. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140472 > Webrev: http://cr.openjdk.java.net/~xiaofeya/8140472/webrev.00 Ooh, I wasn?t aware that the getFreePort ( open and close a ServerSocket on an ephemeral port quickly, then assume that that ephemeral port is ?available" ) was still in use. It has been shown to be unstable in other test areas, namely rmi. I don?t think that we should use it here. From my perspective I don?t see that the specific cases that use hard-coded ports are all that useful. Maybe they should just be removed, if they are causing problems. -Chris. From chris.hegarty at oracle.com Wed Jan 6 06:14:03 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Jan 2016 06:14:03 +0000 Subject: RFC on 8146041: java.net.URLConnection.guessContentTypeFromStream() does not recognize TIFF streams In-Reply-To: References: Message-ID: <64EB5075-0FAA-494B-9C31-A2813770A6A3@oracle.com> On 6 Jan 2016, at 02:22, Brian Burkhalter wrote: > This core-libs-dev RFR > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037847.html > > was already approved on core-libs-dev but I would like to make sure there is no objection from the net-dev community. No objections from me Brian. This looks fine. -Chris. From chris.hegarty at oracle.com Wed Jan 6 06:49:34 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Jan 2016 06:49:34 +0000 Subject: RFR: 8146526: Improve java.net.URI$Parser startup characteristics In-Reply-To: <568C4811.6040300@oracle.com> References: <568C4811.6040300@oracle.com> Message-ID: <69BA9D70-8ABC-4D18-A7C5-BC9D2E3C2876@oracle.com> On 5 Jan 2016, at 22:47, Claes Redestad wrote: > Hi, > > please review this patch to cleanup URI$Parser to help URI construction when run with the interpreter, mostly by inlining wrapping methods: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146526 > > Webrev: http://cr.openjdk.java.net/~redestad/8146526/webrev.01 This looks like a nice straight forward cleanup/change. Thanks Claes. > This is motivated by Jigsaw where URIs might be created unconditionally during startup, and this trivial patch is extracted from an experiment to address observed inefficiencies in java.net.URI[1]. Around half the improvement detailed in [1] can be attributed to this patch, while it does not impact compiled code performance. Good to hear. -Chris. > Thanks! > > /Claes > > [1]http://cr.openjdk.java.net/~redestad/scratch/URIParserBench.java From chris.hegarty at oracle.com Wed Jan 6 06:58:55 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Jan 2016 06:58:55 +0000 Subject: RFR(XS): 8146482: [TESTBUG] java/net/SocketOption/OptionTest should only use multicast capable interfaces for multicast tests In-Reply-To: References: Message-ID: <2B3B3E3B-3D07-4635-B7C2-63D9820280AA@oracle.com> Hi Volker, On 5 Jan 2016, at 17:49, Volker Simonis wrote: > Hi, > > can somebody please review this small test fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8146482/ > https://bugs.openjdk.java.net/browse/JDK-8146482 This change looks good to me. -Chris. > The java/net/SocketOption/OptionTest test chooses the first network > interface returned by NetworkInterface.getNetworkInterfaces() for > doing some tests on multicast sockets. > > But it may be that the chosen interface does not even support > multicasting. So better iterate over all interfaces and only choose > one if NetworkInterface.supportsMulticast() returns true. > > Thanks, > Volker From Alan.Bateman at oracle.com Wed Jan 6 07:43:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Jan 2016 07:43:48 +0000 Subject: RFR: 8146526: Improve java.net.URI$Parser startup characteristics In-Reply-To: <568C4811.6040300@oracle.com> References: <568C4811.6040300@oracle.com> Message-ID: <568CC5B4.40005@oracle.com> On 05/01/2016 22:47, Claes Redestad wrote: > Hi, > > please review this patch to cleanup URI$Parser to help URI > construction when run with the interpreter, mostly by inlining > wrapping methods: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146526 > > Webrev: http://cr.openjdk.java.net/~redestad/8146526/webrev.01 This looks good to me. -Alan From felix.yang at oracle.com Wed Jan 6 08:27:18 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 6 Jan 2016 16:27:18 +0800 Subject: RFR 8140472/9, java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use In-Reply-To: <1C80CB8B-E48A-4902-919A-55C54EE677CB@oracle.com> References: <566E6759.4090607@oracle.com> <568CA18E.6050904@oracle.com> <1C80CB8B-E48A-4902-919A-55C54EE677CB@oracle.com> Message-ID: <568CCFE6.3030009@oracle.com> Hi Chris, updated webrev with your suggestion: http://cr.openjdk.java.net/~xiaofeya/8140472/webrev.01/ Thanks, Felix On 2016/1/6 13:49, Chris Hegarty wrote: > Hi Felix, > > On 6 Jan 2016, at 05:09, Felix Yang wrote: > >> Hi all, >> please review the fix for java/net/ipv6tests/TcpTest.java, which replaces hard-coded ports with dynamic free ports on runtime. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8140472 >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8140472/webrev.00 > Ooh, I wasn?t aware that the getFreePort ( open and close a ServerSocket > on an ephemeral port quickly, then assume that that ephemeral port is > ?available" ) was still in use. It has been shown to be unstable in other test > areas, namely rmi. I don?t think that we should use it here. > > From my perspective I don?t see that the specific cases that use hard-coded > ports are all that useful. Maybe they should just be removed, if they are > causing problems. > > -Chris. From chris.hegarty at oracle.com Wed Jan 6 09:56:46 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Jan 2016 09:56:46 +0000 Subject: RFR 8140472/9, java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use In-Reply-To: <568CCFE6.3030009@oracle.com> References: <566E6759.4090607@oracle.com> <568CA18E.6050904@oracle.com> <1C80CB8B-E48A-4902-919A-55C54EE677CB@oracle.com> <568CCFE6.3030009@oracle.com> Message-ID: <568CE4DE.8020408@oracle.com> Thank Felix. On 06/01/16 08:27, Felix Yang wrote: > Hi Chris, > updated webrev with your suggestion: > http://cr.openjdk.java.net/~xiaofeya/8140472/webrev.01/ These changes look ok to me. Trivially, I'd drop the addition of the bugId from the @bug tag, since the test is not exercising 8140472 ( it is a bug in the test itself ). -Chris. > Thanks, > Felix > On 2016/1/6 13:49, Chris Hegarty wrote: >> Hi Felix, >> >> On 6 Jan 2016, at 05:09, Felix Yang wrote: >> >>> Hi all, >>> please review the fix for java/net/ipv6tests/TcpTest.java, which >>> replaces hard-coded ports with dynamic free ports on runtime. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140472 >>> Webrev: http://cr.openjdk.java.net/~xiaofeya/8140472/webrev.00 >> Ooh, I wasn?t aware that the getFreePort ( open and close a ServerSocket >> on an ephemeral port quickly, then assume that that ephemeral port is >> ?available" ) was still in use. It has been shown to be unstable in >> other test >> areas, namely rmi. I don?t think that we should use it here. >> From my perspective I don?t see that the specific cases that use >> hard-coded >> ports are all that useful. Maybe they should just be removed, if they are >> causing problems. >> >> -Chris. > From Alan.Bateman at oracle.com Wed Jan 6 15:37:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Jan 2016 15:37:42 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA3B8F021@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> <568BE866.2060306@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8F021@ORSMSX113.amr.corp.intel.com> Message-ID: <568D34C6.3030802@oracle.com> On 05/01/2016 18:56, Lu, Yingqi wrote: > Hi Alan, > > Sorry for the confusion. Let me be more detailed on the issue. > > In previous version of the patch, I added an initializer in SocketImpl.java to load the libnet.so since the isReusePortAvailable and its native implementation were there. Then, this time, I tried to move isReusePortAvailable and its native implementation declaration down to AbstractPlainSocketImpl therefore I removed the initializer block from SocketImpl.java as well. Inside AbstractPlainSocketImpl.java, there is already an initializer there by default to load the libnet.so. I was assuming it would just load the library and the code would work. However, I found out the initializer inside the AbstractPlainSocketimpl does not execute. After I add back the initializer to SocketImpl, the code works. > > My question is: Is this a reasonable approach to do it by keeping both initializers? > > Thanks very much for your help, > Lucy > When you updated AbstractPlainSocketImpl then is the new initializer before or after the current initializer? They run in declaration order so I'm wondering if this is the issue you are running into. -Alan From mark.sheppard at oracle.com Wed Jan 6 15:37:13 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 6 Jan 2016 15:37:13 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <568BC0C6.4050600@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> <5645DB41.8000704@oracle.com> <56853BED.2070007@oracle.com> <56877EFC.2000505@oracle.com> <568B1440.6040404@oracle.com> <568BC0C6.4050600@oracle.com> Message-ID: <568D34A9.5020703@oracle.com> thanks for the feedback, Alan based on suggestions, all issues have been addressed and patch has been updated http://cr.openjdk.java.net/~msheppar/8134577/webrev.07 the following should be noted: ExtensionsWithLDAP.java is added to the exclude list with JDK-8134577 - This is on the problem list as it will need to be re-written The NameService associated with this test threw UnknownHostExceptions and added the host name to a List, which was then examined later in the test as a verification. The instantiation of a NameService is as intended, i.e. if jdk.net.hosts.file set and file exist then instantiate HostsFileNameService else instantiate PlatformNameService this is in keeping with previous initialization semantics - if the no service provider NameService created then the default NameService was instantiated. regards Mark On 05/01/2016 13:10, Alan Bateman wrote: > On 05/01/2016 00:54, Mark Sheppard wrote: >> Hi, >> as per feedback below webrev has been updated >> >> http://cr.openjdk.java.net/~msheppar/8134577/webrev.06/ >> >> change summary: >> >> * List nameServices replaced with Nameservice nameService >> >> * references to nameServices removed >> >> * private interface NameService added, with two implementation >> PlatformNameService and HostsFileNameService >> >> * Scanner created with UTF-8 charset >> >> * removed StringTokenizer, replaced with String.split() >> >> * comment handling extended, handling comments on line with mapping entry >> >> * try with resources added to addMappingToHostsFile method in tests > > I think this is starting to look good. > > A few small comments: > > - instantiateNameService (would createNameService be nicer?) still > falls back to PlatformNameService when the hosts file doesn't exist. > Is that expected? > > - HostsFileNameService.hostsFile can be final. > > - in removeComments then I assume you can just use indexOf and check > for -1 rather than contains + indexOf. > > - it would be nice if NameService had some javadoc. Also the methods > don't need to be declared public. > > - it would be nice if PlatformnameService and HostsFileNameService > could use /** */ style javadoc rather than //, just to keep the code > consistent. > > - ExtensionsWithLDAP.java is added to the exclude list with > JDK-8134577, is there is separate issue for this? > > - formatting. There are a few places where the indention is messed up > (5 spaces instead of 4 in a few places). Also some of the throws XXX > are intended in many different ways. Blank lines can help readability > but seem to be inconsistently used here. There's clearly been a lot of > revisions on this issue and maybe the simplest is to just reformat > this section of the file in the IDE. > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Jan 6 19:42:25 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 06 Jan 2016 20:42:25 +0100 Subject: RFR: 8146526: Improve java.net.URI$Parser startup characteristics In-Reply-To: <568CC5B4.40005@oracle.com> References: <568C4811.6040300@oracle.com> <568CC5B4.40005@oracle.com> Message-ID: <568D6E21.1080405@oracle.com> On 2016-01-06 08:43, Alan Bateman wrote: > On 05/01/2016 22:47, Claes Redestad wrote: >> Hi, >> >> please review this patch to cleanup URI$Parser to help URI >> construction when run with the interpreter, mostly by inlining >> wrapping methods: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146526 >> >> Webrev: http://cr.openjdk.java.net/~redestad/8146526/webrev.01 > This looks good to me. Thanks for looking at this, Alan and Chris! /Claes From Alan.Bateman at oracle.com Wed Jan 6 20:37:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Jan 2016 20:37:20 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <568D34A9.5020703@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> <5645DB41.8000704@oracle.com> <56853BED.2070007@oracle.com> <56877EFC.2000505@oracle.com> <568B1440.6040404@oracle.com> <568BC0C6.4050600@oracle.com> <568D34A9.5020703@oracle.com> Message-ID: <568D7B00.7040405@oracle.com> On 06/01/2016 15:37, Mark Sheppard wrote: > thanks for the feedback, Alan > > based on suggestions, all issues have been addressed and patch has > been updated > > http://cr.openjdk.java.net/~msheppar/8134577/webrev.07 > > the following should be noted: > > ExtensionsWithLDAP.java is added to the exclude list with JDK-8134577 > - This is on the problem list as it will need to be re-written > The NameService associated with this test threw UnknownHostExceptions > and added the host name to a List, which was then examined > later in the test as a verification. > > The instantiation of a NameService is as intended, i.e. > if jdk.net.hosts.file set and file exist then > instantiate HostsFileNameService > else > instantiate PlatformNameService > > this is in keeping with previous initialization semantics - if the no > service provider NameService > created then the default NameService was instantiated. I think this looks quite good. If jdk.net.hosts.file is set to a file that doesn't exist then I think it should throw an exception or else just work as if the hosts file is empty. However, it's probably not worth spending time on as this mechanism is mostly for tests. There is still a reference to the JNDI-DNS provider in HostsFileNameService and I assume that should be removed as it's essentially a historical reference now. I assume InetAddress.impl can be changed to be final. For ExtensionsWithLDAP.java then you need to create an issue to track it and use that issue number when adding it to the exclude list. I think that is all I have on this topic. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.yang at oracle.com Thu Jan 7 06:16:29 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 7 Jan 2016 14:16:29 +0800 Subject: RFR 8140472/9, java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use In-Reply-To: <568CE4DE.8020408@oracle.com> References: <566E6759.4090607@oracle.com> <568CA18E.6050904@oracle.com> <1C80CB8B-E48A-4902-919A-55C54EE677CB@oracle.com> <568CCFE6.3030009@oracle.com> <568CE4DE.8020408@oracle.com> Message-ID: <568E02BD.3030906@oracle.com> Thanks Chris! I will remove bug id as you suggested. TO Frank, could you sponsor the fix? Thanks, Felix On 2016/1/6 17:56, Chris Hegarty wrote: > Thank Felix. > > On 06/01/16 08:27, Felix Yang wrote: >> Hi Chris, >> updated webrev with your suggestion: >> http://cr.openjdk.java.net/~xiaofeya/8140472/webrev.01/ > > These changes look ok to me. > > Trivially, I'd drop the addition of the bugId from the @bug tag, > since the test is not exercising 8140472 ( it is a bug in the > test itself ). > > -Chris. > >> Thanks, >> Felix >> On 2016/1/6 13:49, Chris Hegarty wrote: >>> Hi Felix, >>> >>> On 6 Jan 2016, at 05:09, Felix Yang wrote: >>> >>>> Hi all, >>>> please review the fix for java/net/ipv6tests/TcpTest.java, which >>>> replaces hard-coded ports with dynamic free ports on runtime. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140472 >>>> Webrev: http://cr.openjdk.java.net/~xiaofeya/8140472/webrev.00 >>> Ooh, I wasn?t aware that the getFreePort ( open and close a >>> ServerSocket >>> on an ephemeral port quickly, then assume that that ephemeral port is >>> ?available" ) was still in use. It has been shown to be unstable in >>> other test >>> areas, namely rmi. I don?t think that we should use it here. >>> From my perspective I don?t see that the specific cases that use >>> hard-coded >>> ports are all that useful. Maybe they should just be removed, if >>> they are >>> causing problems. >>> >>> -Chris. >> From mark.sheppard at oracle.com Thu Jan 7 10:44:05 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 7 Jan 2016 10:44:05 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <568D7B00.7040405@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> <5645DB41.8000704@oracle.com> <56853BED.2070007@oracle.com> <56877EFC.2000505@oracle.com> <568B1440.6040404@oracle.com> <568BC0C6.4050600@oracle.com> <568D34A9.5020703@oracle.com> <568D7B00.7040405@oracle.com> Message-ID: <568E4175.3090807@oracle.com> again thanks for the review and feedback, Alan patch amended as suggested http://cr.openjdk.java.net/~msheppar/8134577/webrev.08/ removed File.exists test in createNameService - lookup methods in HostsFileNameService already throw UHE for FileNotFoundException InetAddress.impl marked final removed references to JNDI added test for non-existent hosts file regards Mark On 06/01/2016 20:37, Alan Bateman wrote: > On 06/01/2016 15:37, Mark Sheppard wrote: >> thanks for the feedback, Alan >> >> based on suggestions, all issues have been addressed and patch has >> been updated >> >> http://cr.openjdk.java.net/~msheppar/8134577/webrev.07 >> >> the following should be noted: >> >> ExtensionsWithLDAP.java is added to the exclude list with JDK-8134577 >> - This is on the problem list as it will need to be re-written >> The NameService associated with this test threw UnknownHostExceptions >> and added the host name to a List, which was then examined >> later in the test as a verification. >> >> The instantiation of a NameService is as intended, i.e. >> if jdk.net.hosts.file set and file exist then >> instantiate HostsFileNameService >> else >> instantiate PlatformNameService >> >> this is in keeping with previous initialization semantics - if the no >> service provider NameService >> created then the default NameService was instantiated. > I think this looks quite good. > > If jdk.net.hosts.file is set to a file that doesn't exist then I think > it should throw an exception or else just work as if the hosts file is > empty. However, it's probably not worth spending time on as this > mechanism is mostly for tests. > > There is still a reference to the JNDI-DNS provider in > HostsFileNameService and I assume that should be removed as it's > essentially a historical reference now. > > I assume InetAddress.impl can be changed to be final. > > For ExtensionsWithLDAP.java then you need to create an issue to track > it and use that issue number when adding it to the exclude list. > > I think that is all I have on this topic. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Jan 7 15:38:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Jan 2016 15:38:20 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <568E4175.3090807@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> <5645DB41.8000704@oracle.com> <56853BED.2070007@oracle.com> <56877EFC.2000505@oracle.com> <568B1440.6040404@oracle.com> <568BC0C6.4050600@oracle.com> <568D34A9.5020703@oracle.com> <568D7B00.7040405@oracle.com> <568E4175.3090807@oracle.com> Message-ID: <568E866C.9080104@oracle.com> On 07/01/2016 10:44, Mark Sheppard wrote: > again thanks for the review and feedback, Alan > > patch amended as suggested > http://cr.openjdk.java.net/~msheppar/8134577/webrev.08/ > > removed File.exists test in createNameService - lookup methods in > HostsFileNameService already throw UHE for FileNotFoundException > > InetAddress.impl marked final > > removed references to JNDI > > added test for non-existent hosts file > I think InetAddress looks okay now. At some point we should do some clean-up on this code but I think it's okay for now. Before you push this then can you create a bug to track the issue with ExtensionsWithLDAP.java and put that issue number in the exclude list? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Thu Jan 7 16:41:16 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Thu, 7 Jan 2016 16:41:16 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <568D34C6.3030802@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B67CC1@ORSMSX113.amr.corp.intel.com> <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> <568BE866.2060306@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8F021@ORSMSX113.amr.corp.intel.com> <568D34C6.3030802@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA3B923AF@ORSMSX113.amr.corp.intel.com> Hi Alan, In AbstractPlainSocketImpl, I am using the existing/default initializer so that there is only 1 initializer. However, it does not execute. That is the issue I am seeing. Any suggestion on the issue? Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Wednesday, January 06, 2016 7:38 AM To: Lu, Yingqi ; Volker Simonis Cc: net-dev at openjdk.java.net; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; Kaczmarek, Eric Subject: Re: Patch for adding SO_REUSEPORT socket option On 05/01/2016 18:56, Lu, Yingqi wrote: > Hi Alan, > > Sorry for the confusion. Let me be more detailed on the issue. > > In previous version of the patch, I added an initializer in SocketImpl.java to load the libnet.so since the isReusePortAvailable and its native implementation were there. Then, this time, I tried to move isReusePortAvailable and its native implementation declaration down to AbstractPlainSocketImpl therefore I removed the initializer block from SocketImpl.java as well. Inside AbstractPlainSocketImpl.java, there is already an initializer there by default to load the libnet.so. I was assuming it would just load the library and the code would work. However, I found out the initializer inside the AbstractPlainSocketimpl does not execute. After I add back the initializer to SocketImpl, the code works. > > My question is: Is this a reasonable approach to do it by keeping both initializers? > > Thanks very much for your help, > Lucy > When you updated AbstractPlainSocketImpl then is the new initializer before or after the current initializer? They run in declaration order so I'm wondering if this is the issue you are running into. -Alan From Alan.Bateman at oracle.com Thu Jan 7 17:55:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Jan 2016 17:55:33 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA3B923AF@ORSMSX113.amr.corp.intel.com> References: <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> <568BE866.2060306@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8F021@ORSMSX113.amr.corp.intel.com> <568D34C6.3030802@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B923AF@ORSMSX113.amr.corp.intel.com> Message-ID: <568EA695.2050201@oracle.com> On 07/01/2016 16:41, Lu, Yingqi wrote: > Hi Alan, > > In AbstractPlainSocketImpl, I am using the existing/default initializer so that there is only 1 initializer. However, it does not execute. That is the issue I am seeing. > > Any suggestion on the issue? > Are you 100% sure that your updated AbstractPlainSocketImpl is included in the build? I just did a quick check to add Thread.dumpStack() into that initializer and I see it running when creating a Socket or ServerSocket. I believe each of the platform implementations extend AbstractPlainSocketImpl so you should see it running on all platforms. -Alan From felix.yang at oracle.com Fri Jan 8 08:36:07 2016 From: felix.yang at oracle.com (Felix Yang) Date: Fri, 8 Jan 2016 16:36:07 +0800 Subject: RFR 8133704/9, java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java may fail with address already in use In-Reply-To: <568CA18E.6050904@oracle.com> References: <568CA18E.6050904@oracle.com> Message-ID: <568F74F7.70100@oracle.com> Hi all, please review the fix for java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java Bug: https://bugs.openjdk.java.net/browse/JDK-8133704 Webrev: http://cr.openjdk.java.net/~xiaofeya/8133704/webrev.00 It is using hard-coded port 4445 for the server side. This fix updates the test to use a port number that is automatically allocated. Thanks, Felix From chris.hegarty at oracle.com Fri Jan 8 14:08:26 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 8 Jan 2016 14:08:26 +0000 Subject: RFR 8133704/9, java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java may fail with address already in use In-Reply-To: <568F74F7.70100@oracle.com> References: <568CA18E.6050904@oracle.com> <568F74F7.70100@oracle.com> Message-ID: <568FC2DA.2080307@oracle.com> Hi Felix, On 08/01/16 08:36, Felix Yang wrote: > Hi all, > please review the fix for > java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133704 > Webrev: http://cr.openjdk.java.net/~xiaofeya/8133704/webrev.00 This looks good. I think 'port' can be final ( rather than volatile ), as can 'socket'. No need to regenerate the webrev. -Chris. > It is using hard-coded port 4445 for the server side. This fix updates > the test to use a port number that is automatically allocated. > > Thanks, > Felix From claes.redestad at oracle.com Fri Jan 8 14:41:17 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 8 Jan 2016 15:41:17 +0100 Subject: RFR: 8146686: Create the schemeSpecificPart for non-opaque URIs lazily Message-ID: <568FCA8D.4020604@oracle.com> Hi, please review this patch to lazily create schemeSpecificPart for non-opaque URIs. This change accounts for some improvement in footprint characteristics and a 10-20% improvement on URI creation microbenchmarks, while not regressing notably on a targetted microbenchmark which explicitly generate and retrieve the schemeSpecificPart. Bug: https://bugs.openjdk.java.net/browse/JDK-8146686 Webrev: http://cr.openjdk.java.net/~redestad/8146686/webrev.01/ Thanks! /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jan 8 15:34:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Jan 2016 15:34:17 +0000 Subject: RFR: 8146686: Create the schemeSpecificPart for non-opaque URIs lazily In-Reply-To: <568FCA8D.4020604@oracle.com> References: <568FCA8D.4020604@oracle.com> Message-ID: <568FD6F9.2030401@oracle.com> On 08/01/2016 14:41, Claes Redestad wrote: > Hi, > > please review this patch to lazily create schemeSpecificPart for > non-opaque URIs. This change accounts for some improvement in > footprint characteristics and a 10-20% improvement on URI creation > microbenchmarks, while not regressing notably on a targetted > microbenchmark which explicitly generate and retrieve the > schemeSpecificPart. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146686 > Webrev: http://cr.openjdk.java.net/~redestad/8146686/webrev.01/ This looks okay to me. The only thing that I wonder about is the original code returning null when getRawSchemeSpecificPart is specified to never return null. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Fri Jan 8 16:15:24 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 8 Jan 2016 17:15:24 +0100 Subject: RFR: 8146686: Create the schemeSpecificPart for non-opaque URIs lazily In-Reply-To: <568FD6F9.2030401@oracle.com> References: <568FCA8D.4020604@oracle.com> <568FD6F9.2030401@oracle.com> Message-ID: <568FE09C.603@oracle.com> On 2016-01-08 16:34, Alan Bateman wrote: > > > On 08/01/2016 14:41, Claes Redestad wrote: >> Hi, >> >> please review this patch to lazily create schemeSpecificPart for >> non-opaque URIs. This change accounts for some improvement in >> footprint characteristics and a 10-20% improvement on URI creation >> microbenchmarks, while not regressing notably on a targetted >> microbenchmark which explicitly generate and retrieve the >> schemeSpecificPart. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146686 >> Webrev: http://cr.openjdk.java.net/~redestad/8146686/webrev.01/ > This looks okay to me. The only thing that I wonder about is the > original code returning null when getRawSchemeSpecificPart is > specified to never return null. Yes, I think that can't ever happen for any valid URI since during parse either schemeSpecificPart or path will be set to a non-null value. I propagated this confusion in one of the recent patches to be semantically identical with the legacy implementation. /Claes > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Sun Jan 10 09:39:09 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 10 Jan 2016 09:39:09 +0000 Subject: RFR: 8146686: Create the schemeSpecificPart for non-opaque URIs lazily In-Reply-To: <568FCA8D.4020604@oracle.com> References: <568FCA8D.4020604@oracle.com> Message-ID: On 8 Jan 2016, at 14:41, Claes Redestad wrote: > Hi, > > please review this patch to lazily create schemeSpecificPart for non-opaque URIs. This change accounts for some improvement in footprint characteristics and a 10-20% improvement on URI creation microbenchmarks, while not regressing notably on a targetted microbenchmark which explicitly generate and retrieve the schemeSpecificPart. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146686 > Webrev: http://cr.openjdk.java.net/~redestad/8146686/webrev.01/ Looks ok to me Claes. -Chris. > Thanks! > > /Claes From claes.redestad at oracle.com Sun Jan 10 13:14:47 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 10 Jan 2016 14:14:47 +0100 Subject: RFR: 8146686: Create the schemeSpecificPart for non-opaque URIs lazily In-Reply-To: References: <568FCA8D.4020604@oracle.com> Message-ID: <56925947.70309@oracle.com> On 2016-01-10 10:39, Chris Hegarty wrote: > On 8 Jan 2016, at 14:41, Claes Redestad wrote: > >> Hi, >> >> please review this patch to lazily create schemeSpecificPart for non-opaque URIs. This change accounts for some improvement in footprint characteristics and a 10-20% improvement on URI creation microbenchmarks, while not regressing notably on a targetted microbenchmark which explicitly generate and retrieve the schemeSpecificPart. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146686 >> Webrev: http://cr.openjdk.java.net/~redestad/8146686/webrev.01/ > Looks ok to me Claes. > > -Chris. Thanks for reviews, Chris and Alan! /Claes From felix.yang at oracle.com Mon Jan 11 08:40:34 2016 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 11 Jan 2016 16:40:34 +0800 Subject: RFR 8133704/9, java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java may fail with address already in use In-Reply-To: <568FC2DA.2080307@oracle.com> References: <568CA18E.6050904@oracle.com> <568F74F7.70100@oracle.com> <568FC2DA.2080307@oracle.com> Message-ID: <56936A82.3050709@oracle.com> Hi Chris, thank you very much! -Felix On 2016/1/8 22:08, Chris Hegarty wrote: > Hi Felix, > > On 08/01/16 08:36, Felix Yang wrote: >> Hi all, >> please review the fix for >> java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8133704 >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8133704/webrev.00 > > This looks good. I think 'port' can be final ( rather than > volatile ), as can 'socket'. No need to regenerate the webrev. > > -Chris. > >> It is using hard-coded port 4445 for the server side. This fix updates >> the test to use a port number that is automatically allocated. >> >> Thanks, >> Felix From svetlana.nikandrova at oracle.com Wed Jan 13 15:48:11 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Wed, 13 Jan 2016 18:48:11 +0300 Subject: RFR [9] 8143554: UnsupportedOperationException is not thrown for unsupported options In-Reply-To: <56839299.1060008@oracle.com> References: <56603E51.2040202@oracle.com> <5666CEE3.6010805@oracle.com> <5666D363.5020707@oracle.com> <5666DEBF.7050005@oracle.com> <5666E05D.10006@oracle.com> <56748961.7010602@oracle.com> <567A83FD.9070700@oracle.com> <56839299.1060008@oracle.com> Message-ID: <569671BB.4020908@oracle.com> Alan, thank you for you replay. Here is my updated webrev with formatting fixes. http://cr.openjdk.java.net/~kshefov/8143554/webrev.03/ About getSocket() check - you are right, it is because there are Socket options unsupported by ServerSocket. Thank you, Svetlana On 30.12.2015 11:15, Alan Bateman wrote: > > The update to PlainSocketImpl and PlainDatagramSocketImpl look okay, > just a minor nit that "if(" should be "if (" to keep the code consistent. > > For SocketImpl then I assume the getSocket() check is because these > are Socket rather than ServerSocket options. > > There are few formatting issues in the test that would be good to fix > up before this is pushed, otherwise the test looks okay to me. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.yang at oracle.com Thu Jan 14 06:07:22 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 14 Jan 2016 14:07:22 +0800 Subject: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently In-Reply-To: <568F74F7.70100@oracle.com> References: <568F74F7.70100@oracle.com> Message-ID: <56973B1A.30000@oracle.com> Hi all, please review the fix for test/java/net/SocketPermission/SocketPermissionTest.java, which fails frequently with "java.net.BindException: Address already in use". Bug: https://bugs.openjdk.java.net/browse/JDK-8065076 Webrev: http://cr.openjdk.java.net/~xiaofeya/8065076/webrev.00 The test uses getFreePort() test util library to verify permission on specific "host:port". This fix added retries to avoid possible binding failures: 1. A port may be still occupied for a short moment after socket close. 2. Another application is possible to occupy the same port during the short time window of open-close-reuse. This has been observed in experimental test runs. Thanks, Felix From yingqi.lu at intel.com Thu Jan 14 18:28:06 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Thu, 14 Jan 2016 18:28:06 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <568EA695.2050201@oracle.com> References: <5665F388.1090904@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B68849@ORSMSX113.amr.corp.intel.com> <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> <568BE866.2060306@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8F021@ORSMSX113.amr.corp.intel.com> <568D34C6.3030802@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B923AF@ORSMSX113.amr.corp.intel.com> <568EA695.2050201@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA3B9C7E6@ORSMSX113.amr.corp.intel.com> Hi Alan/Michael/Volker, Here is the link to the version 7 of the patch. http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.07/ Please note: after the code has been uploaded, I found out I forgot to remove extra check of ENOPROTOOPT in the net_util_md.c. Since it took us couple days to upload the code each time, I think it might be a good idea to mark this as an open item for now. I will change it in next version for sure together with anything you found in the current version. In this version, we have addressed following items. Please let us know your comments and feedback. 1. Define SO_REUSEPORT to 0x0200 for AIX and OSX. Define SO_REUSEPORT to 0 on Windows and other unknown platforms. 2. genSocketOptionRegistry.c emits a definition on all platforms. 3. Move isReusePortAvailable function from SocketImpl to AbstractPlainSocketImpl. 4. Added comments for SO_REUSEPORT in MulticastSocket.java. 5. Add @since 9 to SocketOptions.SO_REUSEPORT. 6. Corrected indentation for AbstractPlainDatagramSocketImpl. 7. Removed initialization to volatile boolean variables. 8. Added #ifdef SO_REUSEPORT to SdpSupport.convert0. 9. Added space to comments //SO...... to make it consistent with the rest of the code. Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Thursday, January 07, 2016 9:56 AM To: Lu, Yingqi ; Volker Simonis Cc: net-dev at openjdk.java.net; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; Kaczmarek, Eric Subject: Re: Patch for adding SO_REUSEPORT socket option On 07/01/2016 16:41, Lu, Yingqi wrote: > Hi Alan, > > In AbstractPlainSocketImpl, I am using the existing/default initializer so that there is only 1 initializer. However, it does not execute. That is the issue I am seeing. > > Any suggestion on the issue? > Are you 100% sure that your updated AbstractPlainSocketImpl is included in the build? I just did a quick check to add Thread.dumpStack() into that initializer and I see it running when creating a Socket or ServerSocket. I believe each of the platform implementations extend AbstractPlainSocketImpl so you should see it running on all platforms. -Alan From Alan.Bateman at oracle.com Fri Jan 15 12:29:16 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jan 2016 12:29:16 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA3B9C7E6@ORSMSX113.amr.corp.intel.com> References: <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> <568BE866.2060306@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8F021@ORSMSX113.amr.corp.intel.com> <568D34C6.3030802@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B923AF@ORSMSX113.amr.corp.intel.com> <568EA695.2050201@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B9C7E6@ORSMSX113.amr.corp.intel.com> Message-ID: <5698E61C.2080301@oracle.com> On 14/01/2016 18:28, Lu, Yingqi wrote: > Hi Alan/Michael/Volker, > > Here is the link to the version 7 of the patch. http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.07/ > > Please note: after the code has been uploaded, I found out I forgot to remove extra check of ENOPROTOOPT in the net_util_md.c. Since it took us couple days to upload the code each time, I think it might be a good idea to mark this as an open item for now. I will change it in next version for sure together with anything you found in the current version. > > I think this looks quite good but there is still one architectural issue that doesn't look quite right to me. The issue is that DatagramSocketImpl and MulticastSocket shouldn't be dependent on the built-in AbstractPlainSocketImpl. If you develop your own DatagramSocketImpl implementation then you'll quickly see the issue. It looks like you have it right in SocketImpl, it's just DatagramSocketImpl and MulticastSocket where the dependency seems to exist. One other comment is that I don't think SocketImpl.addAdditionalOptions is ready to be exposed in the API (you've added it as a protected method as it will become part of the Java SE API). Clearly there is a need for impls to have a way to expand the set of socket options but it needs further consideration on what that API should be. The simplest is to just drop protected and make this a package-private method. One other point on addAdditionalOptions is that it mutates the set of socket options and so is not thread safe. We'll need to come up with a way to do this in a safe way. One final comment is on the Unix version of PlainSocketImpl and PlainDatagramSocketImpl. I'm wondering if these changes are really needed. This may be something Michael may have suggestions on. -Alan From Alan.Bateman at oracle.com Fri Jan 15 13:21:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jan 2016 13:21:19 +0000 Subject: RFR [9] 8143554: UnsupportedOperationException is not thrown for unsupported options In-Reply-To: <569671BB.4020908@oracle.com> References: <56603E51.2040202@oracle.com> <5666CEE3.6010805@oracle.com> <5666D363.5020707@oracle.com> <5666DEBF.7050005@oracle.com> <5666E05D.10006@oracle.com> <56748961.7010602@oracle.com> <567A83FD.9070700@oracle.com> <56839299.1060008@oracle.com> <569671BB.4020908@oracle.com> Message-ID: <5698F24F.6050009@oracle.com> On 13/01/2016 15:48, Svetlana Nikandrova wrote: > Alan, > > thank you for you replay. > Here is my updated webrev with formatting fixes. > http://cr.openjdk.java.net/~kshefov/8143554/webrev.03/ > > > About getSocket() check - you are right, it is because there are > Socket options unsupported by ServerSocket. > I looked at the latest webrev and it looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From svetlana.nikandrova at oracle.com Fri Jan 15 14:53:03 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Fri, 15 Jan 2016 17:53:03 +0300 Subject: RFR [9] 8143554: UnsupportedOperationException is not thrown for unsupported options In-Reply-To: <5698F24F.6050009@oracle.com> References: <56603E51.2040202@oracle.com> <5666CEE3.6010805@oracle.com> <5666D363.5020707@oracle.com> <5666DEBF.7050005@oracle.com> <5666E05D.10006@oracle.com> <56748961.7010602@oracle.com> <567A83FD.9070700@oracle.com> <56839299.1060008@oracle.com> <569671BB.4020908@oracle.com> <5698F24F.6050009@oracle.com> Message-ID: <569907CF.2040309@oracle.com> Thank you, Alan! If nobody has any objections I'll ask to push this fix. Thank you, Svetlana On 15.01.2016 16:21, Alan Bateman wrote: > > > On 13/01/2016 15:48, Svetlana Nikandrova wrote: >> Alan, >> >> thank you for you replay. >> Here is my updated webrev with formatting fixes. >> http://cr.openjdk.java.net/~kshefov/8143554/webrev.03/ >> >> >> About getSocket() check - you are right, it is because there are >> Socket options unsupported by ServerSocket. >> > I looked at the latest webrev and it looks good to me. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Sun Jan 17 15:30:20 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 17 Jan 2016 16:30:20 +0100 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs Message-ID: <569BB38C.7070602@oracle.com> Hi, please review this patch which might make URI.toURL more efficient Webrev: http://cr.openjdk.java.net/~redestad/8147462 Bug: https://bugs.openjdk.java.net/browse/JDK-8147462 This patch exploits the fact that URI will apply the same validation to the URI/URL specification for any valid non-opaque URL, thus it's safe to use the component-based URL constructor. Also, URIs representing malformed URLs will throw an exception as specified both before and after. A number of simple test cases to capture and document this was added to the existing java/net/URI/URItoURL jtreg test. Microbenchmarks covering various URIs vary from neutral (for opaque) to 1.5x (for the simplest URIs without query and fragment components), while also bringing in a small footprint improvement in jake builds. While toURL() could arguably construct the URL file as path[?query][#fragment], the implementation I tried for this caused regressions in micros due to hitting C2 inlining limit. Thanks! /Claes From Alan.Bateman at oracle.com Mon Jan 18 14:09:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Jan 2016 14:09:25 +0000 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <569BB38C.7070602@oracle.com> References: <569BB38C.7070602@oracle.com> Message-ID: <569CF215.3070009@oracle.com> On 17/01/2016 15:30, Claes Redestad wrote: > Hi, > > please review this patch which might make URI.toURL more efficient > > Webrev: http://cr.openjdk.java.net/~redestad/8147462 > Bug: https://bugs.openjdk.java.net/browse/JDK-8147462 > > This patch exploits the fact that URI will apply the same validation > to the URI/URL specification for any valid non-opaque URL, thus it's > safe to use the component-based URL constructor. Also, URIs > representing malformed URLs will throw an exception as specified both > before and after. A number of simple test cases to capture and > document this was added to the existing java/net/URI/URItoURL jtreg test. I think the change to URI looks okay but it would be good to include a brief comment as otherwise it will be difficult for future maintainers to understand. In the test then it might be simpler to just check that the type of toURLException and newURLException are the same. -Alan. From chris.hegarty at oracle.com Mon Jan 18 14:34:47 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 18 Jan 2016 14:34:47 +0000 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <569CF215.3070009@oracle.com> References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> Message-ID: <569CF807.5040609@oracle.com> On 18/01/16 14:09, Alan Bateman wrote: > > On 17/01/2016 15:30, Claes Redestad wrote: >> Hi, >> >> please review this patch which might make URI.toURL more efficient >> >> Webrev: http://cr.openjdk.java.net/~redestad/8147462 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147462 >> >> This patch exploits the fact that URI will apply the same validation >> to the URI/URL specification for any valid non-opaque URL, thus it's >> safe to use the component-based URL constructor. Also, URIs >> representing malformed URLs will throw an exception as specified both >> before and after. A number of simple test cases to capture and >> document this was added to the existing java/net/URI/URItoURL jtreg test. > I think the change to URI looks okay but it would be good to include a > brief comment as otherwise it will be difficult for future maintainers > to understand. +1. For a long time we have been suggesting that anyone requiring a URL should retrieve it from URI::toURL, so it is good to have a fast(er) common path. The handling of a null/empty host is a little esoteric, so a comment would be good. I do have a little discomfort about this change, since the toURL spec specifically says it is "equivalent to evaluating the expression new URL(this.toString())". I wonder if your tests should cover this too, i.e. the resulting URLs from toURL and URL(this.toString()) are equal? -Chris. From claes.redestad at oracle.com Mon Jan 18 16:20:18 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 Jan 2016 17:20:18 +0100 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <569CF807.5040609@oracle.com> References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> <569CF807.5040609@oracle.com> Message-ID: <569D10C2.7040107@oracle.com> On 2016-01-18 15:34, Chris Hegarty wrote: > On 18/01/16 14:09, Alan Bateman wrote: >> >> On 17/01/2016 15:30, Claes Redestad wrote: >>> Hi, >>> >>> please review this patch which might make URI.toURL more efficient >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8147462 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147462 >>> >>> This patch exploits the fact that URI will apply the same validation >>> to the URI/URL specification for any valid non-opaque URL, thus it's >>> safe to use the component-based URL constructor. Also, URIs >>> representing malformed URLs will throw an exception as specified both >>> before and after. A number of simple test cases to capture and >>> document this was added to the existing java/net/URI/URItoURL jtreg >>> test. >> I think the change to URI looks okay but it would be good to include a >> brief comment as otherwise it will be difficult for future maintainers >> to understand. > > +1. For a long time we have been suggesting that anyone requiring > a URL should retrieve it from URI::toURL, so it is good to have a > fast(er) common path. > > The handling of a null/empty host is a little esoteric, so a comment > would be good. How about this? http://cr.openjdk.java.net/~redestad/8147462/webrev.02 > > I do have a little discomfort about this change, since the toURL spec > specifically says it is "equivalent to evaluating the expression new > URL(this.toString())". I wonder if your tests should cover this too, > i.e. the resulting URLs from toURL and URL(this.toString()) are equal? The test already does this. I've just added cases that exercise some interesting cases like URIs containing /./ and quoted characters. I restructured the exceptional tests slightly to differentiate the cases where both toURL and new URL throw MalformedURLException from cases where toURL throws IAE. It makes the test slightly more verbose but arguably a lot simpler. However: the javadoc spec for URL(String) seems incomplete, and I might have stumbled into a trap... * @exception MalformedURLException if no protocol is specified, or an * unknown protocol is found, or {@code spec} is {@code null}. Since this method delegates parsing to the URLStreamHandler associated with the protocol it might be overriden to throw exceptions (that will be wrapped in MalformedURLException) for a variety of reasons. The ability for URLStreamHandler implementations to override the parseURL method seem to prevent this improvement unless we only do this for a subset of known, well-behaved URLStreamHandlers, which likely defeat the optimization by adding complexity. Thanks! /Claes From chris.hegarty at oracle.com Mon Jan 18 19:26:53 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 18 Jan 2016 19:26:53 +0000 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <569D10C2.7040107@oracle.com> References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> <569CF807.5040609@oracle.com> <569D10C2.7040107@oracle.com> Message-ID: <3A925DC0-E90A-482D-AE9D-1F2F1F38E040@oracle.com> > On 18 Jan 2016, at 16:20, Claes Redestad wrote: > > On 2016-01-18 15:34, Chris Hegarty wrote: >> On 18/01/16 14:09, Alan Bateman wrote: >>> >>> On 17/01/2016 15:30, Claes Redestad wrote: >>>> Hi, >>>> >>>> please review this patch which might make URI.toURL more efficient >>>> >>>> Webrev: http://cr.openjdk.java.net/~redestad/8147462 >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147462 >>>> >>>> This patch exploits the fact that URI will apply the same validation >>>> to the URI/URL specification for any valid non-opaque URL, thus it's >>>> safe to use the component-based URL constructor. Also, URIs >>>> representing malformed URLs will throw an exception as specified both >>>> before and after. A number of simple test cases to capture and >>>> document this was added to the existing java/net/URI/URItoURL jtreg test. >>> I think the change to URI looks okay but it would be good to include a >>> brief comment as otherwise it will be difficult for future maintainers >>> to understand. >> >> +1. For a long time we have been suggesting that anyone requiring >> a URL should retrieve it from URI::toURL, so it is good to have a >> fast(er) common path. >> >> The handling of a null/empty host is a little esoteric, so a comment >> would be good. > > How about this? > > http://cr.openjdk.java.net/~redestad/8147462/webrev.02 Looks good Claes. -Chris. >> I do have a little discomfort about this change, since the toURL spec >> specifically says it is "equivalent to evaluating the expression new URL(this.toString())". I wonder if your tests should cover this too, >> i.e. the resulting URLs from toURL and URL(this.toString()) are equal? > > The test already does this. I've just added cases that exercise some interesting cases like URIs containing /./ and quoted characters. > > I restructured the exceptional tests slightly to differentiate the cases where both toURL and new URL throw MalformedURLException from cases where toURL throws IAE. It makes the test slightly more verbose but arguably a lot simpler. > > However: the javadoc spec for URL(String) seems incomplete, and I might have stumbled into a trap... > > * @exception MalformedURLException if no protocol is specified, or an > * unknown protocol is found, or {@code spec} is {@code null}. > > Since this method delegates parsing to the URLStreamHandler associated with the protocol it might be overriden to throw exceptions (that will be wrapped in MalformedURLException) for a variety of reasons. > > The ability for URLStreamHandler implementations to override the parseURL method seem to prevent this improvement unless we only do this for a subset of known, well-behaved URLStreamHandlers, which likely defeat the optimization by adding complexity. > > Thanks! > > /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jan 18 20:05:18 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Jan 2016 20:05:18 +0000 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <3A925DC0-E90A-482D-AE9D-1F2F1F38E040@oracle.com> References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> <569CF807.5040609@oracle.com> <569D10C2.7040107@oracle.com> <3A925DC0-E90A-482D-AE9D-1F2F1F38E040@oracle.com> Message-ID: <569D457E.5090504@oracle.com> On 18/01/2016 19:26, Chris Hegarty wrote: > >> On 18 Jan 2016, at 16:20, Claes Redestad > > wrote: >> >> On 2016-01-18 15:34, Chris Hegarty wrote: >>> On 18/01/16 14:09, Alan Bateman wrote: >>>> >>>> On 17/01/2016 15:30, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> please review this patch which might make URI.toURL more efficient >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~redestad/8147462 >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147462 >>>>> >>>>> This patch exploits the fact that URI will apply the same validation >>>>> to the URI/URL specification for any valid non-opaque URL, thus it's >>>>> safe to use the component-based URL constructor. Also, URIs >>>>> representing malformed URLs will throw an exception as specified both >>>>> before and after. A number of simple test cases to capture and >>>>> document this was added to the existing java/net/URI/URItoURL >>>>> jtreg test. >>>> I think the change to URI looks okay but it would be good to include a >>>> brief comment as otherwise it will be difficult for future maintainers >>>> to understand. >>> >>> +1. For a long time we have been suggesting that anyone requiring >>> a URL should retrieve it from URI::toURL, so it is good to have a >>> fast(er) common path. >>> >>> The handling of a null/empty host is a little esoteric, so a comment >>> would be good. >> >> How about this? >> >> http://cr.openjdk.java.net/~redestad/8147462/webrev.02 >> > > Looks good Claes. > This looks okay to me too. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Jan 20 06:36:57 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 20 Jan 2016 06:36:57 +0000 Subject: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently In-Reply-To: <56973B1A.30000@oracle.com> References: <568F74F7.70100@oracle.com> <56973B1A.30000@oracle.com> Message-ID: Felix, On 14 Jan 2016, at 06:07, Felix Yang wrote: > Hi all, > please review the fix for test/java/net/SocketPermission/SocketPermissionTest.java, which fails frequently with "java.net.BindException: Address already in use". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065076 > Webrev: http://cr.openjdk.java.net/~xiaofeya/8065076/webrev.00 My preference is to avoid getFreePort. It is problematic and I believe just obfuscates the intermittent failures further. In many of the test scenarios the ?listening? socket can be created before the specific access control context and associated permission are created. I?ll see if I can get some time to try this out. -Chris. > The test uses getFreePort() test util library to verify permission on specific "host:port". This fix added retries to avoid possible binding failures: > 1. A port may be still occupied for a short moment after socket close. > 2. Another application is possible to occupy the same port during the short time window of open-close-reuse. This has been observed in experimental test runs. > > Thanks, > Felix > > From Roger.Riggs at Oracle.com Wed Jan 20 19:08:25 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 20 Jan 2016 14:08:25 -0500 Subject: ServerImpl misplaced null check In-Reply-To: <43F4760D-748F-4556-B187-83D3B593A3C8@gmail.com> References: <43F4760D-748F-4556-B187-83D3B593A3C8@gmail.com> Message-ID: <569FDB29.6010602@Oracle.com> Looks like a bug to me. Network issues are better raised on net-dev at openjdk.java.net Created: 8147862 Null check too late in sun.net.httpserver.ServerImpl Thanks, Roger On 1/20/2016 1:18 PM, Scott Palmer wrote: > I was searching for a way to set TCP_NODELAY for an Endpoint using the default HTTP server and after finally tracking down the existence of the ?sun.net.httpserver.nodelay? system property I noticed what appears to be a mistake (though not a big one) in the source code. > > Look here: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c3ecf996006a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java#l377 > > Notice the null check on ?chan? is performed after it may have been dereferenced to set the TCP_NODELAY on the channel?s socket. If chan truly can be null at that point, the check needs to be move up a few lines. > > Regards, > > Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Jan 20 20:45:37 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 20 Jan 2016 20:45:37 +0000 Subject: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently In-Reply-To: References: <568F74F7.70100@oracle.com> <56973B1A.30000@oracle.com> Message-ID: On 20 Jan 2016, at 06:36, Chris Hegarty wrote: > Felix, > > On 14 Jan 2016, at 06:07, Felix Yang wrote: > >> Hi all, >> please review the fix for test/java/net/SocketPermission/SocketPermissionTest.java, which fails frequently with "java.net.BindException: Address already in use". >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065076 >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8065076/webrev.00 > > My preference is to avoid getFreePort. It is problematic and I believe just obfuscates > the intermittent failures further. > > In many of the test scenarios the ?listening? socket can be created before the specific > access control context and associated permission are created. > > I?ll see if I can get some time to try this out. I spent a little time on this today. I basically rewrote the test, but kept the same test scenarios. The use of data providers was cute, but not workable since there is no common supertype for the socket classes. I decided to just expand out the test cases manually. This will give the same test coverage, but should be stable since it creates the sockets first, on an ephemeral port, and then constructs the permissions appropriately given that port. http://cr.openjdk.java.net/~chegar/8065076/ The webrev diffs are almost useless, just review the new file, and compare test scenarios against the what is in the old file. -Chris. From david.holmes at oracle.com Thu Jan 21 08:59:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jan 2016 18:59:14 +1000 Subject: ServerImpl misplaced null check In-Reply-To: <43F4760D-748F-4556-B187-83D3B593A3C8@gmail.com> References: <43F4760D-748F-4556-B187-83D3B593A3C8@gmail.com> Message-ID: <56A09DE2.7070603@oracle.com> Hi Scott, cc'ing net-dev as this is not a build issue. David On 21/01/2016 4:18 AM, Scott Palmer wrote: > I was searching for a way to set TCP_NODELAY for an Endpoint using the default HTTP server and after finally tracking down the existence of the ?sun.net.httpserver.nodelay? system property I noticed what appears to be a mistake (though not a big one) in the source code. > > Look here: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c3ecf996006a/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java#l377 > > Notice the null check on ?chan? is performed after it may have been dereferenced to set the TCP_NODELAY on the channel?s socket. If chan truly can be null at that point, the check needs to be move up a few lines. > > Regards, > > Scott > From michael.x.mcmahon at oracle.com Thu Jan 21 11:41:55 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 21 Jan 2016 11:41:55 +0000 Subject: [9] RFR: 8138990: Implementation of HTTP Digest authentication may be more flexible In-Reply-To: <568ABC5E.1010707@oracle.com> References: <56617BF2.2090306@oracle.com> <56795729.6040608@oracle.com> <56834DDF.40407@oracle.com> <568A4948.1040901@oracle.com> <568ABC5E.1010707@oracle.com> Message-ID: <56A0C403.80207@oracle.com> Artem, The change looks fine. Thanks, Michael On 04/01/16 18:39, Artem Smotrakov wrote: > Hi Michael, > > On 01/04/2016 02:28 AM, Michael McMahon wrote: >> On 30/12/15 03:22, Artem Smotrakov wrote: >>> Hi Michael, >>> >>> Thanks for review, it looks like BNF notation uses only a comma as a >>> separator >>> >>> http://www.w3.org/Notation.html >>> >>> ... >>> #element >>> >>> indicating at least l and at most m elements, each separated by one >>> or more commas (","). >>> ... >>> >> >> Hi Artem, >> >> The BNF definitions used in RFC 2617 come from section 2.1 of RFC 2616 >> which allows linear white space between tokens. >> >> #rule >> A construct "#" is defined, similar to "*", for defining lists of >> elements. The full form is "#element" indicating at least >> and at most elements, each separated by one or more commas >> (",") and OPTIONAL linear white space (LWS). > If I read it correctly, it means that a comma is used as a separator, > but there also may be a linear whitespace after a comma. So for > example "auth,auth-int" and "auth, auth-int" are equal, and should > result to a list of two elements. Current version of webrev seems to > follow it (first, it splits a string by a comma, and then ignores > white spaces): > > http://cr.openjdk.java.net/~asmotrak/http_auth_digest/webrev.01/ > > Am I missing something? > > Artem > >> >> So, I think we should be conservative and check for white-space. >> >> - Michael. >> Michael >>> And here is "qop" definition from https://tools.ietf.org/html/rfc2617 >>> >>> ... >>> qop-options = "qop" "=" <"> 1#qop-value <"> >>> qop-value = "auth" | "auth-int" | token >>> ... >>> >>> Please take a look at updated webrev: >>> >>> http://cr.openjdk.java.net/~asmotrak/http_auth_digest/webrev.01/ >>> >>> Artem >>> >>> On 12/22/2015 05:59 AM, Michael McMahon wrote: >>>> Hi Artem, >>>> >>>> >>>> On 04/12/15 11:41, Artem Smotrakov wrote: >>>>> Hello, >>>>> >>>>> Please review this small fix for DigestAuthentication class. >>>>> >>>>> 1. Added a check in DigestAuthentication.setNonce(String) that >>>>> nonce is not null. NPE may happen if a buggy HTTP server returns >>>>> "WWW-Authenticate" header which doesn't contain a "nonce" field. >>>>> According to RFCs 2069 [1] and 2617 [2], this is not expected >>>>> behaviour, but it would be better if an HTTP client threw a >>>>> checked IOException instead of NPE. >>>>> >>>> >>>> That's fine. >>>> >>>>> 2. Updated DigestAuthentication.setQop(String) method to accept >>>>> both a whitespace and a comma as a delimiter. RFC 2617 [2] says >>>>> that "qop" may contain more than one token, but it doesn't specify >>>>> a delimiter for "qop" field in "WWW-Authenticate" header. There is >>>>> an example of "WWW-Authenticate" header in RFC 2617 [2] where a >>>>> comma is used as a delimiter of value in "qop" field. >>>>> >>>> >>>> It looks like the BNF specification mandates a comma and optional >>>> linear white space. >>>> So, the old code was buggy, but we didn't see the problem because >>>> there is typically >>>> only at most ever one value used for the qop field. But, to be >>>> strictly correct, we would >>>> have to check for TABs also. So, I think the correct behavior is to >>>> delimit using comma >>>> and remove any white space >>>> >>>> - Michael. >>>> >>>>> 3. Added a test for Digest authentication. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138990 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~asmotrak/http_auth_digest/webrev.00/ >>>>> >>>>> [1] https://tools.ietf.org/html/rfc2069 >>>>> [2] https://tools.ietf.org/html/rfc2617 >>>>> >>>>> Artem >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Thu Jan 21 17:27:12 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 21 Jan 2016 18:27:12 +0100 Subject: RFR: 8147962: URL should handle lower-casing of protocol locale-independently Message-ID: <56A114F0.3040106@oracle.com> Hi, using String.toLowerCase() in URL allows some strings to lower-case to a string that'd be invalid, e.g. "FILE".toLowerCase() -> "f\u0131le" in turkish locales. This patch suggests using the locale-independent String.toLowerCase(Locale.ENGLISH) instead, since only a-z and A-Z are legal alphabeticals according to spec. Webrev: http://cr.openjdk.java.net/~redestad/8147962/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147962 Thanks! Claes From felix.yang at oracle.com Thu Jan 21 22:55:30 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 21 Jan 2016 14:55:30 -0800 Subject: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently In-Reply-To: References: <568F74F7.70100@oracle.com> <56973B1A.30000@oracle.com> Message-ID: <67D3FEF2-7B00-4C90-8D87-6258B7AE547A@oracle.com> Hi Chris, your fix is cool. I will assign the bug to you:) a comment on this fix. The test changed system SecurityManager and it is not executed with othervm mode. I think you need to rollback the change after test. Otherwise it may affect other tests. Thanks, Felix > On Jan 20, 2016, at 12:45 PM, Chris Hegarty wrote: > > On 20 Jan 2016, at 06:36, Chris Hegarty > wrote: > >> Felix, >> >> On 14 Jan 2016, at 06:07, Felix Yang wrote: >> >>> Hi all, >>> please review the fix for test/java/net/SocketPermission/SocketPermissionTest.java, which fails frequently with "java.net.BindException: Address already in use". >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8065076 >>> Webrev: http://cr.openjdk.java.net/~xiaofeya/8065076/webrev.00 >> >> My preference is to avoid getFreePort. It is problematic and I believe just obfuscates >> the intermittent failures further. >> >> In many of the test scenarios the ?listening? socket can be created before the specific >> access control context and associated permission are created. >> >> I?ll see if I can get some time to try this out. > > I spent a little time on this today. I basically rewrote the test, but kept the > same test scenarios. The use of data providers was cute, but not workable > since there is no common supertype for the socket classes. I decided to > just expand out the test cases manually. This will give the same test > coverage, but should be stable since it creates the sockets first, on an > ephemeral port, and then constructs the permissions appropriately given > that port. > > http://cr.openjdk.java.net/~chegar/8065076/ > > The webrev diffs are almost useless, just review the new file, and compare > test scenarios against the what is in the old file. > > -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto.sato at oracle.com Fri Jan 22 04:34:47 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 22 Jan 2016 10:04:47 +0530 Subject: RFR: 8147962: URL should handle lower-casing of protocol locale-independently In-Reply-To: <56A114F0.3040106@oracle.com> References: <56A114F0.3040106@oracle.com> Message-ID: <56A1B167.8080903@oracle.com> Hello, I'd suggest using Locale.ROOT instead of Locale.ENGLISH for this purpose. Naoto On 1/21/16 10:57 PM, Claes Redestad wrote: > Hi, > > using String.toLowerCase() in URL allows some strings to lower-case to a > string that'd be invalid, e.g. "FILE".toLowerCase() -> "f\u0131le" in > turkish locales. > > This patch suggests using the locale-independent > String.toLowerCase(Locale.ENGLISH) instead, since only a-z and A-Z are > legal alphabeticals according to spec. > > Webrev: http://cr.openjdk.java.net/~redestad/8147962/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8147962 > > Thanks! > > Claes > From Alan.Bateman at oracle.com Fri Jan 22 11:29:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Jan 2016 11:29:30 +0000 Subject: RFR: 8147962: URL should handle lower-casing of protocol locale-independently In-Reply-To: <56A114F0.3040106@oracle.com> References: <56A114F0.3040106@oracle.com> Message-ID: <56A2129A.7010300@oracle.com> On 21/01/2016 17:27, Claes Redestad wrote: > Hi, > > using String.toLowerCase() in URL allows some strings to lower-case to > a string that'd be invalid, e.g. "FILE".toLowerCase() -> "f\u0131le" > in turkish locales. > > This patch suggests using the locale-independent > String.toLowerCase(Locale.ENGLISH) instead, since only a-z and A-Z are > legal alphabeticals according to spec. > > Webrev: http://cr.openjdk.java.net/~redestad/8147962/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8147962 The change to URL looks okay but be warned that URL has bitten the fingers of many that have dared to touch it. So we'll need to keep an eye out for any side effects/bug reports. For the test then maybe it could iterate over all locales rather than just test with tr. Also good for the test to run in othervm mode, I can't recall off hand if jtreg resets the locale when in agent VM mode (the default in our testing these days). -Alan. From claes.redestad at oracle.com Fri Jan 22 12:29:22 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 22 Jan 2016 13:29:22 +0100 Subject: RFR: 8147962: URL should handle lower-casing of protocol locale-independently In-Reply-To: <56A2129A.7010300@oracle.com> References: <56A114F0.3040106@oracle.com> <56A2129A.7010300@oracle.com> Message-ID: <56A220A2.70502@oracle.com> On 2016-01-22 12:29, Alan Bateman wrote: > > > On 21/01/2016 17:27, Claes Redestad wrote: >> Hi, >> >> using String.toLowerCase() in URL allows some strings to lower-case >> to a string that'd be invalid, e.g. "FILE".toLowerCase() -> >> "f\u0131le" in turkish locales. >> >> This patch suggests using the locale-independent >> String.toLowerCase(Locale.ENGLISH) instead, since only a-z and A-Z >> are legal alphabeticals according to spec. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8147962/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147962 > The change to URL looks okay but be warned that URL has bitten the > fingers of many that have dared to touch it. So we'll need to keep an > eye out for any side effects/bug reports. I've been questioning my sanity for some time now. > > For the test then maybe it could iterate over all locales rather than > just test with tr. Also good for the test to run in othervm mode, I > can't recall off hand if jtreg resets the locale when in agent VM mode > (the default in our testing these days). Done: http://cr.openjdk.java.net/~redestad/8147962/webrev.02/ Going over available locales will make the test pass on environments that don't happen to have the "tr" locale (and verified this catches the issue). Also switched to Locale.ROOT as Naoto suggested. Thanks! /Claes From mark.sheppard at oracle.com Fri Jan 22 12:36:20 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 22 Jan 2016 12:36:20 +0000 Subject: RFR: JDK-8147862 - Null check too late in sun.net.httpserver.ServerImpl Message-ID: <56A22244.1020304@oracle.com> Hi please oblige and review the small change http://cr.openjdk.java.net/~msheppar/8147862/webrev/ to address https://bugs.openjdk.java.net/browse/JDK-8147862 it was observed that a null check on a SocketChannel object in the Disptacher.run() method within ServerImpl, should be earlier in the call flow. regards Mark From Alan.Bateman at oracle.com Fri Jan 22 13:38:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Jan 2016 13:38:09 +0000 Subject: RFR: 8147962: URL should handle lower-casing of protocol locale-independently In-Reply-To: <56A220A2.70502@oracle.com> References: <56A114F0.3040106@oracle.com> <56A2129A.7010300@oracle.com> <56A220A2.70502@oracle.com> Message-ID: <56A230C1.60109@oracle.com> On 22/01/2016 12:29, Claes Redestad wrote: > : > > http://cr.openjdk.java.net/~redestad/8147962/webrev.02/ > This looks good to me. -Alan From claes.redestad at oracle.com Fri Jan 22 13:38:35 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 22 Jan 2016 14:38:35 +0100 Subject: RFR: 8147962: URL should handle lower-casing of protocol locale-independently In-Reply-To: <56A230C1.60109@oracle.com> References: <56A114F0.3040106@oracle.com> <56A2129A.7010300@oracle.com> <56A220A2.70502@oracle.com> <56A230C1.60109@oracle.com> Message-ID: <56A230DB.5090006@oracle.com> On 2016-01-22 14:38, Alan Bateman wrote: > > > On 22/01/2016 12:29, Claes Redestad wrote: >> : >> >> http://cr.openjdk.java.net/~redestad/8147962/webrev.02/ >> > This looks good to me. > > -Alan Thanks! /Claes From chris.hegarty at oracle.com Fri Jan 22 13:46:55 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 Jan 2016 13:46:55 +0000 Subject: RFR: JDK-8147862 - Null check too late in sun.net.httpserver.ServerImpl In-Reply-To: <56A22244.1020304@oracle.com> References: <56A22244.1020304@oracle.com> Message-ID: <56A232CF.4030806@oracle.com> On 22/01/16 12:36, Mark Sheppard wrote: > Hi > please oblige and review the small change > http://cr.openjdk.java.net/~msheppar/8147862/webrev/ Thanks for fixing this Mark. This was originally my mistake :-( -Chris. > to address > https://bugs.openjdk.java.net/browse/JDK-8147862 > > it was observed that a null check on a SocketChannel object in > the Disptacher.run() method within ServerImpl, should be > earlier in the call flow. > > regards > Mark From chris.hegarty at oracle.com Fri Jan 22 13:56:28 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 Jan 2016 13:56:28 +0000 Subject: RFR: 8147962: URL should handle lower-casing of protocol locale-independently In-Reply-To: <56A230DB.5090006@oracle.com> References: <56A114F0.3040106@oracle.com> <56A2129A.7010300@oracle.com> <56A220A2.70502@oracle.com> <56A230C1.60109@oracle.com> <56A230DB.5090006@oracle.com> Message-ID: <56A2350C.20602@oracle.com> On 22/01/16 13:38, Claes Redestad wrote: > > > On 2016-01-22 14:38, Alan Bateman wrote: >> >> >> On 22/01/2016 12:29, Claes Redestad wrote: >>> : >>> >>> http://cr.openjdk.java.net/~redestad/8147962/webrev.02/ Looks good. -Chris. From chris.hegarty at oracle.com Fri Jan 22 14:49:46 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 Jan 2016 14:49:46 +0000 Subject: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently In-Reply-To: <67D3FEF2-7B00-4C90-8D87-6258B7AE547A@oracle.com> References: <568F74F7.70100@oracle.com> <56973B1A.30000@oracle.com> <67D3FEF2-7B00-4C90-8D87-6258B7AE547A@oracle.com> Message-ID: <56A2418A.1060903@oracle.com> On 21/01/16 22:55, Felix Yang wrote: > Hi Chris, > your fix is cool. I will assign the bug to you:) > a comment on this fix. The test changed system SecurityManager and > it is not executed with othervm mode. I think you need to rollback the > change after test. I will revert the change and have the test run in othervm mode. I did do a complete test run with this change and it did not cause any problems, but then again the policy is all permissions! Thanks Felix. -Chris. > Otherwise it may affect other tests. > > Thanks, > Felix >> On Jan 20, 2016, at 12:45 PM, Chris Hegarty > > wrote: >> >> On 20 Jan 2016, at 06:36, Chris Hegarty > > wrote: >> >>> Felix, >>> >>> On 14 Jan 2016, at 06:07, Felix Yang >> > wrote: >>> >>>> Hi all, >>>> please review the fix for >>>> test/java/net/SocketPermission/SocketPermissionTest.java, which >>>> fails frequently with "java.net.BindException: Address already in use". >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8065076 >>>> Webrev: http://cr.openjdk.java.net/~xiaofeya/8065076/webrev.00 >>> >>> My preference is to avoid getFreePort. It is problematic and I >>> believe just obfuscates >>> the intermittent failures further. >>> >>> In many of the test scenarios the ?listening? socket can be created >>> before the specific >>> access control context and associated permission are created. >>> >>> I?ll see if I can get some time to try this out. >> >> I spent a little time on this today. I basically rewrote the test, but >> kept the >> same test scenarios. The use of data providers was cute, but not workable >> since there is no common supertype for the socket classes. I decided to >> just expand out the test cases manually. This will give the same test >> coverage, but should be stable since it creates the sockets first, on an >> ephemeral port, and then constructs the permissions appropriately given >> that port. >> >> http://cr.openjdk.java.net/~chegar/8065076/ >> >> The webrev diffs are almost useless, just review the new file, and compare >> test scenarios against the what is in the old file. >> >> -Chris. > From sean.coffey at oracle.com Mon Jan 25 14:39:28 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 25 Jan 2016 14:39:28 +0000 Subject: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently In-Reply-To: <56A2418A.1060903@oracle.com> References: <568F74F7.70100@oracle.com> <56973B1A.30000@oracle.com> <67D3FEF2-7B00-4C90-8D87-6258B7AE547A@oracle.com> <56A2418A.1060903@oracle.com> Message-ID: <56A633A0.3000309@oracle.com> The changes look fine to me also Chris. Regards, Sean. On 22/01/16 14:49, Chris Hegarty wrote: > On 21/01/16 22:55, Felix Yang wrote: >> Hi Chris, >> your fix is cool. I will assign the bug to you:) >> a comment on this fix. The test changed system SecurityManager and >> it is not executed with othervm mode. I think you need to rollback the >> change after test. > > I will revert the change and have the test run in othervm mode. > > I did do a complete test run with this change and it did not cause > any problems, but then again the policy is all permissions! > > Thanks Felix. > > -Chris. > > > Otherwise it may affect other tests. >> >> Thanks, >> Felix >>> On Jan 20, 2016, at 12:45 PM, Chris Hegarty >> > wrote: >>> >>> On 20 Jan 2016, at 06:36, Chris Hegarty >> > wrote: >>> >>>> Felix, >>>> >>>> On 14 Jan 2016, at 06:07, Felix Yang >>> > wrote: >>>> >>>>> Hi all, >>>>> please review the fix for >>>>> test/java/net/SocketPermission/SocketPermissionTest.java, which >>>>> fails frequently with "java.net.BindException: Address already in >>>>> use". >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8065076 >>>>> Webrev: http://cr.openjdk.java.net/~xiaofeya/8065076/webrev.00 >>>> >>>> My preference is to avoid getFreePort. It is problematic and I >>>> believe just obfuscates >>>> the intermittent failures further. >>>> >>>> In many of the test scenarios the ?listening? socket can be created >>>> before the specific >>>> access control context and associated permission are created. >>>> >>>> I?ll see if I can get some time to try this out. >>> >>> I spent a little time on this today. I basically rewrote the test, but >>> kept the >>> same test scenarios. The use of data providers was cute, but not >>> workable >>> since there is no common supertype for the socket classes. I decided to >>> just expand out the test cases manually. This will give the same test >>> coverage, but should be stable since it creates the sockets first, >>> on an >>> ephemeral port, and then constructs the permissions appropriately given >>> that port. >>> >>> http://cr.openjdk.java.net/~chegar/8065076/ >>> >>> The webrev diffs are almost useless, just review the new file, and >>> compare >>> test scenarios against the what is in the old file. >>> >>> -Chris. >> From claes.redestad at oracle.com Wed Jan 27 17:24:22 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 Jan 2016 18:24:22 +0100 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <569D10C2.7040107@oracle.com> References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> <569CF807.5040609@oracle.com> <569D10C2.7040107@oracle.com> Message-ID: <56A8FD46.8030002@oracle.com> On 2016-01-18 17:20, Claes Redestad wrote: > > The ability for URLStreamHandler implementations to override the > parseURL method seem to prevent this improvement unless we only do > this for a subset of known, well-behaved URLStreamHandlers, which > likely defeat the optimization by adding complexity. Right, the fast path can only be safely used for the non-overrideable handlers (jrt and file), but turns out we can make that work without penalizing other cases: http://cr.openjdk.java.net/~redestad/8147462/webrev.04/ Relevant micros[1] show that this brings a benefit to file/jrt, even when mixed with slow path URIs, while micros only hitting slow path (newHttpURIToURL, opaqueURIToURL) doesn't regress: Before: Benchmark Mode Cnt Score Error Units URIBench.mixedURIToURL avgt 30 463.748 ? 14.445 ns/op URIBench.newHttpURIToURL avgt 30 441.497 ? 20.173 ns/op URIBench.newURIToURL avgt 30 227.106 ? 9.055 ns/op URIBench.opaqueURIToURL avgt 30 320.904 ? 13.232 ns/op Patched: Benchmark Mode Cnt Score Error Units URIBench.mixedURIToURL avgt 30 441.773 ? 16.530 ns/op URIBench.newHttpURIToURL avgt 30 433.946 ? 18.569 ns/op URIBench.newURIToURL avgt 30 147.379 ? 6.349 ns/op URIBench.opaqueURIToURL avgt 30 316.632 ? 12.940 ns/op /Claes [1] http://cr.openjdk.java.net/~redestad/8147462/URIBench.java From martinrb at google.com Thu Jan 28 02:29:58 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Jan 2016 18:29:58 -0800 Subject: JDK-8148424 Support ipv6-only environments Message-ID: Are y'all interested in our ipv6-only changes? https://bugs.openjdk.java.net/browse/JDK-8148424 If yes, there will be some work on both sides, mostly for multi-platform testing. From yingqi.lu at intel.com Thu Jan 28 06:03:51 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Thu, 28 Jan 2016 06:03:51 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <5698E61C.2080301@oracle.com> References: <56670940.6020107@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B69EFE@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> <568BE866.2060306@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8F021@ORSMSX113.amr.corp.intel.com> <568D34C6.3030802@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B923AF@ORSMSX113.amr.corp.intel.com> <568EA695.2050201@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B9C7E6@ORSMSX113.amr.corp.intel.com> <5698E61C.2080301@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA3BBC1D7@ORSMSX113.amr.corp.intel.com> Hi Alan, Here is a new version of the patch: http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.08/ In this version, based on your comment, we have changed following items: 1. Remove the dependency of DatagramSocketImpl and MulticastSocket with AbstractPlainSocketImpl. 2. Made addReusePortOption() to be both thread safe and package private. Please let us know your feedback and comments. Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Friday, January 15, 2016 4:29 AM To: Lu, Yingqi Cc: net-dev at openjdk.java.net; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; Kaczmarek, Eric Subject: Re: Patch for adding SO_REUSEPORT socket option On 14/01/2016 18:28, Lu, Yingqi wrote: > Hi Alan/Michael/Volker, > > Here is the link to the version 7 of the patch. > http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.07/ > > Please note: after the code has been uploaded, I found out I forgot to remove extra check of ENOPROTOOPT in the net_util_md.c. Since it took us couple days to upload the code each time, I think it might be a good idea to mark this as an open item for now. I will change it in next version for sure together with anything you found in the current version. > > I think this looks quite good but there is still one architectural issue that doesn't look quite right to me. The issue is that DatagramSocketImpl and MulticastSocket shouldn't be dependent on the built-in AbstractPlainSocketImpl. If you develop your own DatagramSocketImpl implementation then you'll quickly see the issue. It looks like you have it right in SocketImpl, it's just DatagramSocketImpl and MulticastSocket where the dependency seems to exist. One other comment is that I don't think SocketImpl.addAdditionalOptions is ready to be exposed in the API (you've added it as a protected method as it will become part of the Java SE API). Clearly there is a need for impls to have a way to expand the set of socket options but it needs further consideration on what that API should be. The simplest is to just drop protected and make this a package-private method. One other point on addAdditionalOptions is that it mutates the set of socket options and so is not thread safe. We'll need to come up with a way to do this in a safe way. One final comment is on the Unix version of PlainSocketImpl and PlainDatagramSocketImpl. I'm wondering if these changes are really needed. This may be something Michael may have suggestions on. -Alan From Alan.Bateman at oracle.com Thu Jan 28 13:41:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Jan 2016 13:41:45 +0000 Subject: JDK-8148424 Support ipv6-only environments In-Reply-To: References: Message-ID: <56AA1A99.7020509@oracle.com> On 28/01/2016 02:29, Martin Buchholz wrote: > Are y'all interested in our ipv6-only changes? > https://bugs.openjdk.java.net/browse/JDK-8148424 > If yes, there will be some work on both sides, mostly for > multi-platform testing. I think so, this is configuration that we attempted to test several times, going back to JDK 1.4. -Alan From chris.hegarty at oracle.com Thu Jan 28 15:52:18 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 28 Jan 2016 15:52:18 +0000 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <56A8FD46.8030002@oracle.com> References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> <569CF807.5040609@oracle.com> <569D10C2.7040107@oracle.com> <56A8FD46.8030002@oracle.com> Message-ID: On 27 Jan 2016, at 17:24, Claes Redestad wrote: > > On 2016-01-18 17:20, Claes Redestad wrote: >> >> The ability for URLStreamHandler implementations to override the parseURL method seem to prevent this improvement unless we only do this for a subset of known, well-behaved URLStreamHandlers, which likely defeat the optimization by adding complexity. > > Right, the fast path can only be safely used for the non-overrideable handlers (jrt and file), but turns out we can make that work without penalizing other cases: > > http://cr.openjdk.java.net/~redestad/8147462/webrev.04/ This looks fine Claes. Maybe just a comment on the fact that character based comparison is being used for perf reasons. In an older version of the webrev, there was an updated to an existing test, test/java/net/URI/URItoURLTest.java. I assume this was just mistakenly omitted from the latest version? -Chris. > Relevant micros[1] show that this brings a benefit to file/jrt, even when mixed with slow path URIs, while micros only hitting slow path (newHttpURIToURL, opaqueURIToURL) doesn't regress: > > Before: > Benchmark Mode Cnt Score Error Units > URIBench.mixedURIToURL avgt 30 463.748 ? 14.445 ns/op > URIBench.newHttpURIToURL avgt 30 441.497 ? 20.173 ns/op > URIBench.newURIToURL avgt 30 227.106 ? 9.055 ns/op > URIBench.opaqueURIToURL avgt 30 320.904 ? 13.232 ns/op > > Patched: > Benchmark Mode Cnt Score Error Units > URIBench.mixedURIToURL avgt 30 441.773 ? 16.530 ns/op > URIBench.newHttpURIToURL avgt 30 433.946 ? 18.569 ns/op > URIBench.newURIToURL avgt 30 147.379 ? 6.349 ns/op > URIBench.opaqueURIToURL avgt 30 316.632 ? 12.940 ns/op > > /Claes > > [1] http://cr.openjdk.java.net/~redestad/8147462/URIBench.java From claes.redestad at oracle.com Thu Jan 28 16:38:35 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 28 Jan 2016 17:38:35 +0100 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> <569CF807.5040609@oracle.com> <569D10C2.7040107@oracle.com> <56A8FD46.8030002@oracle.com> Message-ID: <56AA440B.3060401@oracle.com> On 2016-01-28 16:52, Chris Hegarty wrote: >> ... > This looks fine Claes. Thanks, Chris! > > Maybe just a comment on the fact that character based comparison is > being used for perf reasons. > > In an older version of the webrev, there was an updated to an existing test, > test/java/net/URI/URItoURLTest.java. I assume this was just mistakenly > omitted from the latest version? Fixed test and added a comment: http://cr.openjdk.java.net/~redestad/8147462/webrev.05/ Thanks! /Claes From chris.hegarty at oracle.com Thu Jan 28 17:12:05 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 28 Jan 2016 17:12:05 +0000 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <56AA440B.3060401@oracle.com> References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> <569CF807.5040609@oracle.com> <569D10C2.7040107@oracle.com> <56A8FD46.8030002@oracle.com> <56AA440B.3060401@oracle.com> Message-ID: <116F4348-D467-4C81-A9DF-3494DA705E36@oracle.com> On 28 Jan 2016, at 16:38, Claes Redestad wrote: > On 2016-01-28 16:52, Chris Hegarty wrote: >>> ... >> This looks fine Claes. > > Thanks, Chris! > >> >> Maybe just a comment on the fact that character based comparison is >> being used for perf reasons. >> >> In an older version of the webrev, there was an updated to an existing test, >> test/java/net/URI/URItoURLTest.java. I assume this was just mistakenly >> omitted from the latest version? > > Fixed test and added a comment: > > http://cr.openjdk.java.net/~redestad/8147462/webrev.05/ Reviewed. -Chris. From Alan.Bateman at oracle.com Thu Jan 28 19:56:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Jan 2016 19:56:21 +0000 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <56AA440B.3060401@oracle.com> References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> <569CF807.5040609@oracle.com> <569D10C2.7040107@oracle.com> <56A8FD46.8030002@oracle.com> <56AA440B.3060401@oracle.com> Message-ID: <56AA7265.3030307@oracle.com> This looks okay. I think it would be good to put a javadoc comment on this method, also maybe move it to below all the constructors rather than in the middle. -Alan. On 28/01/2016 16:38, Claes Redestad wrote: > > > On 2016-01-28 16:52, Chris Hegarty wrote: >>> ... >> This looks fine Claes. > > Thanks, Chris! > >> >> Maybe just a comment on the fact that character based comparison is >> being used for perf reasons. >> >> In an older version of the webrev, there was an updated to an >> existing test, >> test/java/net/URI/URItoURLTest.java. I assume this was just mistakenly >> omitted from the latest version? > > Fixed test and added a comment: > > http://cr.openjdk.java.net/~redestad/8147462/webrev.05/ > > Thanks! > > /Claes > > From claes.redestad at oracle.com Thu Jan 28 23:47:11 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 29 Jan 2016 00:47:11 +0100 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <56AA7265.3030307@oracle.com> References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> <569CF807.5040609@oracle.com> <569D10C2.7040107@oracle.com> <56A8FD46.8030002@oracle.com> <56AA440B.3060401@oracle.com> <56AA7265.3030307@oracle.com> Message-ID: <56AAA87F.1040606@oracle.com> On 2016-01-28 20:56, Alan Bateman wrote: > > This looks okay. I think it would be good to put a javadoc comment on > this method, also maybe move it to below all the constructors rather > than in the middle. > > -Alan. Sure, as this is package-private API a short description and reference to the URI::toURL method whose specification we adhere to should suffice: http://cr.openjdk.java.net/~redestad/8147462/webrev.06/ Thanks! /Claes From Alan.Bateman at oracle.com Fri Jan 29 09:15:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Jan 2016 09:15:54 +0000 Subject: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs In-Reply-To: <56AAA87F.1040606@oracle.com> References: <569BB38C.7070602@oracle.com> <569CF215.3070009@oracle.com> <569CF807.5040609@oracle.com> <569D10C2.7040107@oracle.com> <56A8FD46.8030002@oracle.com> <56AA440B.3060401@oracle.com> <56AA7265.3030307@oracle.com> <56AAA87F.1040606@oracle.com> Message-ID: <56AB2DCA.8060003@oracle.com> On 28/01/2016 23:47, Claes Redestad wrote: > > Sure, as this is package-private API a short description and reference > to the URI::toURL method whose specification we adhere to should suffice: > > http://cr.openjdk.java.net/~redestad/8147462/webrev.06/ > This looks good - thanks! -Alan From Alan.Bateman at oracle.com Fri Jan 29 14:37:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Jan 2016 14:37:37 +0000 Subject: Patch for adding SO_REUSEPORT socket option In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA3BBC1D7@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA3B6B293@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B78D14@ORSMSX113.amr.corp.intel.com> <5686606A.5050100@oracle.com> <568AC6E0.9050807@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E123@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8E62B@ORSMSX113.amr.corp.intel.com> <568BE866.2060306@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B8F021@ORSMSX113.amr.corp.intel.com> <568D34C6.3030802@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B923AF@ORSMSX113.amr.corp.intel.com> <568EA695.2050201@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3B9C7E6@ORSMSX113.amr.corp.intel.com> <5698E61C.2080301@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA3BBC1D7@ORSMSX113.amr.corp.intel.com> Message-ID: <56AB7931.9020106@oracle.com> On 28/01/2016 06:03, Lu, Yingqi wrote: > Hi Alan, > > Here is a new version of the patch: http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.08/ > > In this version, based on your comment, we have changed following items: > > 1. Remove the dependency of DatagramSocketImpl and MulticastSocket with AbstractPlainSocketImpl. > > 2. Made addReusePortOption() to be both thread safe and package private. > > Please let us know your feedback and comments. > > I looking the latest patch and it's looking quite good but I think there is still an issue with the supportedOptions() methods in the java.net classes. You changes also highlight an existing bug in SocketImpl::supportedOptions whereby it returns a mutable rather than immutable set - I'll create a bug for this. The issue is that the patch changes SocketImpl.socketOptions and SocketImpl.serverSocketOptions and so these sets of options will be incorrect if an alternative SocketImpl is created. For now then I think the simplest is to change AbstractPlainSocketImpl.supportedOptions() to: @Override protected Set> supportedOptions() { Set> options = super.supportedOptions(); if (isReusePortAvailable()) { options = new HashSet<>(options); options.add(StandardSocketOptions.SO_REUSEPORT); return Collections.unmodifiableSet(options); } else { return options; } } That will ensure that the caller get an immutable set of options that include SO_REUSEPORT when it supported. Clearly it would be better to cache this but we can sort that later once you are okay with not changing the set at the level of SocketImpl. Otherwise just a few minor comments: - in src/java.base/windows/native/libnet/net_util_md.h then it might be better to put the #define SO_REUSEPORT near the top or at least before the function prototypes. - test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java - I assume this change is not needed. - test/java/nio/channels/DatagramChannel/SocketOptionTests.java - the Arrays.asList could be formatted better to keep the line length consistent. That's all I have, I think we are close to the final line on this one. -Alan. From claes.redestad at oracle.com Sun Jan 31 00:58:35 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 31 Jan 2016 01:58:35 +0100 Subject: RFR: 8148626: URI.toURL needs to use protocol Handler to parse file URIs In-Reply-To: <56AD026C.7030703@oracle.com> References: <56ACC8FF.6050405@oracle.com> <56AD026C.7030703@oracle.com> Message-ID: <56AD5C3B.9030803@oracle.com> Hi, On 2016-01-30 19:35, joe darcy wrote: > Hello, > > The change looks okay in that the new code is limited to the jrt > protocol. I assume the failing test > > java/net/URL/B5086147.java > > passes again with this change. I had to go through some hoops to find out how to ensure this test actually gets picked up by the remote-testing incantation I've been using so far, but have verified the test has been run and passes on the affected platforms. > > If a fix for this issue is not pushed soon, I want to have the failing > test problem listed > (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038459.html). I'm ready push this, but might be good to get a second opinion from net-dev to ensure they aren't caught unaware of this follow-up fix. Thanks! /Claes > > Thanks, > > -Joe > > On 1/30/2016 6:30 AM, Claes Redestad wrote: >> Hi, >> >> it turns out trying to optimize URI to URL conversion for file URLs >> don't work out very well due to special treatment of backward slashes. >> >> Instead of trying to deal with such file URLs, this patch partially >> backs out 8147462 and only leave the optimization in place for the >> jrt protocol. This still helps >> reducing footprint in jigsaw while keeping things performance neutral >> for other kinds of URLs. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148626 >> Webrev: http://cr.openjdk.java.net/~redestad/8148626/webrev.01/ >> >> /Claes > From chris.hegarty at oracle.com Sun Jan 31 16:13:35 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 31 Jan 2016 16:13:35 +0000 Subject: RFR: 8148626: URI.toURL needs to use protocol Handler to parse file URIs In-Reply-To: <56AD5C3B.9030803@oracle.com> References: <56ACC8FF.6050405@oracle.com> <56AD026C.7030703@oracle.com> <56AD5C3B.9030803@oracle.com> Message-ID: <5483AAB2-ECC8-4A99-A8DC-05815EEFC5F0@oracle.com> > On 31 Jan 2016, at 00:58, Claes Redestad wrote: > > Hi, > > On 2016-01-30 19:35, joe darcy wrote: >> Hello, >> >> The change looks okay in that the new code is limited to the jrt protocol. I assume the failing test >> >> java/net/URL/B5086147.java >> >> passes again with this change. > > I had to go through some hoops to find out how to ensure this test actually gets picked up by the remote-testing incantation I've been using so far, but have verified the test has been run and passes on the affected platforms. > >> >> If a fix for this issue is not pushed soon, I want to have the failing test problem listed (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038459.html). > > I'm ready push this, but might be good to get a second opinion from net-dev to ensure they aren't caught unaware of this follow-up fix. This looks ok Claes. -Chris. > Thanks! > > /Claes >> >> Thanks, >> >> -Joe >> >> On 1/30/2016 6:30 AM, Claes Redestad wrote: >>> Hi, >>> >>> it turns out trying to optimize URI to URL conversion for file URLs don't work out very well due to special treatment of backward slashes. >>> >>> Instead of trying to deal with such file URLs, this patch partially backs out 8147462 and only leave the optimization in place for the jrt protocol. This still helps >>> reducing footprint in jigsaw while keeping things performance neutral for other kinds of URLs. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148626 >>> Webrev: http://cr.openjdk.java.net/~redestad/8148626/webrev.01/ >>> >>> /Claes >> > From claes.redestad at oracle.com Sun Jan 31 21:37:19 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 31 Jan 2016 22:37:19 +0100 Subject: RFR: 8148626: URI.toURL needs to use protocol Handler to parse file URIs In-Reply-To: <5483AAB2-ECC8-4A99-A8DC-05815EEFC5F0@oracle.com> References: <56ACC8FF.6050405@oracle.com> <56AD026C.7030703@oracle.com> <56AD5C3B.9030803@oracle.com> <5483AAB2-ECC8-4A99-A8DC-05815EEFC5F0@oracle.com> Message-ID: <56AE7E8F.4030407@oracle.com> Joe, Chris, thanks for reviewing. Pushed. /Claes On 2016-01-31 17:13, Chris Hegarty wrote: >> On 31 Jan 2016, at 00:58, Claes Redestad wrote: >> >> Hi, >> >> On 2016-01-30 19:35, joe darcy wrote: >>> Hello, >>> >>> The change looks okay in that the new code is limited to the jrt protocol. I assume the failing test >>> >>> java/net/URL/B5086147.java >>> >>> passes again with this change. >> I had to go through some hoops to find out how to ensure this test actually gets picked up by the remote-testing incantation I've been using so far, but have verified the test has been run and passes on the affected platforms. >> >>> If a fix for this issue is not pushed soon, I want to have the failing test problem listed (http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038459.html). >> I'm ready push this, but might be good to get a second opinion from net-dev to ensure they aren't caught unaware of this follow-up fix. > This looks ok Claes. > > -Chris. > >> Thanks! >> >> /Claes >>> Thanks, >>> >>> -Joe >>> >>> On 1/30/2016 6:30 AM, Claes Redestad wrote: >>>> Hi, >>>> >>>> it turns out trying to optimize URI to URL conversion for file URLs don't work out very well due to special treatment of backward slashes. >>>> >>>> Instead of trying to deal with such file URLs, this patch partially backs out 8147462 and only leave the optimization in place for the jrt protocol. This still helps >>>> reducing footprint in jigsaw while keeping things performance neutral for other kinds of URLs. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148626 >>>> Webrev: http://cr.openjdk.java.net/~redestad/8148626/webrev.01/ >>>> >>>> /Claes