From michael.x.mcmahon at oracle.com Wed Mar 1 15:40:54 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 Mar 2017 15:40:54 +0000 Subject: RFR 8175814: HttpClient protocol version needs unspecified value Message-ID: <58B6EB86.8040804@oracle.com> Hi Could I get the following JDK 9 change reviewed, please? In addition to fixing the spec problem around HTTP version, it fixes an implementation issue with version also, where the per-request version (if set) was not being picked up. http://cr.openjdk.java.net/~michaelm/8175814/webrev.1/index.html Thanks, Michael From daniel.fuchs at oracle.com Mon Mar 6 11:00:54 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 6 Mar 2017 11:00:54 +0000 Subject: RFR 8175814: HttpClient protocol version needs unspecified value In-Reply-To: <58B6EB86.8040804@oracle.com> References: <58B6EB86.8040804@oracle.com> Message-ID: On 01/03/17 15:40, Michael McMahon wrote: > Hi > > Could I get the following JDK 9 change reviewed, please? > In addition to fixing the spec problem around HTTP version, > it fixes an implementation issue with version also, where the per-request > version (if set) was not being picked up. > > http://cr.openjdk.java.net/~michaelm/8175814/webrev.1/index.html Looks good to me Michael. best regards, -- daniel > > Thanks, > > Michael From chris.hegarty at oracle.com Mon Mar 6 11:12:12 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Mar 2017 11:12:12 +0000 Subject: RFR 8175814: HttpClient protocol version needs unspecified value In-Reply-To: References: <58B6EB86.8040804@oracle.com> Message-ID: <9bb98606-2178-7e6d-8aee-33163983db64@oracle.com> On 06/03/17 11:00, Daniel Fuchs wrote: > On 01/03/17 15:40, Michael McMahon wrote: >> Hi >> >> Could I get the following JDK 9 change reviewed, please? >> In addition to fixing the spec problem around HTTP version, >> it fixes an implementation issue with version also, where the per-request >> version (if set) was not being picked up. >> >> http://cr.openjdk.java.net/~michaelm/8175814/webrev.1/index.html > > Looks good to me Michael. +1. I am happy to see the default version changed to HTTP/2. Could a test for the default spec'ed HTTP/2 version be added. We typically line up the module names, one per line, in the at modules tag. -Chris. From michael.x.mcmahon at oracle.com Mon Mar 6 11:29:30 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 06 Mar 2017 11:29:30 +0000 Subject: RFR 8175814: HttpClient protocol version needs unspecified value In-Reply-To: <9bb98606-2178-7e6d-8aee-33163983db64@oracle.com> References: <58B6EB86.8040804@oracle.com> <9bb98606-2178-7e6d-8aee-33163983db64@oracle.com> Message-ID: <58BD481A.9010201@oracle.com> On 06/03/2017, 11:12, Chris Hegarty wrote: > On 06/03/17 11:00, Daniel Fuchs wrote: >> On 01/03/17 15:40, Michael McMahon wrote: >>> Hi >>> >>> Could I get the following JDK 9 change reviewed, please? >>> In addition to fixing the spec problem around HTTP version, >>> it fixes an implementation issue with version also, where the >>> per-request >>> version (if set) was not being picked up. >>> >>> http://cr.openjdk.java.net/~michaelm/8175814/webrev.1/index.html >> >> Looks good to me Michael. > > +1. I am happy to see the default version changed to HTTP/2. > > Could a test for the default spec'ed HTTP/2 version be added. > We typically line up the module names, one per line, in the at > modules tag. > Yes, I'll add a test. Thanks, Michael. > -Chris. > From mark.sheppard at oracle.com Mon Mar 6 22:00:46 2017 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Mon, 6 Mar 2017 22:00:46 +0000 Subject: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses Message-ID: <194a7ad6-1f9f-332e-858d-c405b81442a1@oracle.com> Hi, please oblige and review the change http://cr.openjdk.java.net/~msheppar/8175325/webrev/ for the issue raised in https://bugs.openjdk.java.net/browse/JDK-8175325 the scenario is that a MulticastSocket, bound to a wildcard address, which has yet to have its NetworkInterface set, will return a synthesized NetworkInterface for a getNetworkInterface method call. The newly constructed has no InterfaceAddress bindings instantiated, resulting in a NPE when getInterfaceAddresses is invoked. The fix initializes the bindings member variable with an empty array, as per suggestion in the bug, and also, for completeness, places a null check in the getInterfaceAddresses method. There is a side issue here, relating to the synthesis of a NetworkInterface for a MulticastSocket bound to a wildcard address. This is somewhat dubious semantics, and would seem to be worthy of review at some stage in the future. regards Mark From martinrb at google.com Mon Mar 6 22:16:05 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 Mar 2017 14:16:05 -0800 Subject: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses In-Reply-To: <194a7ad6-1f9f-332e-858d-c405b81442a1@oracle.com> References: <194a7ad6-1f9f-332e-858d-c405b81442a1@oracle.com> Message-ID: It would not have both the never-null property and the check for null. I would probably just leave bindings null in the constructor and check for null whenever reading bindings. On Mon, Mar 6, 2017 at 2:00 PM, Mark Sheppard wrote: > Hi, > please oblige and review the change > http://cr.openjdk.java.net/~msheppar/8175325/webrev/ > > for the issue raised in > https://bugs.openjdk.java.net/browse/JDK-8175325 > > the scenario is that a MulticastSocket, bound to a wildcard address, which > has yet to have its NetworkInterface > set, will return a synthesized NetworkInterface for a getNetworkInterface > method call. The newly constructed > has no InterfaceAddress bindings instantiated, resulting in a NPE when > getInterfaceAddresses is invoked. > The fix initializes the bindings member variable with an empty array, as > per suggestion in the bug, and also, > for completeness, places a null check in the getInterfaceAddresses method. > > There is a side issue here, relating to the synthesis of a > NetworkInterface for a MulticastSocket > bound to a wildcard address. This is somewhat dubious semantics, and would > seem to be worthy of review > at some stage in the future. > > regards > Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.sheppard at oracle.com Mon Mar 6 23:21:14 2017 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Mon, 6 Mar 2017 23:21:14 +0000 Subject: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses In-Reply-To: References: <194a7ad6-1f9f-332e-858d-c405b81442a1@oracle.com> Message-ID: tha's true from the Java side. I didn't exhaustively check if is possible that the bindings could be returned uninitialized or null from native code - I don't think it is possible, but I added the null check, just in case. regards Mark On 06/03/2017 22:16, Martin Buchholz wrote: > It would not have both the never-null property and the check for null. > > I would probably just leave bindings null in the constructor and check > for null whenever reading bindings. > > On Mon, Mar 6, 2017 at 2:00 PM, Mark Sheppard > > wrote: > > Hi, > please oblige and review the change > http://cr.openjdk.java.net/~msheppar/8175325/webrev/ > > > for the issue raised in > https://bugs.openjdk.java.net/browse/JDK-8175325 > > > the scenario is that a MulticastSocket, bound to a wildcard > address, which has yet to have its NetworkInterface > set, will return a synthesized NetworkInterface for a > getNetworkInterface method call. The newly constructed > has no InterfaceAddress bindings instantiated, resulting in a NPE > when getInterfaceAddresses is invoked. > The fix initializes the bindings member variable with an empty > array, as per suggestion in the bug, and also, > for completeness, places a null check in the getInterfaceAddresses > method. > > There is a side issue here, relating to the synthesis of a > NetworkInterface for a MulticastSocket > bound to a wildcard address. This is somewhat dubious semantics, > and would seem to be worthy of review > at some stage in the future. > > regards > Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Mar 7 15:17:17 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 7 Mar 2017 15:17:17 +0000 Subject: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses In-Reply-To: References: <194a7ad6-1f9f-332e-858d-c405b81442a1@oracle.com> Message-ID: <665AEFC2-DCEB-45D6-8A78-0BFD2F149635@oracle.com> Mark, > On 6 Mar 2017, at 23:21, Mark Sheppard wrote: > > tha's true from the Java side. I didn't exhaustively check if is possible that the bindings could > be returned uninitialized or null from native code - I don't think it is possible, but I added the > null check, just in case. I agree with Martin?s comment. The null check should be sufficient. ? >> There is a side issue here, relating to the synthesis of a NetworkInterface for a MulticastSocket >> bound to a wildcard address. This is somewhat dubious semantics, and would seem to be worthy of review >> at some stage in the future. Yes, this should be looked at in some more detail in the future. -Chris. From mark.sheppard at oracle.com Tue Mar 7 16:15:34 2017 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Tue, 7 Mar 2017 16:15:34 +0000 Subject: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses In-Reply-To: <665AEFC2-DCEB-45D6-8A78-0BFD2F149635@oracle.com> References: <194a7ad6-1f9f-332e-858d-c405b81442a1@oracle.com> <665AEFC2-DCEB-45D6-8A78-0BFD2F149635@oracle.com> Message-ID: <2ca0f8ae-acf1-5451-4575-7eb21bd21f3f@oracle.com> Chris, Martin, thanks for the feedback .... I'll remove the initialization from the constructor regards Mark On 07/03/2017 15:17, Chris Hegarty wrote: > Mark, > >> On 6 Mar 2017, at 23:21, Mark Sheppard wrote: >> >> tha's true from the Java side. I didn't exhaustively check if is possible that the bindings could >> be returned uninitialized or null from native code - I don't think it is possible, but I added the >> null check, just in case. > I agree with Martin?s comment. The null check should be sufficient. > ? > >>> There is a side issue here, relating to the synthesis of a NetworkInterface for a MulticastSocket >>> bound to a wildcard address. This is somewhat dubious semantics, and would seem to be worthy of review >>> at some stage in the future. > Yes, this should be looked at in some more detail in the future. > > -Chris. From martinrb at google.com Fri Mar 17 18:47:56 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 17 Mar 2017 11:47:56 -0700 Subject: Let's improve IPv6 support Message-ID: Google cares a lot about IPv6, and not only because Vint Cerf works at Google. We have some local modifications and some networking expertise and intend to port/contribute that to openjdk10. Most of this is the work of my colleagues Alexander Smundak and Paul Marks. We hope we can do most of this work without asking too much of other net-dev engineers, but we will likely need help with porting to non-Linux platforms, running JPRT, and perhaps CCC/JEP process. We expect to make a large number of commits. Should there be a JEP to cover this? Is there a current net-dev engineer who feels they "own" this problem (Chris?)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmarks at google.com Fri Mar 17 21:12:17 2017 From: pmarks at google.com (Paul Marks) Date: Fri, 17 Mar 2017 14:12:17 -0700 Subject: Let's improve IPv6 support In-Reply-To: References: Message-ID: On Fri, Mar 17, 2017 at 11:47 AM, Martin Buchholz wrote: > Google cares a lot about IPv6, and not only because Vint Cerf works at > Google. > > We have some local modifications and some networking expertise and intend to > port/contribute that to openjdk10. > > Most of this is the work of my colleagues Alexander Smundak and Paul Marks. > > We hope we can do most of this work without asking too much of other net-dev > engineers, but we will likely need help with porting to non-Linux platforms, > running JPRT, and perhaps CCC/JEP process. > > We expect to make a large number of commits. Should there be a JEP to cover > this? Is there a current net-dev engineer who feels they "own" this problem > (Chris?)? I should point out that the current batch of changes are focused on support for systems where 127.0.0.1 doesn't exist, which is relatively straightforward and unexciting. However, I'm also aware of three "hard problems" that would require new features, and significant changes to current behavior: - Address selection: https://bugs.openjdk.java.net/browse/JDK-8170568 - Default IP address formatting ("0:0:0:0:0:0:0:1" vs. RFC 5952) - Parsing and formatting of host:port strings, e.g. "[::1]:80" From christoph.langer at sap.com Sat Mar 18 18:03:53 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 18 Mar 2017 18:03:53 +0000 Subject: Let's improve IPv6 support In-Reply-To: References: Message-ID: <66d12a7f8a6b4aaab1b715890d072a84@sap.com> Hi Martin and colleagues, Sounds good. I?m supporting that and I?m willing to assist with testing/reviewing. But if it comes to larger changes and JEPs/CCCs (or the new CSR), it will need an owner at Oracle? like Chris. Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Martin Buchholz Sent: Freitag, 17. M?rz 2017 19:48 To: net-dev ; Alexander Smundak ; Paul Marks ; Chuck Rasbold ; Chris Hegarty Subject: Let's improve IPv6 support Google cares a lot about IPv6, and not only because Vint Cerf works at Google. We have some local modifications and some networking expertise and intend to port/contribute that to openjdk10. Most of this is the work of my colleagues Alexander Smundak and Paul Marks. We hope we can do most of this work without asking too much of other net-dev engineers, but we will likely need help with porting to non-Linux platforms, running JPRT, and perhaps CCC/JEP process. We expect to make a large number of commits. Should there be a JEP to cover this? Is there a current net-dev engineer who feels they "own" this problem (Chris?)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Mar 20 11:22:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Mar 2017 11:22:58 +0000 Subject: Let's improve IPv6 support In-Reply-To: References: Message-ID: <100f5768-5087-db85-14b4-303e72d53325@oracle.com> On 17/03/2017 18:47, Martin Buchholz wrote: > Google cares a lot about IPv6, and not only because Vint Cerf works at > Google. > > We have some local modifications and some networking expertise and > intend to port/contribute that to openjdk10. > > Most of this is the work of my colleagues Alexander Smundak and Paul > Marks. > > We hope we can do most of this work without asking too much of other > net-dev engineers, but we will likely need help with porting to > non-Linux platforms, running JPRT, and perhaps CCC/JEP process. > > We expect to make a large number of commits. Should there be a JEP to > cover this? Is there a current net-dev engineer who feels they "own" > this problem (Chris?)? Do you expect a significant overhaul that would add new APIs and re-specify/modernize some of the existing APIs? If so then this seems significant enough to create a JEP. On the other hand, if this a series of point patches to address specific issues then it might be best handled as a linked sequence of issues in JIRA. As regards the CCC then the proposal is to replace this with a new "Compatibility & Specification Review" group in OpenJDK [1]. -Alan [1] http://mail.openjdk.java.net/pipermail/gb-discuss/2017-January/000320.html From chris.hegarty at oracle.com Mon Mar 20 14:07:17 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Mar 2017 14:07:17 +0000 Subject: Let's improve IPv6 support In-Reply-To: <100f5768-5087-db85-14b4-303e72d53325@oracle.com> References: <100f5768-5087-db85-14b4-303e72d53325@oracle.com> Message-ID: Martin, > On 17/03/2017 18:47, Martin Buchholz wrote: > >> Google cares a lot about IPv6, and not only because Vint Cerf works at >> Google. >> >> We have some local modifications and some networking expertise and >> intend to port/contribute that to openjdk10. >> >> Most of this is the work of my colleagues Alexander Smundak and Paul >> Marks. >> >> We hope we can do most of this work without asking too much of other >> net-dev engineers, but we will likely need help with porting to >> non-Linux platforms, running JPRT, and perhaps CCC/JEP process. >> >> We expect to make a large number of commits. Should there be a JEP to >> cover this? Is there a current net-dev engineer who feels they "own" >> this problem (Chris?)? Doing this work under a JEP would give folks a better insight what Google is planning here. As you know, we have tinkered a lot in this area, even in 9, but there has not be a concerted effort in recent times. We are also very interested in making improvements here. Working on this in a branch of the jdk10/sandbox would facilitate collaboration, and lighten the process as changes can be flattened when bringing them into the mainline. -Chris. From chris.hegarty at oracle.com Mon Mar 20 14:14:10 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Mar 2017 14:14:10 +0000 Subject: Let's improve IPv6 support In-Reply-To: References: Message-ID: On 17/03/17 21:12, Paul Marks wrote: > On Fri, Mar 17, 2017 at 11:47 AM, Martin Buchholz wrote: >> Google cares a lot about IPv6, and not only because Vint Cerf works at >> Google. >> >> We have some local modifications and some networking expertise and intend to >> port/contribute that to openjdk10. >> >> Most of this is the work of my colleagues Alexander Smundak and Paul Marks. >> >> We hope we can do most of this work without asking too much of other net-dev >> engineers, but we will likely need help with porting to non-Linux platforms, >> running JPRT, and perhaps CCC/JEP process. >> >> We expect to make a large number of commits. Should there be a JEP to cover >> this? Is there a current net-dev engineer who feels they "own" this problem >> (Chris?)? > > I should point out that the current batch of changes are focused on > support for systems where 127.0.0.1 doesn't exist, which is relatively > straightforward and unexciting. Sorry, what does this mean. IPv6-only environment with ::1, or no loopback mechanism at all? > However, I'm also aware of three "hard problems" that would require > new features, and significant changes to current behavior: > - Address selection: https://bugs.openjdk.java.net/browse/JDK-8170568 > - Default IP address formatting ("0:0:0:0:0:0:0:1" vs. RFC 5952) > - Parsing and formatting of host:port strings, e.g. "[::1]:80" While a JEP is not strictly needed to add APIs for such, I think it would be a really useful to go through the process of writing this stuff up ( which will likely result in a JEP, if not a JEP-like document ), since there are others that are interested. -Chris. From sean.coffey at oracle.com Mon Mar 20 16:11:55 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 20 Mar 2017 16:11:55 +0000 Subject: RFR (xs) : 8177144 :sun/net/www/http/HttpClient/B8025710.java should run in ovm mode Message-ID: Looking for a simple review. Test should be run in ovm mode : https://bugs.openjdk.java.net/browse/JDK-8177144 diff --git a/test/sun/net/www/http/HttpClient/B8025710.java b/test/sun/net/www/http/HttpClient/B8025710.java --- a/test/sun/net/www/http/HttpClient/B8025710.java +++ b/test/sun/net/www/http/HttpClient/B8025710.java @@ -37,6 +37,7 @@ * @test * @bug 8025710 * @summary Proxied https connection reuse by HttpClient can send CONNECT to the server + * @run main/othervm B8025710 */ public class B8025710 { -- Regards, Sean. From martinrb at google.com Mon Mar 20 16:11:58 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 20 Mar 2017 09:11:58 -0700 Subject: Let's improve IPv6 support In-Reply-To: References: Message-ID: On Mon, Mar 20, 2017 at 7:14 AM, Chris Hegarty wrote: > >> I should point out that the current batch of changes are focused on >> support for systems where 127.0.0.1 doesn't exist, which is relatively >> straightforward and unexciting. >> > > Sorry, what does this mean. IPv6-only environment with ::1, or no > loopback mechanism at all? A system where 127.0.0.1 does not exist (in fact IPv4 is completely absent), and "localhost" resolves to ::1. A simple but pervasive change to global replace testing code via: s/"127.0.0.1"/ InetAddress.getLoopbackAddress().getHostAddress()/g -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Mon Mar 20 16:14:47 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 20 Mar 2017 16:14:47 +0000 Subject: RFR (xs) : 8177144 :sun/net/www/http/HttpClient/B8025710.java should run in ovm mode In-Reply-To: References: Message-ID: Looks good to me Se?n! best, -- daniel On 20/03/2017 16:11, Se?n Coffey wrote: > Looking for a simple review. Test should be run in ovm mode : > > https://bugs.openjdk.java.net/browse/JDK-8177144 > > diff --git a/test/sun/net/www/http/HttpClient/B8025710.java > b/test/sun/net/www/http/HttpClient/B8025710.java > --- a/test/sun/net/www/http/HttpClient/B8025710.java > +++ b/test/sun/net/www/http/HttpClient/B8025710.java > @@ -37,6 +37,7 @@ > * @test > * @bug 8025710 > * @summary Proxied https connection reuse by HttpClient can send > CONNECT to the server > + * @run main/othervm B8025710 > */ > public class B8025710 { > From chris.hegarty at oracle.com Mon Mar 20 16:15:15 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Mar 2017 16:15:15 +0000 Subject: RFR (xs) : 8177144 :sun/net/www/http/HttpClient/B8025710.java should run in ovm mode In-Reply-To: References: Message-ID: Looks good Sean. -Chris. On 20/03/17 16:11, Se?n Coffey wrote: > Looking for a simple review. Test should be run in ovm mode : > > https://bugs.openjdk.java.net/browse/JDK-8177144 > > diff --git a/test/sun/net/www/http/HttpClient/B8025710.java > b/test/sun/net/www/http/HttpClient/B8025710.java > --- a/test/sun/net/www/http/HttpClient/B8025710.java > +++ b/test/sun/net/www/http/HttpClient/B8025710.java > @@ -37,6 +37,7 @@ > * @test > * @bug 8025710 > * @summary Proxied https connection reuse by HttpClient can send > CONNECT to the server > + * @run main/othervm B8025710 > */ > public class B8025710 { > From Roger.Riggs at Oracle.com Mon Mar 20 16:18:19 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 20 Mar 2017 12:18:19 -0400 Subject: RFR (xs) : 8177144 :sun/net/www/http/HttpClient/B8025710.java should run in ovm mode In-Reply-To: References: Message-ID: <43b4fb44-bc17-2982-ef02-2a5cfe5d661f@Oracle.com> Hi Sean, Looks good, Roger On 3/20/2017 12:11 PM, Se?n Coffey wrote: > Looking for a simple review. Test should be run in ovm mode : > > https://bugs.openjdk.java.net/browse/JDK-8177144 > > diff --git a/test/sun/net/www/http/HttpClient/B8025710.java > b/test/sun/net/www/http/HttpClient/B8025710.java > --- a/test/sun/net/www/http/HttpClient/B8025710.java > +++ b/test/sun/net/www/http/HttpClient/B8025710.java > @@ -37,6 +37,7 @@ > * @test > * @bug 8025710 > * @summary Proxied https connection reuse by HttpClient can send > CONNECT to the server > + * @run main/othervm B8025710 > */ > public class B8025710 { > From chris.hegarty at oracle.com Mon Mar 20 16:20:18 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Mar 2017 16:20:18 +0000 Subject: Let's improve IPv6 support In-Reply-To: References: Message-ID: <822d41bf-d055-342e-350c-69f7a1e3bd64@oracle.com> On 20/03/17 16:11, Martin Buchholz wrote: > > > On Mon, Mar 20, 2017 at 7:14 AM, Chris Hegarty > wrote: > > > I should point out that the current batch of changes are focused on > support for systems where 127.0.0.1 doesn't exist, which is > relatively > straightforward and unexciting. > > > Sorry, what does this mean. IPv6-only environment with ::1, or no > loopback mechanism at all? > > > A system where 127.0.0.1 does not exist (in fact IPv4 is completely > absent), and "localhost" resolves to ::1. Ok. > A simple but pervasive change to global replace testing code via: > s/"127.0.0.1"/ InetAddress.getLoopbackAddress().getHostAddress()/g Right. This should be fine, but will likely show up mis-configurations on some of our systems. I'd be happy to help shake out any issues, once there is a patch available. -Chris. From michael.x.mcmahon at oracle.com Mon Mar 20 17:32:50 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 20 Mar 2017 17:32:50 +0000 Subject: RFR (xs) : 8177144 :sun/net/www/http/HttpClient/B8025710.java should run in ovm mode In-Reply-To: References: Message-ID: <58D01242.8010504@oracle.com> Looks fine Sean. - Michael. On 20/03/2017, 16:11, Se?n Coffey wrote: > Looking for a simple review. Test should be run in ovm mode : > > https://bugs.openjdk.java.net/browse/JDK-8177144 > > diff --git a/test/sun/net/www/http/HttpClient/B8025710.java > b/test/sun/net/www/http/HttpClient/B8025710.java > --- a/test/sun/net/www/http/HttpClient/B8025710.java > +++ b/test/sun/net/www/http/HttpClient/B8025710.java > @@ -37,6 +37,7 @@ > * @test > * @bug 8025710 > * @summary Proxied https connection reuse by HttpClient can send > CONNECT to the server > + * @run main/othervm B8025710 > */ > public class B8025710 { > From martinrb at google.com Mon Mar 20 21:53:21 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 20 Mar 2017 14:53:21 -0700 Subject: Let's improve IPv6 support In-Reply-To: References: <822d41bf-d055-342e-350c-69f7a1e3bd64@oracle.com> Message-ID: On Mon, Mar 20, 2017 at 2:46 PM, Alexander Smundak wrote: > Should this be a patch for JDK9 or JDK10? > It's too late for jdk9 initial release, although we might backport to jdk9.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akashche at redhat.com Wed Mar 22 23:51:18 2017 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 22 Mar 2017 23:51:18 +0000 Subject: [PATCH] 8035653: jdk8u152-b01 windows crash on DatagramSocket.getLocalAddress Message-ID: Hi, We found that 8035653 test from jdk9 [1] crashes jdk8u152-b01 on windows at this point [2] because "ia6_class" is not initialized. It looks like the following bit of 8035653 is missed in jdk8u152-b01: diff -r 83726fe0f756 src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c --- a/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Tue Mar 21 17:08:03 2017 -0700 +++ b/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Wed Mar 22 23:18:30 2017 +0000 @@ -87,6 +87,8 @@ IO_fd_fdID = NET_GetFileDescriptorID(env); CHECK_NULL(IO_fd_fdID); JNU_CHECK_EXCEPTION(env); + + initInetAddressIDs(env); } If it will be convenient, I can submit an issue+webrev and re-send this to jdk8u-dev list. But as 8u152 is not yet released and the fix is already in jdk9, I will appreciate some guidance on this problem. [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f6bf027e88e9/test/java/net/DatagramSocket/B8035653.java [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/83726fe0f756/src/share/native/java/net/net_util.c#l222 -- -Alex From kato at win6.jp Mon Mar 27 07:08:43 2017 From: kato at win6.jp (Jun-ya Kato) Date: Mon, 27 Mar 2017 16:08:43 +0900 (JST) Subject: Let's improve IPv6 support In-Reply-To: References: Message-ID: <20170327.160843.2019890920381169766.jkato@vanilla.ocn.ne.jp> > However, I'm also aware of three "hard problems" that would require > new features, and significant changes to current behavior: > - Address selection: https://bugs.openjdk.java.net/browse/JDK-8170568 JDK-8170568 is not IPv6 specific problem. Even if target-host has multiple IP addresses, java.net.Socket("target-host", port) constructor trys to connect to the only first one. Service provider often assigns IP addresses on his edge nodes for load balancing and reliabilty. For example, I could easily find that "amazon.com" DNS record has six IPv4 addresses. Name: amazon.com Address: 54.239.17.6 Name: amazon.com Address: 54.239.17.7 Name: amazon.com Address: 54.239.25.192 Name: amazon.com Address: 54.239.25.200 Name: amazon.com Address: 54.239.25.208 Name: amazon.com Address: 54.239.26.128 Most common Linux/UNIX network commands such as telnet, ssh, or netcat implement multiple addresses manuplation that trys all possible addresses until connetion is established. This behavior is useful for java.net.Socket(String hostname, int port) constructor. I also think that RFC6555 is more better solution. -- J. Kato kato at win6.jp From: Paul Marks Subject: Re: Let's improve IPv6 support Date: Mon, 27 Mar 2017 15:34:10 +0900 (JST) > On Fri, Mar 17, 2017 at 11:47 AM, Martin Buchholz wrote: >> Google cares a lot about IPv6, and not only because Vint Cerf works at >> Google. >> >> We have some local modifications and some networking expertise and intend to >> port/contribute that to openjdk10. >> >> Most of this is the work of my colleagues Alexander Smundak and Paul Marks. >> >> We hope we can do most of this work without asking too much of other net-dev >> engineers, but we will likely need help with porting to non-Linux platforms, >> running JPRT, and perhaps CCC/JEP process. >> >> We expect to make a large number of commits. Should there be a JEP to cover >> this? Is there a current net-dev engineer who feels they "own" this problem >> (Chris?)? > > I should point out that the current batch of changes are focused on > support for systems where 127.0.0.1 doesn't exist, which is relatively > straightforward and unexciting. > > However, I'm also aware of three "hard problems" that would require > new features, and significant changes to current behavior: > - Address selection: https://bugs.openjdk.java.net/browse/JDK-8170568 > - Default IP address formatting ("0:0:0:0:0:0:0:1" vs. RFC 5952) > - Parsing and formatting of host:port strings, e.g. "[::1]:80" > > From ashtonhogan at ymail.com Tue Mar 28 11:26:22 2017 From: ashtonhogan at ymail.com (ashtonhogan at ymail.com) Date: Tue, 28 Mar 2017 12:26:22 +0100 Subject: com.sun.httpserver Message-ID: <252570.48876.bm@smtp207.mail.ne1.yahoo.com> Hi all I was looking through the archives but did not find any answers to these questions so I figured I'd try here, hopefully this helps someone else as well. I've done some testing on the httpserver and come across some things: 1. No support for websockets (ws) or secure websockets (wss) - will this be in a future release? 2. When starting the server a number of threads are spawned regardless of whether you specify an executor or not. Was this the intention? If so then why does it spawn multiple threads when it could just spawn one for listening that places all HttpExchange instances into a BlockingQueue or something for the developer to use in a single or multithreaded environment? Thanks & Regards Ashton From michael.x.mcmahon at oracle.com Tue Mar 28 14:42:07 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 28 Mar 2017 15:42:07 +0100 Subject: com.sun.httpserver In-Reply-To: <252570.48876.bm@smtp207.mail.ne1.yahoo.com> References: <252570.48876.bm@smtp207.mail.ne1.yahoo.com> Message-ID: <58DA763F.6050002@oracle.com> Hi Ashton On 28/03/2017, 12:26, ashtonhogan at ymail.com wrote: > Hi all > > I was looking through the archives but did not find any answers to these questions so I figured I'd try here, hopefully this helps someone else as well. > > I've done some testing on the httpserver and come across some things: > > 1. No support for websockets (ws) or secure websockets (wss) - will this be in a future release? There are no plans at present to add support for websockets to this implementation. > 2. When starting the server a number of threads are spawned regardless of whether you specify an executor or not. Was this the intention? If so then why does it spawn multiple threads when it could just spawn one for listening that places all HttpExchange instances into a BlockingQueue or something for the developer to use in a single or multithreaded environment? Yes, just looking at the implementation, there are 2-3 threads created. One thread is the listener for incoming connections, plus one or two more for operating timer functionality. The executor is only used for handling incoming requests. Regards, Michael. > Thanks& Regards > Ashton From ashtonhogan at ymail.com Tue Mar 28 16:40:59 2017 From: ashtonhogan at ymail.com (ashtonhogan at ymail.com) Date: Tue, 28 Mar 2017 17:40:59 +0100 Subject: com.sun.httpserver Message-ID: <196783.41720.bm@smtp110.mail.ne1.yahoo.com> An HTML attachment was scrubbed... URL: From mhall at mhcomputing.net Tue Mar 28 16:54:11 2017 From: mhall at mhcomputing.net (Matthew Hall) Date: Tue, 28 Mar 2017 09:54:11 -0700 Subject: com.sun.httpserver In-Reply-To: <252570.48876.bm@smtp207.mail.ne1.yahoo.com> References: <252570.48876.bm@smtp207.mail.ne1.yahoo.com> Message-ID: <20170328165411.GE31948@mhcomputing.net> On Tue, Mar 28, 2017 at 12:26:22PM +0100, ashtonhogan at ymail.com wrote: > Hi all > > I was looking through the archives but did not find any answers to these questions so I figured I'd try here, hopefully this helps someone else as well. > > I've done some testing on the httpserver and come across some things: > > 1. No support for websockets (ws) or secure websockets (wss) - will this be in a future release? > > 2. When starting the server a number of threads are spawned regardless of whether you specify an executor or not. Was this the intention? If so then why does it spawn multiple threads when it could just spawn one for listening that places all HttpExchange instances into a BlockingQueue or something for the developer to use in a single or multithreaded environment? > > Thanks & Regards > Ashton Your email system mangled one of your reply emails. If you want a really great Java embedded web server I recommend using this one instead: https://grizzly.java.net/ It has way more features than the ancient com.sun.httpserver, and it's used in Glassfish and some other servlet containers. Matthew. From michael.x.mcmahon at oracle.com Tue Mar 28 17:09:17 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 28 Mar 2017 18:09:17 +0100 Subject: com.sun.httpserver In-Reply-To: <196783.41720.bm@smtp110.mail.ne1.yahoo.com> References: <196783.41720.bm@smtp110.mail.ne1.yahoo.com> Message-ID: <58DA98BD.9080500@oracle.com> Hi Ashton, On 28/03/2017, 17:40, ashtonhogan at ymail.com wrote: > Hi Michael > > Thanks for the below. > > 1. Would it be possible to contribute this feature or is there a > reason to not have it going forward? > I think it would be useful. Maybe Pavel here in Oracle might comment on it since he has done work on a client implementation. It probably depends on how much additional API footprint it would create. Are you offering to do it? > 2. Is it possible to disable the other threads and just have the > listener? Smaller devices that don't have as many cores really > struggle with multithreaded applications and if there are already > threads in an application it may add additional overhead and complexity > Yes, I think it would be possible to combine the timer functionality with the listener, and build the timing capability into the nio selector. Again that is more work, but if it is something you are offering to do..? Thanks, Michael. > Thanks & Regards > Ashton > > > -------- Original Message -------- > Subject: Re: com.sun.httpserver > From: Michael McMahon > To: ashtonhogan at ymail.com > CC: net-dev at openjdk.java.net > > > Hi Ashton > > On 28/03/2017, 12:26, ashtonhogan at ymail.com wrote: > > Hi all > > > > I was looking through the archives but did not find any answers > to these questions so I figured I'd try here, hopefully this helps > someone else as well. > > > > I've done some testing on the httpserver and come across some > things: > > > > 1. No support for websockets (ws) or secure websockets (wss) - > will this be in a future release? > There are no plans at present to add support for websockets to this > implementation. > > 2. When starting the server a number of threads are spawned > regardless of whether you specify an executor or not. Was this the > intention? If so then why does it spawn multiple threads when it > could just spawn one for listening that places all HttpExchange > instances into a BlockingQueue or something for the developer to > use in a single or multithreaded environment? > Yes, just looking at the implementation, there are 2-3 threads > created. > One thread is the listener for incoming connections, > plus one or two more for operating timer functionality. The > executor is > only used for handling incoming requests. > > Regards, > Michael. > > > Thanks& Regards > > Ashton > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashtonhogan at ymail.com Tue Mar 28 19:56:36 2017 From: ashtonhogan at ymail.com (Ashton Hogan) Date: Tue, 28 Mar 2017 19:56:36 +0000 (UTC) Subject: com.sun.httpserver In-Reply-To: <58DA98BD.9080500@oracle.com> References: <196783.41720.bm@smtp110.mail.ne1.yahoo.com> <58DA98BD.9080500@oracle.com> Message-ID: <1514887806.5766164.1490730996292@mail.yahoo.com> Hi Michael Thank you for the below 1. I would be happy to but I would need some direction on some of the more low-level stuff. I've tried going through RFC's but didn't really get anything constructive out of it. I've also read several books on the topic but can't seem to find one that gives information on the binary payload structures and flows. If you could let me know of a good place to get the information I need then I'd be happy to contribute this. I have already studied the existing source quite a bit so I am fairly familiar with it. 2. I don't fully understand the purpose of the timer and looking at the code it looks as if you could prevent it by changing MAX_REQ and MAX_RES to not be hard-coded to -1 but I'm not entirely sure what the implications of changing that would be. Again, I would be happy to contribute this but I would need access to more background information if it's possible? Thanks & RegardsAshton From: Michael McMahon To: "ashtonhogan at ymail.com" Cc: net-dev at openjdk.java.net; Pavel Rappo Sent: Tuesday, 28 March 2017, 18:09 Subject: Re: com.sun.httpserver Hi Ashton, On 28/03/2017, 17:40, ashtonhogan at ymail.com wrote: Hi Michael Thanks for the below. 1. Would it be possible to contribute this feature or is there a reason to not have it going forward? I think it would be useful. Maybe Pavel here in Oracle might comment on it since he has done work on a client implementation. It probably depends on how much additional API footprint it would create. Are you offering to do it? 2. Is it possible to disable the other threads and just have the listener? Smaller devices that don't have as many cores really struggle with multithreaded applications and if there are already threads in an application it may add additional overhead and complexity Yes, I think it would be possible to combine the timer functionality with the listener, and build the timing capability into the nio selector. Again that is more work, but if it is something you are offering to do..? Thanks, Michael. Thanks & Regards Ashton -------- Original Message -------- Subject: Re: com.sun.httpserver From: Michael McMahon To: ashtonhogan at ymail.com CC: net-dev at openjdk.java.net Hi Ashton On 28/03/2017, 12:26, ashtonhogan at ymail.com wrote: > Hi all > > I was looking through the archives but did not find any answers to these questions so I figured I'd try here, hopefully this helps someone else as well. > > I've done some testing on the httpserver and come across some things: > > 1. No support for websockets (ws) or secure websockets (wss) - will this be in a future release? There are no plans at present to add support for websockets to this implementation. > 2. When starting the server a number of threads are spawned regardless of whether you specify an executor or not. Was this the intention? If so then why does it spawn multiple threads when it could just spawn one for listening that places all HttpExchange instances into a BlockingQueue or something for the developer to use in a single or multithreaded environment? Yes, just looking at the implementation, there are 2-3 threads created. One thread is the listener for incoming connections, plus one or two more for operating timer functionality. The executor is only used for handling incoming requests. Regards, Michael. > Thanks& Regards > Ashton -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman.maurer at googlemail.com Thu Mar 30 14:36:26 2017 From: norman.maurer at googlemail.com (Norman Maurer) Date: Thu, 30 Mar 2017 16:36:26 +0200 Subject: Expose DNS Servers via public API Message-ID: Hi there, I am not sure if this is the correct list for the question but as relate to network I will just try. If its the wrong list please tell me which one would be better fitted. Is there reason why not expose the DNS Servers configured on a system. These are exposed in sun.net.dns.ResolverConfiguration but not exposed in any public way. Be able to access these would help people that want to do a custom dns lookup (for example non-blocking) like what we do in netty. If this is something that would be considered I can come up with a patch for it. Bye, Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Mar 30 14:58:07 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Mar 2017 15:58:07 +0100 Subject: Expose DNS Servers via public API In-Reply-To: References: Message-ID: <219e6b18-7bc0-745f-f7ea-032388904a06@oracle.com> On 30/03/2017 15:36, Norman Maurer wrote: > Hi there, > > I am not sure if this is the correct list for the question but as > relate to network I will just try. If its the wrong list please tell > me which one would be better fitted. > > Is there reason why not expose the DNS Servers configured on a system. > These are exposed in sun.net.dns.ResolverConfiguration but not exposed > in any public way. Be able to access these would help people that want > to do a custom dns lookup (for example non-blocking) like what we do > in netty. > If this is something that would be considered I can come up with a > patch for it. > One could imagine introducing an API in java.net that exposes more of the networking configuration but I think would require debate as to whether it's the right thing to do or not (esp. as the existing networking APIs are abstracted from whether resolution is done via DNS, host files, ..). An alternative might to see if it is exposed by the JNDI-DNS provider (the primary user of ResolverConfiguration and the reason it was created). It might already be exposed in the environment. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman.maurer at googlemail.com Thu Mar 30 14:59:52 2017 From: norman.maurer at googlemail.com (Norman Maurer) Date: Thu, 30 Mar 2017 16:59:52 +0200 Subject: Expose DNS Servers via public API In-Reply-To: <219e6b18-7bc0-745f-f7ea-032388904a06@oracle.com> References: <219e6b18-7bc0-745f-f7ea-032388904a06@oracle.com> Message-ID: <3A5BEC43-BF87-471A-9F8D-08DCC72FFB48@googlemail.com> > On 30. Mar 2017, at 16:58, Alan Bateman wrote: > > On 30/03/2017 15:36, Norman Maurer wrote: >> Hi there, >> >> I am not sure if this is the correct list for the question but as relate to network I will just try. If its the wrong list please tell me which one would be better fitted. >> >> Is there reason why not expose the DNS Servers configured on a system. These are exposed in sun.net.dns.ResolverConfiguration but not exposed in any public way. Be able to access these would help people that want to do a custom dns lookup (for example non-blocking) like what we do in netty. >> If this is something that would be considered I can come up with a patch for it. >> > One could imagine introducing an API in java.net that exposes more of the networking configuration but I think would require debate as to whether it's the right thing to do or not (esp. as the existing networking APIs are abstracted from whether resolution is done via DNS, host files, ..). > > An alternative might to see if it is exposed by the JNDI-DNS provider (the primary user of ResolverConfiguration and the reason it was created). It might already be exposed in the environment. > > -Alan Thats why I tried to kick-off the topic :) Thanks for the quick reply btw?. So is this list the right place for this discussion ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Mar 30 15:27:21 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Mar 2017 16:27:21 +0100 Subject: Expose DNS Servers via public API In-Reply-To: <3A5BEC43-BF87-471A-9F8D-08DCC72FFB48@googlemail.com> References: <219e6b18-7bc0-745f-f7ea-032388904a06@oracle.com> <3A5BEC43-BF87-471A-9F8D-08DCC72FFB48@googlemail.com> Message-ID: On 30/03/2017 15:59, Norman Maurer wrote: > Thats why I tried to kick-off the topic :) Thanks for the quick reply > btw?. So is this list the right place for this discussion ? > I just checked the docs for the JNDI-DNS provider [1] and it documents that the provider updates the java.naming.provider.url property with the configuration when it isn't initially specified. So I think this will do what you want: Hashtable env = new Hashtable<>(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.dns.DnsContextFactory"); env.put("java.naming.provider.url", "dns://"); DirContext ctx = new InitialDirContext(env); String dnsUrls = (String) ctx.getEnvironment().get("java.naming.provider.url")); -Alan [1] http://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-dns.html From norman.maurer at googlemail.com Thu Mar 30 15:43:23 2017 From: norman.maurer at googlemail.com (Norman Maurer) Date: Thu, 30 Mar 2017 17:43:23 +0200 Subject: Expose DNS Servers via public API In-Reply-To: References: <219e6b18-7bc0-745f-f7ea-032388904a06@oracle.com> <3A5BEC43-BF87-471A-9F8D-08DCC72FFB48@googlemail.com> Message-ID: <85C9D8BE-CE94-40DF-8F2D-493D6FAEAE6D@googlemail.com> Nice! This works :) Norman > On 30. Mar 2017, at 17:27, Alan Bateman wrote: > > On 30/03/2017 15:59, Norman Maurer wrote: > >> Thats why I tried to kick-off the topic :) Thanks for the quick reply btw?. So is this list the right place for this discussion ? >> > I just checked the docs for the JNDI-DNS provider [1] and it documents that the provider updates the java.naming.provider.url property with the configuration when it isn't initially specified. So I think this will do what you want: > > Hashtable env = new Hashtable<>(); > env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.dns.DnsContextFactory"); > env.put("java.naming.provider.url", "dns://"); > DirContext ctx = new InitialDirContext(env); > String dnsUrls = (String) ctx.getEnvironment().get("java.naming.provider.url")); > > -Alan > > [1] http://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-dns.html