From claes.redestad at oracle.com Wed Jan 2 09:02:31 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 Jan 2019 10:02:31 +0100 Subject: RFR: 8215990: Avoid using reflection to create common default URLStreamHandlers Message-ID: Hi, during bootstrap we load and use at least two of the jrt, file and jar URLStreamHandlers via URL$DefaultFactory. Avoiding use of reflection to instantiate these slightly speed up bootstrap by reducing number of classes loaded and doing fewer relatively expensive reflective operations: http://cr.openjdk.java.net/~redestad/8215990/jdk.00/ Thanks! /Claes From Alan.Bateman at oracle.com Wed Jan 2 10:04:35 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jan 2019 10:04:35 +0000 Subject: RFR: 8215990: Avoid using reflection to create common default URLStreamHandlers In-Reply-To: References: Message-ID: On 02/01/2019 09:02, Claes Redestad wrote: > Hi, > > during bootstrap we load and use at least two of the jrt, file and jar > URLStreamHandlers via URL$DefaultFactory. Avoiding use of reflection to > instantiate these slightly speed up bootstrap by reducing number of > classes loaded and doing fewer relatively expensive reflective > operations: > > http://cr.openjdk.java.net/~redestad/8215990/jdk.00/ This looks okay to me and will continue to work when the protocol is not in lower case (URL protocols/schemes are compared with regard to case). While we're in the area then it would be nice to eliminate the use of Class::newInstance too - if each of the built-in protocol handlers is public with a public no-arg constructor then getConstructor().newInstance() should do it. A bigger job of work in this area is to replace the use of Hashtable (handlers field). That's something for a bigger overhaul of course. We shy-ed away from doing this in JDK 9 due to OSGi implementations hacking the field directly. -Alan From claes.redestad at oracle.com Wed Jan 2 10:43:47 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 Jan 2019 11:43:47 +0100 Subject: RFR: 8215990: Avoid using reflection to create common default URLStreamHandlers In-Reply-To: References: Message-ID: <42af0440-8105-03c5-55b0-376fd3b42bcf@oracle.com> Hi, On 2019-01-02 11:04, Alan Bateman wrote: > On 02/01/2019 09:02, Claes Redestad wrote: >> Hi, >> >> during bootstrap we load and use at least two of the jrt, file and jar >> URLStreamHandlers via URL$DefaultFactory. Avoiding use of reflection to >> instantiate these slightly speed up bootstrap by reducing number of >> classes loaded and doing fewer relatively expensive reflective >> operations: >> >> http://cr.openjdk.java.net/~redestad/8215990/jdk.00/ > This looks okay to me and will continue to work when the protocol is not > in lower case (URL protocols/schemes are compared with regard to case). thanks! (The protocol input string should already be lower-case at this point) > > While we're in the area then it would be nice to eliminate the use of > Class::newInstance too - if each of the built-in protocol handlers is > public with a public no-arg constructor then > getConstructor().newInstance() should do it. To be perfectly compatible I think .getDeclaredConstructor().newInstance() should be used: http://cr.openjdk.java.net/~redestad/8215990/jdk.01 > > A bigger job of work in this area is to replace the use of Hashtable > (handlers field). That's something for a bigger overhaul of course. We > shy-ed away from doing this in JDK 9 due to OSGi implementations hacking > the field directly. I'm in favor of any effort to get rid of Hashtable usage, anywhere. :-) /Claes From Alan.Bateman at oracle.com Wed Jan 2 14:06:18 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jan 2019 14:06:18 +0000 Subject: RFR: 8215990: Avoid using reflection to create common default URLStreamHandlers In-Reply-To: <42af0440-8105-03c5-55b0-376fd3b42bcf@oracle.com> References: <42af0440-8105-03c5-55b0-376fd3b42bcf@oracle.com> Message-ID: <3ba5d8ed-b80c-99d5-f1a8-102f3d020044@oracle.com> On 02/01/2019 10:43, Claes Redestad wrote: > : > >> >> While we're in the area then it would be nice to eliminate the use of >> Class::newInstance too - if each of the built-in protocol handlers is >> public with a public no-arg constructor then >> getConstructor().newInstance() should do it. > > To be perfectly compatible I think > .getDeclaredConstructor().newInstance() should be used: > > http://cr.openjdk.java.net/~redestad/8215990/jdk.01 This looks okay. Using getConstructor should work here too because this is the built-in protocol handlers. I think the only compatibility concern with getConstructor in this code path would be if someone deploys a custom protocol handler in the sun.net.* tree via -Xbootclasspath/p or by patches a java.* or jdk.* module that is mapped to the boot loader and the protocol handler doesn't have a public no-arg constructor. If they set java.protocol.handlers.pkgs property then it uses lookupViaProperty and Class::newInstance as before. -Alan From chris.hegarty at oracle.com Mon Jan 7 14:33:48 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 7 Jan 2019 14:33:48 +0000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <285fd29d18994a74be86dd923a07e10b@sap.com> Message-ID: <00f3a69d-cf14-7194-f2d0-d7f96afecaaf@oracle.com> Steve, On 05/12/2018 10:50, Steve Groeger wrote: > Posting this to net-dev as well as ppc-aix-port-dev as this may be a > more appropriate mailing list to get responses about networking. > > I have performed the test Volker mentioned in an earlier post (on xLinux > machine, remove the ipv6 address from the ens32 interface but leaving > inte6 enabled on the system). > With this configuration the jdk/java/net/MulticastSocket/JoinLeave.java > test still passes, whereas on AIX with a similar configuration the test > fails. > For those with knowledge of networking, should this MulticastSocket test > pass if there is no ipv6 address enabled for the interface being used. If there is no interface, that supports multicasting, with an IPv6 address, then the test will not execute the particular IPv6 multicasting scenario. That is fine, the IPv6 portion of the test is effectively skipped, since it cannot be tested on the particular platform. ( One could separate IPv4 from IPv6 in this test, and rather return a jtreg skipped status if a suitable interface with IPv6 is not found. But is does not seem worth while. ) -Chris. From matthias.baesken at sap.com Wed Jan 9 08:36:21 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 9 Jan 2019 08:36:21 +0000 Subject: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress Message-ID: Hello, please review the following fix . In NetworkInterface.c and Inet6AddressImpl.c we have some coding that omits checking for ifa_addr == NULL when iterating on the result of the getifaddrs call. This is similar to what has been fixed in hotspot with https://bugs.openjdk.java.net/browse/JDK-8208676 The issues are in the bsd/macOS coding. However bsd/macOS also document that ifa_addr can be NULL in special cases (not sure how likely it is to see it "in the wild"). See https://www.freebsd.org/cgi/man.cgi?getifaddrs https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getifaddrs.3.html Additionally a small resource leak in NetworkInterface.c is fixed. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8216355 http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.1/ Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Jan 9 09:01:36 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 9 Jan 2019 09:01:36 +0000 Subject: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress In-Reply-To: References: Message-ID: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.2/ ( I noticed that I accidentally deleted a line in the AIX coding so I brought it back, and I updated the Copyright year info to 2019 ). Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 9. Januar 2019 09:36 To: net-dev Cc: 'Robin Westberg' Subject: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress Hello, please review the following fix . In NetworkInterface.c and Inet6AddressImpl.c we have some coding that omits checking for ifa_addr == NULL when iterating on the result of the getifaddrs call. This is similar to what has been fixed in hotspot with https://bugs.openjdk.java.net/browse/JDK-8208676 The issues are in the bsd/macOS coding. However bsd/macOS also document that ifa_addr can be NULL in special cases (not sure how likely it is to see it "in the wild"). See https://www.freebsd.org/cgi/man.cgi?getifaddrs https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getifaddrs.3.html Additionally a small resource leak in NetworkInterface.c is fixed. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8216355 http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.1/ Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Jan 9 11:15:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 9 Jan 2019 11:15:47 +0000 Subject: [CAUTION] RE: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress In-Reply-To: References: Message-ID: Hi Matthias, looks good to me. In src/java.base/unix/native/libnet/NetworkInterface.c, lines 1019 and 1034, I'd prefer if the style was: if (addr == NULL) { return 0; } Thanks Christoph From: net-dev On Behalf Of Baesken, Matthias Sent: Mittwoch, 9. Januar 2019 10:02 To: net-dev Cc: Robin Westberg Subject: [CAUTION] RE: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.2/ ( I noticed that I accidentally deleted a line in the AIX coding so I brought it back, and I updated the Copyright year info to 2019 ). Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 9. Januar 2019 09:36 To: net-dev > Cc: 'Robin Westberg' > Subject: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress Hello, please review the following fix . In NetworkInterface.c and Inet6AddressImpl.c we have some coding that omits checking for ifa_addr == NULL when iterating on the result of the getifaddrs call. This is similar to what has been fixed in hotspot with https://bugs.openjdk.java.net/browse/JDK-8208676 The issues are in the bsd/macOS coding. However bsd/macOS also document that ifa_addr can be NULL in special cases (not sure how likely it is to see it "in the wild"). See https://www.freebsd.org/cgi/man.cgi?getifaddrs https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getifaddrs.3.html Additionally a small resource leak in NetworkInterface.c is fixed. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8216355 http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.1/ Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Jan 9 14:10:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 9 Jan 2019 14:10:08 +0000 Subject: [CAUTION] RE: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review ! I updated the formatting : http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.3/ Robin : may I add you as reviewer too ? Thanks, Matthias From: Langer, Christoph Sent: Mittwoch, 9. Januar 2019 12:16 To: Baesken, Matthias Cc: net-dev ; Robin Westberg Subject: RE: [CAUTION] RE: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress Hi Matthias, looks good to me. In src/java.base/unix/native/libnet/NetworkInterface.c, lines 1019 and 1034, I'd prefer if the style was: if (addr == NULL) { return 0; } Thanks Christoph From: net-dev > On Behalf Of Baesken, Matthias Sent: Mittwoch, 9. Januar 2019 10:02 To: net-dev > Cc: Robin Westberg > Subject: [CAUTION] RE: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.2/ ( I noticed that I accidentally deleted a line in the AIX coding so I brought it back, and I updated the Copyright year info to 2019 ). Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 9. Januar 2019 09:36 To: net-dev > Cc: 'Robin Westberg' > Subject: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress Hello, please review the following fix . In NetworkInterface.c and Inet6AddressImpl.c we have some coding that omits checking for ifa_addr == NULL when iterating on the result of the getifaddrs call. This is similar to what has been fixed in hotspot with https://bugs.openjdk.java.net/browse/JDK-8208676 The issues are in the bsd/macOS coding. However bsd/macOS also document that ifa_addr can be NULL in special cases (not sure how likely it is to see it "in the wild"). See https://www.freebsd.org/cgi/man.cgi?getifaddrs https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getifaddrs.3.html Additionally a small resource leak in NetworkInterface.c is fixed. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8216355 http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.1/ Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.westberg at oracle.com Wed Jan 9 14:41:52 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 9 Jan 2019 15:41:52 +0100 Subject: [CAUTION] RE: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress In-Reply-To: References: Message-ID: <8224C388-8088-4534-8568-44F3F60366C8@oracle.com> Hi Matthias, Yes, looks fine to me! Best regards, Robin > On 9 Jan 2019, at 15:10, Baesken, Matthias wrote: > > Hi Christoph, thanks for the review ! > I updated the formatting : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.3/ > > Robin : may I add you as reviewer too ? > > Thanks, Matthias > > > From: Langer, Christoph > Sent: Mittwoch, 9. Januar 2019 12:16 > To: Baesken, Matthias > Cc: net-dev ; Robin Westberg > Subject: RE: [CAUTION] RE: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress > > Hi Matthias, > > looks good to me. > > In src/java.base/unix/native/libnet/NetworkInterface.c, lines 1019 and 1034, I?d prefer if the style was: > if (addr == NULL) { > return 0; > } > > Thanks > Christoph > > > From: net-dev > On Behalf Of Baesken, Matthias > Sent: Mittwoch, 9. Januar 2019 10:02 > To: net-dev > > Cc: Robin Westberg > > Subject: [CAUTION] RE: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.2/ > > > ( I noticed that I accidentally deleted a line in the AIX coding so I brought it back, and I updated the Copyright year info to 2019 ). > > Best regards, Matthias > > > From: Baesken, Matthias > Sent: Mittwoch, 9. Januar 2019 09:36 > To: net-dev > > Cc: 'Robin Westberg' > > Subject: RFR 8216355: missing NULL checks in libnet in interface iteration and potential resource leak in getMacAddress > > Hello, please review the following fix . > > In NetworkInterface.c and Inet6AddressImpl.c we have some coding that omits checking for ifa_addr == NULL when iterating on the result of the getifaddrs call. > This is similar to what has been fixed in hotspot with > > https://bugs.openjdk.java.net/browse/JDK-8208676 > > The issues are in the bsd/macOS coding. However bsd/macOS also document that ifa_addr can be NULL in special cases (not sure how likely it is to see it "in the wild"). > See > > > https://www.freebsd.org/cgi/man.cgi?getifaddrs > > https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getifaddrs.3.html > > > Additionally a small resource leak in NetworkInterface.c is fixed. > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8216355 > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8216355.1/ > > > Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From GROEGES at uk.ibm.com Wed Jan 9 15:20:21 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 9 Jan 2019 15:20:21 +0000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: <00f3a69d-cf14-7194-f2d0-d7f96afecaaf@oracle.com> References: <285fd29d18994a74be86dd923a07e10b@sap.com> <00f3a69d-cf14-7194-f2d0-d7f96afecaaf@oracle.com> Message-ID: Hi Chris, Thanks for responding. The IPv6 portion of the test is not being executed as you have mentioned. The errors I am seeing on AIX are when it runs the IPv4 portion of the test. The AIX system I am running on has IPv6 enabled but the interface that is being used for the IPv4 test (en0) doesn't have an IPv6/INET6 address configured for it. As can be seen from the output from the 'ifconfig -a' command en0: flags=1e084863,80480 inet 9.xxx.xxx.150 netmask 0xfffffe00 broadcast 9.xxx.xxx.255 tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 lo0: flags=e08084b,c0 inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255 inet6 ::1%1/64 tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1 The test does the following: try (MulticastSocket soc = new MulticastSocket()) { soc.setNetworkInterface(nif); soc.joinGroup(group); soc.leaveGroup(group); } catch (IOException e) { throw new UncheckedIOException(e); } The issue I am gettiing is when the test calls the following line soc.setNetworkInterface(nif); which basically ends up throwing an exception from the mcast_set_if_by_if_v6 native method in java.base/unix/native/libnet/PlainDatagramSocketImpl.c when it is doing the setsockopt which gets a EADDRNOTAVAIL error and throws an exception. The code is: if (setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_IF, (const char*)&index, sizeof(index)) < 0) { if (errno == EINVAL && index > 0) { JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", "IPV6_MULTICAST_IF failed (interface has IPv4 " "address only?)"); } else { JNU_ThrowByNameWithMessageAndLastError (env, JNU_JAVANETPKG "SocketException", "Error setting socket option"); } return; } If I run the test with '-Djava.net.preferIPv4Stack=true` it al works fine. Digging into the java code I can see that when the MulticastSocket is created using try (MulticastSocket soc = new MulticastSocket()) { it ends up in the datagramSocketCreate function in Java_java_net_PlainDatagramSocketImpl_datagramSocketCreate(JNIEnv *env, jobject this) { jobject fdObj = (*env)->GetObjectField(env, this, pdsi_fdID); int arg, fd, t = 1; char tmpbuf[1024]; int domain = ipv6_available() ? AF_INET6 : AF_INET; if (IS_NULL(fdObj)) { JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", "Socket closed"); return; } if ((fd = socket(domain, SOCK_DGRAM, 0)) == -1) { JNU_ThrowByNameWithMessageAndLastError (env, JNU_JAVANETPKG "SocketException", "Error creating socket"); return; } where it is creating a socket with a family of AF_INET6 because the ipv6_available() function returns true. then later we are trying to configure an interface on that socket that doesnt have an IPv6/INET6 address and hence why I think we get the EADDRNOTAVAIL error. I think I have an Linux system setup with a simarly configured interface (system has IPv6 configured but interface has no IPv6/INET6 address configured) but the test works fine when run on that system. This was why I was asking the question on whether this should work on AIX, or whether it should fail on Linux!!! Hoping that with the description above you might be able to let me know what the expected behaviour is. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Chris Hegarty To: Steve Groeger , net-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Date: 07/01/2019 14:34 Subject: Re: 8207404: MulticastSocket tests failing on Aix Steve, On 05/12/2018 10:50, Steve Groeger wrote: > Posting this to net-dev as well as ppc-aix-port-dev as this may be a > more appropriate mailing list to get responses about networking. > > I have performed the test Volker mentioned in an earlier post (on xLinux > machine, remove the ipv6 address from the ens32 interface but leaving > inte6 enabled on the system). > With this configuration the jdk/java/net/MulticastSocket/JoinLeave.java > test still passes, whereas on AIX with a similar configuration the test > fails. > For those with knowledge of networking, should this MulticastSocket test > pass if there is no ipv6 address enabled for the interface being used. If there is no interface, that supports multicasting, with an IPv6 address, then the test will not execute the particular IPv6 multicasting scenario. That is fine, the IPv6 portion of the test is effectively skipped, since it cannot be tested on the particular platform. ( One could separate IPv4 from IPv6 in this test, and rather return a jtreg skipped status if a suitable interface with IPv6 is not found. But is does not seem worth while. ) -Chris. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Thu Jan 10 18:23:40 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 10 Jan 2019 18:23:40 +0000 Subject: [13] RFR: 8216498: Confusing and unneeded wrapping of SSLHandshakeException Message-ID: <9a7c6655-2145-7dd0-5e68-cec8967f26fc@oracle.com> Hi, Please find below a fix for: 8216498: Confusing and unneeded wrapping of SSLHandshakeException https://bugs.openjdk.java.net/browse/JDK-8216498 Webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216498/webrev.00/ When an IOException occurs in the java.net.http HTTP/1.1 stack it eventually gets re-wrapped in another IOException that provides a more detailed message about the state of the parser at the point where the exception was raised. This however gets confusing if the original exception that gets wrapped is an SSLHandshakeException, as the state of the parser is usually not useful in that case, and the important information (about the handshake failure) then gets buried down the exception stack. This webrev alters the wrapping logic to not re-wrap the SSLHandshakeException. best regards, -- daniel From chris.hegarty at oracle.com Thu Jan 10 20:18:32 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Jan 2019 20:18:32 +0000 Subject: [13] RFR: 8216498: Confusing and unneeded wrapping of SSLHandshakeException In-Reply-To: <9a7c6655-2145-7dd0-5e68-cec8967f26fc@oracle.com> References: <9a7c6655-2145-7dd0-5e68-cec8967f26fc@oracle.com> Message-ID: > On 10 Jan 2019, at 18:23, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > 8216498: Confusing and unneeded wrapping of SSLHandshakeException > https://bugs.openjdk.java.net/browse/JDK-8216498 > > Webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216498/webrev.00/ This looks good to me. Thanks Daniel. -Chris. From ivan.gerasimov at oracle.com Fri Jan 11 04:29:08 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 10 Jan 2019 20:29:08 -0800 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86@oracle.com> Hello! This seems to be the last use of realloc() without proper handling of a failure. Would you please help review a trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From christoph.langer at sap.com Fri Jan 11 06:30:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 11 Jan 2019 06:30:02 +0000 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly In-Reply-To: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86@oracle.com> References: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86@oracle.com> Message-ID: Hi Ivan, looks good. Best regards Christoph > -----Original Message----- > From: net-dev On Behalf Of Ivan > Gerasimov > Sent: Freitag, 11. Januar 2019 05:29 > To: net-dev at openjdk.java.net > Subject: RFR 8007606 : Handle realloc() failure in > unix/native/libnet/net_util_md.c correctly > > Hello! > > This seems to be the last use of realloc() without proper handling of a > failure. > > Would you please help review a trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 > WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ > > Thanks in advance! > > -- > With kind regards, > Ivan Gerasimov From daniel.fuchs at oracle.com Fri Jan 11 11:20:00 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Jan 2019 11:20:00 +0000 Subject: [13] RFR: 8216498: Confusing and unneeded wrapping of SSLHandshakeException In-Reply-To: References: <9a7c6655-2145-7dd0-5e68-cec8967f26fc@oracle.com> Message-ID: Thanks Chris. More extensive test campaign revealed that I missed another wrapping point in HttpClientImpl::sendAsync. New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216498/webrev.01 best regards, -- daniel On 10/01/2019 20:18, Chris Hegarty wrote: > >> On 10 Jan 2019, at 18:23, Daniel Fuchs wrote: >> >> Hi, >> >> Please find below a fix for: >> 8216498: Confusing and unneeded wrapping of SSLHandshakeException >> https://bugs.openjdk.java.net/browse/JDK-8216498 >> >> Webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8216498/webrev.00/ > > This looks good to me. Thanks Daniel. > > -Chris. > From chris.hegarty at oracle.com Fri Jan 11 11:31:20 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Jan 2019 11:31:20 +0000 Subject: [13] RFR: 8216498: Confusing and unneeded wrapping of SSLHandshakeException In-Reply-To: References: <9a7c6655-2145-7dd0-5e68-cec8967f26fc@oracle.com> Message-ID: On 11/01/2019 11:20, Daniel Fuchs wrote: > Thanks Chris. > > More extensive test campaign revealed that I missed another > wrapping point in HttpClientImpl::sendAsync. > > New webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216498/webrev.01 Good catch. The updated webrev looks good. -Chris. From matthias.baesken at sap.com Fri Jan 11 12:43:16 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 11 Jan 2019 12:43:16 +0000 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly Message-ID: Hi Ivan, Shouldn't you reset localifsSize to 0 in case of the early return ? The comment says localifsSize is the size of the array so the size of the array is 0 again after freeing. 637 static struct localinterface *localifs = 0; 638 static int localifsSize = 0; /* size of array */ 639 static int nifs = 0; /* number of entries used in array */ ... 679 if (localifsTemp == 0) { 680 free(localifs); 681 localifs = 0; 682 nifs = 0; 683 fclose(f); 684 return; 685 } Best regards, Matthias > Date: Thu, 10 Jan 2019 20:29:08 -0800 > From: Ivan Gerasimov > To: "net-dev at openjdk.java.net" > Subject: RFR 8007606 : Handle realloc() failure in > unix/native/libnet/net_util_md.c correctly > Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hello! > > This seems to be the last use of realloc() without proper handling of a > failure. > > Would you please help review a trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 > WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ > > Thanks in advance! > > -- > With kind regards, > Ivan Gerasimov > > From matthias.baesken at sap.com Fri Jan 11 12:54:40 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 11 Jan 2019 12:54:40 +0000 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly In-Reply-To: References: Message-ID: (and btw. There seem to be a few other places in the coding where the realloc return value is not checked , see for example : jdk/src/hotspot/share/adlc/forms.cpp 50void NameList::addName(const char *name) { 51 if (_cur == _max) _names =(const char**)realloc(_names,(_max *=2)*sizeof(char*)); 52 _names[_cur++] = name; 53} jdk/src/java.base/share/native/libjimage/imageFile.cpp 225// Add a new image entry to the table. 226void ImageFileReaderTable::add(ImageFileReader* image) { 227 if (_count == _max) { 228 _max += _growth; 229 _table = static_cast(realloc(_table, _max * sizeof(ImageFileReader*))); 230 } 231 _table[_count++] = image; 232} However I think adjustments of those cod parts is out of scope of 8007606 . Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Freitag, 11. Januar 2019 13:43 > To: net-dev at openjdk.java.net > Subject: Re: RFR 8007606 : Handle realloc() failure in > unix/native/libnet/net_util_md.c correctly > > Hi Ivan, > > Shouldn't you reset localifsSize to 0 in case of the early return ? The > comment says localifsSize is the size of the array so the size of the array is 0 > again after freeing. > > > 637 static struct localinterface *localifs = 0; > 638 static int localifsSize = 0; /* size of array */ > 639 static int nifs = 0; /* number of entries used in array */ > > ... > > 679 if (localifsTemp == 0) { > 680 free(localifs); > 681 localifs = 0; > 682 nifs = 0; > 683 fclose(f); > 684 return; > 685 } > > > > > Best regards, Matthias > > > > > Date: Thu, 10 Jan 2019 20:29:08 -0800 > > From: Ivan Gerasimov > > To: "net-dev at openjdk.java.net" > > Subject: RFR 8007606 : Handle realloc() failure in > > unix/native/libnet/net_util_md.c correctly > > Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86 at oracle.com> > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > Hello! > > > > This seems to be the last use of realloc() without proper handling of a > > failure. > > > > Would you please help review a trivial fix? > > > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 > > WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ > > > > Thanks in advance! > > > > -- > > With kind regards, > > Ivan Gerasimov > > > > From chris.hegarty at oracle.com Fri Jan 11 16:28:38 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Jan 2019 16:28:38 +0000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <285fd29d18994a74be86dd923a07e10b@sap.com> <00f3a69d-cf14-7194-f2d0-d7f96afecaaf@oracle.com> Message-ID: <6c49e1f1-eecb-5c66-1ee0-71aaff6921e6@oracle.com> On 09/01/2019 15:20, Steve Groeger wrote: >... > > I think I have an Linux system setup with a simarly configured interface > (system has IPv6 configured but interface > has no IPv6/INET6 address configured) but the test works fine when run > on that system. This is what I observe too. Confirmed by looking at the test output in the jtr file. > This was why I was asking the question on whether this should work on > AIX, or whether it should fail on Linux!!! I suspect that this is an issue with the native setsockopt on AIX. That said, if it cannot be resolved on AIX, then maybe the networking native code on AIX, should workaround it. -Chris. From christoph.langer at sap.com Fri Jan 11 17:04:04 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 11 Jan 2019 17:04:04 +0000 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly In-Reply-To: References: Message-ID: <91a68f8b413d440f9ad689dafb17ef5b@sap.com> Hi, that's right, good catch. Either set localifs to 0 or maybe even keep the old pointer with the old value of localifs. I guess the case is a bit theoretical but it should be done right. In line 695 fclose (f); the formatting can be fixed (also remove space between fclose and the bracket). Thanks Christoph > -----Original Message----- > From: net-dev On Behalf Of > Baesken, Matthias > Sent: Freitag, 11. Januar 2019 13:43 > To: net-dev at openjdk.java.net > Subject: [CAUTION] Re: RFR 8007606 : Handle realloc() failure in > unix/native/libnet/net_util_md.c correctly > > Hi Ivan, > > Shouldn't you reset localifsSize to 0 in case of the early return ? The > comment says localifsSize is the size of the array so the size of the array is 0 > again after freeing. > > > 637 static struct localinterface *localifs = 0; > 638 static int localifsSize = 0; /* size of array */ > 639 static int nifs = 0; /* number of entries used in array */ > > ... > > 679 if (localifsTemp == 0) { > 680 free(localifs); > 681 localifs = 0; > 682 nifs = 0; > 683 fclose(f); > 684 return; > 685 } > > > > > Best regards, Matthias > > > > > Date: Thu, 10 Jan 2019 20:29:08 -0800 > > From: Ivan Gerasimov > > To: "net-dev at openjdk.java.net" > > Subject: RFR 8007606 : Handle realloc() failure in > > unix/native/libnet/net_util_md.c correctly > > Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86 at oracle.com> > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > Hello! > > > > This seems to be the last use of realloc() without proper handling of a > > failure. > > > > Would you please help review a trivial fix? > > > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 > > WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ > > > > Thanks in advance! > > > > -- > > With kind regards, > > Ivan Gerasimov > > > > From volker.simonis at gmail.com Fri Jan 11 17:28:35 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Jan 2019 18:28:35 +0100 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: <6c49e1f1-eecb-5c66-1ee0-71aaff6921e6@oracle.com> References: <285fd29d18994a74be86dd923a07e10b@sap.com> <00f3a69d-cf14-7194-f2d0-d7f96afecaaf@oracle.com> <6c49e1f1-eecb-5c66-1ee0-71aaff6921e6@oracle.com> Message-ID: I think the difference is in setMulticastInterface() in PlainDatagramSocketImpl.c #ifdef __linux__ mcast_set_if_by_if_v4(env, this, fd, value); if (ipv6_available()) { if ((*env)->ExceptionCheck(env)){ (*env)->ExceptionClear(env); } mcast_set_if_by_if_v6(env, this, fd, value); } #else /* __linux__ not defined */ if (ipv6_available()) { mcast_set_if_by_if_v6(env, this, fd, value); } else { mcast_set_if_by_if_v4(env, this, fd, value); } #endif /* __linux__ */ We should probably follow the Linux way for AIX as well. On Fri, Jan 11, 2019 at 5:29 PM Chris Hegarty wrote: > > > On 09/01/2019 15:20, Steve Groeger wrote: > >... > > > > I think I have an Linux system setup with a simarly configured interface > > (system has IPv6 configured but interface > > has no IPv6/INET6 address configured) but the test works fine when run > > on that system. > > This is what I observe too. Confirmed by looking at the test > output in the jtr file. > > > This was why I was asking the question on whether this should work on > > AIX, or whether it should fail on Linux!!! > > I suspect that this is an issue with the native setsockopt > on AIX. That said, if it cannot be resolved on AIX, then > maybe the networking native code on AIX, should workaround > it. > > -Chris. From daniel.fuchs at oracle.com Fri Jan 11 17:37:13 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Jan 2019 17:37:13 +0000 Subject: [13] RFR: 8216478: Cleanup HttpResponseImpl back reference to HttpConnection Message-ID: Hi, Please find below a fix for: 8216478: Cleanup HttpResponseImpl back reference to HttpConnection https://bugs.openjdk.java.net/browse/JDK-8216478 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216478/webrev.00/ HttpResponseImpl keeps an internal hard reference to the Exchange and HttpConnection objects which were involved in the exchange through which the response was received. This has the inconvenience of pinning a number of auxiliary internal objects in memory until all references to the HttpResponse is released by the application code. These internal references are only useful in the case of the initial request that establishes a WebSocket connection. This small patch proposes to only keep them in the case where the request is a WebSocket connect request. This should avoid pinning these objects in memory until the reference to the HttpResponseImpl is released by user code for the regular case where no WebSocket is involved. There's no additional non-regression test - but I have verified that all existing tests are still passing. best regards, -- daniel From ivan.gerasimov at oracle.com Fri Jan 11 19:30:18 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 11 Jan 2019 11:30:18 -0800 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly In-Reply-To: References: Message-ID: Good catch, thank you! Indeed, if we don't reset localifsSize then we could end up accessing already freed memory, which is worse than just a memory leak. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8007606/01/webrev/ With kind regards, Ivan On 1/11/19 4:43 AM, Baesken, Matthias wrote: > Hi Ivan, > > Shouldn't you reset localifsSize to 0 in case of the early return ? The comment says localifsSize is the size of the array so the size of the array is 0 again after freeing. > > > 637 static struct localinterface *localifs = 0; > 638 static int localifsSize = 0; /* size of array */ > 639 static int nifs = 0; /* number of entries used in array */ > > ... > > 679 if (localifsTemp == 0) { > 680 free(localifs); > 681 localifs = 0; > 682 nifs = 0; > 683 fclose(f); > 684 return; > 685 } > > > > > Best regards, Matthias > > > >> Date: Thu, 10 Jan 2019 20:29:08 -0800 >> From: Ivan Gerasimov >> To: "net-dev at openjdk.java.net" >> Subject: RFR 8007606 : Handle realloc() failure in >> unix/native/libnet/net_util_md.c correctly >> Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86 at oracle.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> Hello! >> >> This seems to be the last use of realloc() without proper handling of a >> failure. >> >> Would you please help review a trivial fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ >> >> Thanks in advance! >> >> -- >> With kind regards, >> Ivan Gerasimov >> >> > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Fri Jan 11 19:34:01 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 11 Jan 2019 11:34:01 -0800 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly In-Reply-To: <91a68f8b413d440f9ad689dafb17ef5b@sap.com> References: <91a68f8b413d440f9ad689dafb17ef5b@sap.com> Message-ID: Thank you Christoph! Mixed code formatting style is used in this file. There are too many places where an extra space is put after a function name. I think it's better to only fix the style on the already touched lines to avoid blurring the fix. With kind regards, Ivan On 1/11/19 9:04 AM, Langer, Christoph wrote: > Hi, > > that's right, good catch. Either set localifs to 0 or maybe even keep the old pointer with the old value of localifs. I guess the case is a bit theoretical but it should be done right. > > In line 695 fclose (f); the formatting can be fixed (also remove space between fclose and the bracket). > > Thanks > Christoph > > >> -----Original Message----- >> From: net-dev On Behalf Of >> Baesken, Matthias >> Sent: Freitag, 11. Januar 2019 13:43 >> To: net-dev at openjdk.java.net >> Subject: [CAUTION] Re: RFR 8007606 : Handle realloc() failure in >> unix/native/libnet/net_util_md.c correctly >> >> Hi Ivan, >> >> Shouldn't you reset localifsSize to 0 in case of the early return ? The >> comment says localifsSize is the size of the array so the size of the array is 0 >> again after freeing. >> >> >> 637 static struct localinterface *localifs = 0; >> 638 static int localifsSize = 0; /* size of array */ >> 639 static int nifs = 0; /* number of entries used in array */ >> >> ... >> >> 679 if (localifsTemp == 0) { >> 680 free(localifs); >> 681 localifs = 0; >> 682 nifs = 0; >> 683 fclose(f); >> 684 return; >> 685 } >> >> >> >> >> Best regards, Matthias >> >> >> >>> Date: Thu, 10 Jan 2019 20:29:08 -0800 >>> From: Ivan Gerasimov >>> To: "net-dev at openjdk.java.net" >>> Subject: RFR 8007606 : Handle realloc() failure in >>> unix/native/libnet/net_util_md.c correctly >>> Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86 at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> Hello! >>> >>> This seems to be the last use of realloc() without proper handling of a >>> failure. >>> >>> Would you please help review a trivial fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ >>> >>> Thanks in advance! >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> >>> > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Fri Jan 11 19:34:10 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 11 Jan 2019 11:34:10 -0800 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly In-Reply-To: <91a68f8b413d440f9ad689dafb17ef5b@sap.com> References: <91a68f8b413d440f9ad689dafb17ef5b@sap.com> Message-ID: <803a86f5-a595-76c3-fb03-c185fec4e408@oracle.com> Thank you Christoph! Mixed code formatting style is used in this file. There are too many places where an extra space is put after a function name. I think it's better to only fix the style on the already touched lines to avoid blurring the fix. With kind regards, Ivan On 1/11/19 9:04 AM, Langer, Christoph wrote: > Hi, > > that's right, good catch. Either set localifs to 0 or maybe even keep the old pointer with the old value of localifs. I guess the case is a bit theoretical but it should be done right. > > In line 695 fclose (f); the formatting can be fixed (also remove space between fclose and the bracket). > > Thanks > Christoph > > >> -----Original Message----- >> From: net-dev On Behalf Of >> Baesken, Matthias >> Sent: Freitag, 11. Januar 2019 13:43 >> To: net-dev at openjdk.java.net >> Subject: [CAUTION] Re: RFR 8007606 : Handle realloc() failure in >> unix/native/libnet/net_util_md.c correctly >> >> Hi Ivan, >> >> Shouldn't you reset localifsSize to 0 in case of the early return ? The >> comment says localifsSize is the size of the array so the size of the array is 0 >> again after freeing. >> >> >> 637 static struct localinterface *localifs = 0; >> 638 static int localifsSize = 0; /* size of array */ >> 639 static int nifs = 0; /* number of entries used in array */ >> >> ... >> >> 679 if (localifsTemp == 0) { >> 680 free(localifs); >> 681 localifs = 0; >> 682 nifs = 0; >> 683 fclose(f); >> 684 return; >> 685 } >> >> >> >> >> Best regards, Matthias >> >> >> >>> Date: Thu, 10 Jan 2019 20:29:08 -0800 >>> From: Ivan Gerasimov >>> To: "net-dev at openjdk.java.net" >>> Subject: RFR 8007606 : Handle realloc() failure in >>> unix/native/libnet/net_util_md.c correctly >>> Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86 at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> Hello! >>> >>> This seems to be the last use of realloc() without proper handling of a >>> failure. >>> >>> Would you please help review a trivial fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ >>> >>> Thanks in advance! >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> >>> > -- With kind regards, Ivan Gerasimov From chris.hegarty at oracle.com Sat Jan 12 14:20:30 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 12 Jan 2019 14:20:30 +0000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <285fd29d18994a74be86dd923a07e10b@sap.com> <00f3a69d-cf14-7194-f2d0-d7f96afecaaf@oracle.com> <6c49e1f1-eecb-5c66-1ee0-71aaff6921e6@oracle.com> Message-ID: > On 11 Jan 2019, at 17:28, Volker Simonis wrote: > > I think the difference is in setMulticastInterface() in > PlainDatagramSocketImpl.c > > #ifdef __linux__ > mcast_set_if_by_if_v4(env, this, fd, value); > if (ipv6_available()) { > if ((*env)->ExceptionCheck(env)){ > (*env)->ExceptionClear(env); > } > mcast_set_if_by_if_v6(env, this, fd, value); > } > #else /* __linux__ not defined */ > if (ipv6_available()) { > mcast_set_if_by_if_v6(env, this, fd, value); > } else { > mcast_set_if_by_if_v4(env, this, fd, value); > } > #endif /* __linux__ */ > > We should probably follow the Linux way for AIX as well. I agree. -Chris. >> On Fri, Jan 11, 2019 at 5:29 PM Chris Hegarty wrote: >> >> >>> On 09/01/2019 15:20, Steve Groeger wrote: >>> ... >>> >>> I think I have an Linux system setup with a simarly configured interface >>> (system has IPv6 configured but interface >>> has no IPv6/INET6 address configured) but the test works fine when run >>> on that system. >> >> This is what I observe too. Confirmed by looking at the test >> output in the jtr file. >> >>> This was why I was asking the question on whether this should work on >>> AIX, or whether it should fail on Linux!!! >> >> I suspect that this is an issue with the native setsockopt >> on AIX. That said, if it cannot be resolved on AIX, then >> maybe the networking native code on AIX, should workaround >> it. >> >> -Chris. From chris.hegarty at oracle.com Sat Jan 12 14:23:13 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 12 Jan 2019 14:23:13 +0000 Subject: [13] RFR: 8216478: Cleanup HttpResponseImpl back reference to HttpConnection In-Reply-To: References: Message-ID: <64F8F695-5EDD-43D2-BC09-EA58293E10D1@oracle.com> > On 11 Jan 2019, at 17:37, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8216478: Cleanup HttpResponseImpl back reference to HttpConnection > https://bugs.openjdk.java.net/browse/JDK-8216478 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216478/webrev.00/ This looks good to me Daniel. Thanks. -Chris. From daniel.fuchs at oracle.com Mon Jan 14 12:28:53 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 14 Jan 2019 12:28:53 +0000 Subject: [13] RFR - 8216974: HttpConnection not returned to the pool after 204 response Message-ID: Hi, Please find below a patch for: 8216974: HttpConnection not returned to the pool after 204 response https://bugs.openjdk.java.net/browse/JDK-8216974 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216974/webrev.00/ While investigating some other bug I noticed that HTTP/1.1 connections where not returned to the pool when the server replied with correct 204 response. This is because the HttpResponse is synthesized directly by the MultiExchange on reception of the response headers. The MultiExchange should notify the ExchangeImpl that no body will be coming so that the ExchangeImpl can take appropriate actions. best regards, -- daniel From GROEGES at uk.ibm.com Mon Jan 14 13:19:38 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Mon, 14 Jan 2019 13:19:38 +0000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <285fd29d18994a74be86dd923a07e10b@sap.com> <00f3a69d-cf14-7194-f2d0-d7f96afecaaf@oracle.com> <6c49e1f1-eecb-5c66-1ee0-71aaff6921e6@oracle.com> Message-ID: Hi Chris / Volker, I had already tried doing the same as is done for Linux, ie calling this first mcast_set_if_by_if_v4(env, this, fd, value); This still fails for some reason with EADDRNOTAVAIL. This error gets cleared by the if ((*env)->ExceptionCheck(env)){ (*env)->ExceptionClear(env); } as ipv6_available() still returns true, but we then still try and call mcast_set_if_by_if_v6(env, this, fd, value); which again fails with EADDRNOTAVAIL. So we have the same result. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Chris Hegarty To: Volker Simonis Cc: Steve Groeger , ppc-aix-port-dev at openjdk.java.net, net-dev Date: 12/01/2019 14:21 Subject: Re: 8207404: MulticastSocket tests failing on Aix > On 11 Jan 2019, at 17:28, Volker Simonis wrote: > > I think the difference is in setMulticastInterface() in > PlainDatagramSocketImpl.c > > #ifdef __linux__ > mcast_set_if_by_if_v4(env, this, fd, value); > if (ipv6_available()) { > if ((*env)->ExceptionCheck(env)){ > (*env)->ExceptionClear(env); > } > mcast_set_if_by_if_v6(env, this, fd, value); > } > #else /* __linux__ not defined */ > if (ipv6_available()) { > mcast_set_if_by_if_v6(env, this, fd, value); > } else { > mcast_set_if_by_if_v4(env, this, fd, value); > } > #endif /* __linux__ */ > > We should probably follow the Linux way for AIX as well. I agree. -Chris. >> On Fri, Jan 11, 2019 at 5:29 PM Chris Hegarty wrote: >> >> >>> On 09/01/2019 15:20, Steve Groeger wrote: >>> ... >>> >>> I think I have an Linux system setup with a simarly configured interface >>> (system has IPv6 configured but interface >>> has no IPv6/INET6 address configured) but the test works fine when run >>> on that system. >> >> This is what I observe too. Confirmed by looking at the test >> output in the jtr file. >> >>> This was why I was asking the question on whether this should work on >>> AIX, or whether it should fail on Linux!!! >> >> I suspect that this is an issue with the native setsockopt >> on AIX. That said, if it cannot be resolved on AIX, then >> maybe the networking native code on AIX, should workaround >> it. >> >> -Chris. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Mon Jan 14 14:08:52 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 14 Jan 2019 15:08:52 +0100 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <285fd29d18994a74be86dd923a07e10b@sap.com> <00f3a69d-cf14-7194-f2d0-d7f96afecaaf@oracle.com> <6c49e1f1-eecb-5c66-1ee0-71aaff6921e6@oracle.com> Message-ID: On Mon, Jan 14, 2019 at 2:19 PM Steve Groeger wrote: > > Hi Chris / Volker, > > I had already tried doing the same as is done for Linux, ie calling this first > > mcast_set_if_by_if_v4(env, this, fd, value); > > This still fails for some reason with EADDRNOTAVAIL. Finding this out is probably the main challenge in order to solve this issue and one of the reason why we asked IBM for assistance :) I suppose there must be a possibility to set a socket option for an IPv4 socket on AIX even if IPv6 is enabled. Otherwise this is probably an AIX problem/bug which should be fixed there (where, again, we need assistance from IBM). The man-page (https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/ssocko.htm) mentions the following: IP_MULTICAST_IF: et interface over which outgoing multicast datagrams should be sent. This option is only supported for sockets with an address family of AF_INET and type of SOCK_DGRAM or SOCK_RAW. Maybe the interface is erroneously in the AF_INET6 family? The man-page only mentions the following for EADDRNOTAVAIL: EADDRNOTAVAIL: Address not available. For the IP_ADD_MEMBERSHIP or IP_DROP_MEMBERSHIP operations, this error code indicates that an incorrect address was specified for either the imr_multiaddr or imr_interface parameter value. > This error gets cleared by the > > if ((*env)->ExceptionCheck(env)){ > (*env)->ExceptionClear(env); > } > > as ipv6_available() still returns true, but we then still try and call > > mcast_set_if_by_if_v6(env, this, fd, value); > > which again fails with EADDRNOTAVAIL. So we have the same result. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Chris Hegarty > To: Volker Simonis > Cc: Steve Groeger , ppc-aix-port-dev at openjdk.java.net, net-dev > Date: 12/01/2019 14:21 > Subject: Re: 8207404: MulticastSocket tests failing on Aix > ________________________________ > > > > > > > On 11 Jan 2019, at 17:28, Volker Simonis wrote: > > > > I think the difference is in setMulticastInterface() in > > PlainDatagramSocketImpl.c > > > > #ifdef __linux__ > > mcast_set_if_by_if_v4(env, this, fd, value); > > if (ipv6_available()) { > > if ((*env)->ExceptionCheck(env)){ > > (*env)->ExceptionClear(env); > > } > > mcast_set_if_by_if_v6(env, this, fd, value); > > } > > #else /* __linux__ not defined */ > > if (ipv6_available()) { > > mcast_set_if_by_if_v6(env, this, fd, value); > > } else { > > mcast_set_if_by_if_v4(env, this, fd, value); > > } > > #endif /* __linux__ */ > > > > We should probably follow the Linux way for AIX as well. > > I agree. > > -Chris. > > >> On Fri, Jan 11, 2019 at 5:29 PM Chris Hegarty wrote: > >> > >> > >>> On 09/01/2019 15:20, Steve Groeger wrote: > >>> ... > >>> > >>> I think I have an Linux system setup with a simarly configured interface > >>> (system has IPv6 configured but interface > >>> has no IPv6/INET6 address configured) but the test works fine when run > >>> on that system. > >> > >> This is what I observe too. Confirmed by looking at the test > >> output in the jtr file. > >> > >>> This was why I was asking the question on whether this should work on > >>> AIX, or whether it should fail on Linux!!! > >> > >> I suspect that this is an issue with the native setsockopt > >> on AIX. That said, if it cannot be resolved on AIX, then > >> maybe the networking native code on AIX, should workaround > >> it. > >> > >> -Chris. > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From GROEGES at uk.ibm.com Mon Jan 14 14:30:41 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Mon, 14 Jan 2019 14:30:41 +0000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <00f3a69d-cf14-7194-f2d0-d7f96afecaaf@oracle.com> <6c49e1f1-eecb-5c66-1ee0-71aaff6921e6@oracle.com> Message-ID: Hi Volker, The reason the mcast_set_if_by_if_v4(env, this, fd, value); probably fails is that the socket that we are trying to set the IPPROTO_IP, IP_MULTICAST_IF options on has been created with the AF_INET6 family, and these options may not be valid. The socket is setup with the AF_INET6 family because ipv6_available() returns true, as the AIX system does support INET6/IPv6. It is just that the interface we are using doesnt have an INET6 address associated with it. I am checking with the AIX/C compiler team in IBM to see if this a bug or not. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Volker Simonis To: Steve Groeger Cc: Chris Hegarty , net-dev , ppc-aix-port-dev at openjdk.java.net Date: 14/01/2019 14:11 Subject: Re: 8207404: MulticastSocket tests failing on Aix On Mon, Jan 14, 2019 at 2:19 PM Steve Groeger wrote: > > Hi Chris / Volker, > > I had already tried doing the same as is done for Linux, ie calling this first > > mcast_set_if_by_if_v4(env, this, fd, value); > > This still fails for some reason with EADDRNOTAVAIL. Finding this out is probably the main challenge in order to solve this issue and one of the reason why we asked IBM for assistance :) I suppose there must be a possibility to set a socket option for an IPv4 socket on AIX even if IPv6 is enabled. Otherwise this is probably an AIX problem/bug which should be fixed there (where, again, we need assistance from IBM). The man-page ( https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/ssocko.htm) mentions the following: IP_MULTICAST_IF: et interface over which outgoing multicast datagrams should be sent. This option is only supported for sockets with an address family of AF_INET and type of SOCK_DGRAM or SOCK_RAW. Maybe the interface is erroneously in the AF_INET6 family? The man-page only mentions the following for EADDRNOTAVAIL: EADDRNOTAVAIL: Address not available. For the IP_ADD_MEMBERSHIP or IP_DROP_MEMBERSHIP operations, this error code indicates that an incorrect address was specified for either the imr_multiaddr or imr_interface parameter value. > This error gets cleared by the > > if ((*env)->ExceptionCheck(env)){ > (*env)->ExceptionClear(env); > } > > as ipv6_available() still returns true, but we then still try and call > > mcast_set_if_by_if_v6(env, this, fd, value); > > which again fails with EADDRNOTAVAIL. So we have the same result. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Chris Hegarty > To: Volker Simonis > Cc: Steve Groeger , ppc-aix-port-dev at openjdk.java.net, net-dev > Date: 12/01/2019 14:21 > Subject: Re: 8207404: MulticastSocket tests failing on Aix > ________________________________ > > > > > > > On 11 Jan 2019, at 17:28, Volker Simonis wrote: > > > > I think the difference is in setMulticastInterface() in > > PlainDatagramSocketImpl.c > > > > #ifdef __linux__ > > mcast_set_if_by_if_v4(env, this, fd, value); > > if (ipv6_available()) { > > if ((*env)->ExceptionCheck(env)){ > > (*env)->ExceptionClear(env); > > } > > mcast_set_if_by_if_v6(env, this, fd, value); > > } > > #else /* __linux__ not defined */ > > if (ipv6_available()) { > > mcast_set_if_by_if_v6(env, this, fd, value); > > } else { > > mcast_set_if_by_if_v4(env, this, fd, value); > > } > > #endif /* __linux__ */ > > > > We should probably follow the Linux way for AIX as well. > > I agree. > > -Chris. > > >> On Fri, Jan 11, 2019 at 5:29 PM Chris Hegarty wrote: > >> > >> > >>> On 09/01/2019 15:20, Steve Groeger wrote: > >>> ... > >>> > >>> I think I have an Linux system setup with a simarly configured interface > >>> (system has IPv6 configured but interface > >>> has no IPv6/INET6 address configured) but the test works fine when run > >>> on that system. > >> > >> This is what I observe too. Confirmed by looking at the test > >> output in the jtr file. > >> > >>> This was why I was asking the question on whether this should work on > >>> AIX, or whether it should fail on Linux!!! > >> > >> I suspect that this is an issue with the native setsockopt > >> on AIX. That said, if it cannot be resolved on AIX, then > >> maybe the networking native code on AIX, should workaround > >> it. > >> > >> -Chris. > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Jan 15 09:07:35 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Jan 2019 09:07:35 +0000 Subject: [13] RFR - 8216974: HttpConnection not returned to the pool after 204 response In-Reply-To: References: Message-ID: <8BD416BE-6BC6-4097-88B4-06514DE1078B@oracle.com> > On 14 Jan 2019, at 12:28, Daniel Fuchs wrote: > > Hi, > > Please find below a patch for: > > 8216974: HttpConnection not returned to the pool after 204 response > https://bugs.openjdk.java.net/browse/JDK-8216974 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216974/webrev.00/ Looks good Daniel. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Jan 15 15:16:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Jan 2019 15:16:14 +0000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <00f3a69d-cf14-7194-f2d0-d7f96afecaaf@oracle.com> <6c49e1f1-eecb-5c66-1ee0-71aaff6921e6@oracle.com> Message-ID: <17df0a7e2f5d4b028dd570621216f77b@sap.com> Hi Steve, I have looked into this topic. I started some work in that area a few years ago and never finished it. I think the root cause of the issue got already pointed out in this discussion. The JVM (correctly) detects that the system is capable of IPv6 and hence opens new sockets with address family AF_INET6. This type of socket shall allow for communication in both domains, IPv6 and IPv4. To ensure the dual stack socket, we also set socket option IPV6_V6ONLY to '0' which should make sure it's not an IPv6 only socket. This is the way, the standard TCP/UDP socket communication works in the JDK, also on AIX. Now, for multicasting, the VM wants to set the multicast interface. At that point, the socket is not yet bound to a local address or has joined a multicast group which might restrict the address type. So, we need either setsockopt(IPV6_MULTICAST_IF) or setsockopt(IP_MULTICAST_IF) to work. The documentation cited by Volker (https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/ssocko.htm) is quite explicit in that IP_MULTICAST_IF is for AF_INET sockets and IPV6_MULTICAST_IF is for AF_INET6 type sockets. So I would expect, that IPV6_MULTICAST_IF works, even for an interface without configured IPv6 address. So, while this is nothing for the compiler folks, it is something for the AIX runtime/network people. Can you address that within IBM? Maybe the AIX experts have a suggestion if there's already a way to code around this. And if it's not possible to get this to work with the existing APIs, would it be possible for you to open a PMR with IBM or find any other means to get that fixed in the OS? Anyway, I think even if IBM can fix this in AIX, it'll be in future versions only. So I'll go ahead and create a patch for modifying the failing tests to be more tolerant to such type of system configurations on AIX. I will send an RFR mail soon. Best regards Christoph From: net-dev On Behalf Of Steve Groeger Sent: Montag, 14. Januar 2019 15:31 To: Volker Simonis Cc: ppc-aix-port-dev at openjdk.java.net; net-dev Subject: Re: 8207404: MulticastSocket tests failing on Aix Hi Volker, The reason the mcast_set_if_by_if_v4(env, this, fd, value); probably fails is that the socket that we are trying to set the IPPROTO_IP, IP_MULTICAST_IF options on has been created with the AF_INET6 family, and these options may not be valid. The socket is setup with the AF_INET6 family because ipv6_available() returns true, as the AIX system does support INET6/IPv6. It is just that the interface we are using doesnt have an INET6 address associated with it. I am checking with the AIX/C compiler team in IBM to see if this a bug or not. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Volker Simonis > To: Steve Groeger > Cc: Chris Hegarty >, net-dev >, ppc-aix-port-dev at openjdk.java.net Date: 14/01/2019 14:11 Subject: Re: 8207404: MulticastSocket tests failing on Aix ________________________________ On Mon, Jan 14, 2019 at 2:19 PM Steve Groeger > wrote: > > Hi Chris / Volker, > > I had already tried doing the same as is done for Linux, ie calling this first > > mcast_set_if_by_if_v4(env, this, fd, value); > > This still fails for some reason with EADDRNOTAVAIL. Finding this out is probably the main challenge in order to solve this issue and one of the reason why we asked IBM for assistance :) I suppose there must be a possibility to set a socket option for an IPv4 socket on AIX even if IPv6 is enabled. Otherwise this is probably an AIX problem/bug which should be fixed there (where, again, we need assistance from IBM). The man-page (https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/ssocko.htm) mentions the following: IP_MULTICAST_IF: et interface over which outgoing multicast datagrams should be sent. This option is only supported for sockets with an address family of AF_INET and type of SOCK_DGRAM or SOCK_RAW. Maybe the interface is erroneously in the AF_INET6 family? The man-page only mentions the following for EADDRNOTAVAIL: EADDRNOTAVAIL: Address not available. For the IP_ADD_MEMBERSHIP or IP_DROP_MEMBERSHIP operations, this error code indicates that an incorrect address was specified for either the imr_multiaddr or imr_interface parameter value. > This error gets cleared by the > > if ((*env)->ExceptionCheck(env)){ > (*env)->ExceptionClear(env); > } > > as ipv6_available() still returns true, but we then still try and call > > mcast_set_if_by_if_v6(env, this, fd, value); > > which again fails with EADDRNOTAVAIL. So we have the same result. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Chris Hegarty > > To: Volker Simonis > > Cc: Steve Groeger >, ppc-aix-port-dev at openjdk.java.net, net-dev > > Date: 12/01/2019 14:21 > Subject: Re: 8207404: MulticastSocket tests failing on Aix > ________________________________ > > > > > > > On 11 Jan 2019, at 17:28, Volker Simonis > wrote: > > > > I think the difference is in setMulticastInterface() in > > PlainDatagramSocketImpl.c > > > > #ifdef __linux__ > > mcast_set_if_by_if_v4(env, this, fd, value); > > if (ipv6_available()) { > > if ((*env)->ExceptionCheck(env)){ > > (*env)->ExceptionClear(env); > > } > > mcast_set_if_by_if_v6(env, this, fd, value); > > } > > #else /* __linux__ not defined */ > > if (ipv6_available()) { > > mcast_set_if_by_if_v6(env, this, fd, value); > > } else { > > mcast_set_if_by_if_v4(env, this, fd, value); > > } > > #endif /* __linux__ */ > > > > We should probably follow the Linux way for AIX as well. > > I agree. > > -Chris. > > >> On Fri, Jan 11, 2019 at 5:29 PM Chris Hegarty > wrote: > >> > >> > >>> On 09/01/2019 15:20, Steve Groeger wrote: > >>> ... > >>> > >>> I think I have an Linux system setup with a simarly configured interface > >>> (system has IPv6 configured but interface > >>> has no IPv6/INET6 address configured) but the test works fine when run > >>> on that system. > >> > >> This is what I observe too. Confirmed by looking at the test > >> output in the jtr file. > >> > >>> This was why I was asking the question on whether this should work on > >>> AIX, or whether it should fail on Linux!!! > >> > >> I suspect that this is an issue with the native setsockopt > >> on AIX. That said, if it cannot be resolved on AIX, then > >> maybe the networking native code on AIX, should workaround > >> it. > >> > >> -Chris. > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue Jan 15 16:52:26 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 15 Jan 2019 16:52:26 +0000 Subject: [13] RFR: 8217094: HttpClient SSL race if a socket IOException is raised before ALPN is available Message-ID: <4d8a4b9d-94a4-7d76-739d-b96bcf7fd24a@oracle.com> Hi, Please find below a fix for: 8217094: HttpClient SSL race if a socket IOException is raised before ALPN is available https://bugs.openjdk.java.net/browse/JDK-8217094 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8217094/webrev.00/ While investigating another test I stumbled on a race condition in the SSLTube/SSLFlowDelegate: if an IOException is raised at the lower level (socket) before the ALPN is available the ALPN CF may never be completed, and as a result the connection may be stuck. The patch ensure that the ALPN CF will always get completed. best regards, -- daniel From ivan.gerasimov at oracle.com Tue Jan 15 19:53:26 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 15 Jan 2019 11:53:26 -0800 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly In-Reply-To: References: Message-ID: <7ec472ce-c15d-fa85-ec52-cd33866bc365@oracle.com> Hello! Do you think it is good to go now? With kind regards, Ivan On 1/11/19 11:30 AM, Ivan Gerasimov wrote: > Good catch, thank you! > > Indeed, if we don't reset localifsSize then we could end up accessing > already freed memory, which is worse than just a memory leak. > > Here's the updated webrev: > > http://cr.openjdk.java.net/~igerasim/8007606/01/webrev/ > > With kind regards, > Ivan > > On 1/11/19 4:43 AM, Baesken, Matthias wrote: >> Hi Ivan, >> >> Shouldn't you reset localifsSize to 0 in case of the early >> return ? The comment says localifsSize is the size of the array so >> the size of the array is 0 again after freeing. >> >> >> 637 static struct localinterface *localifs = 0; >> 638 static int localifsSize = 0; /* size of array */ >> 639 static int nifs = 0; /* number of entries used in >> array */ >> >> ... >> >> 679 if (localifsTemp == 0) { >> 680 free(localifs); >> 681 localifs = 0; >> 682 nifs = 0; >> 683 fclose(f); >> 684 return; >> 685 } >> >> >> >> >> Best regards, Matthias >> >> >> >>> Date: Thu, 10 Jan 2019 20:29:08 -0800 >>> From: Ivan Gerasimov >>> To: "net-dev at openjdk.java.net" >>> Subject: RFR 8007606 : Handle realloc() failure in >>> unix/native/libnet/net_util_md.c correctly >>> Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86 at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> Hello! >>> >>> This seems to be the last use of realloc() without proper handling of a >>> failure. >>> >>> Would you please help review a trivial fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ >>> >>> Thanks in advance! >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> >>> >> > -- With kind regards, Ivan Gerasimov From christoph.langer at sap.com Tue Jan 15 19:57:31 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Jan 2019 19:57:31 +0000 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly In-Reply-To: <7ec472ce-c15d-fa85-ec52-cd33866bc365@oracle.com> References: <7ec472ce-c15d-fa85-ec52-cd33866bc365@oracle.com> Message-ID: Hi Ivan, yes, sure, push it ?? Best regards Christoph > -----Original Message----- > From: Ivan Gerasimov > Sent: Dienstag, 15. Januar 2019 20:53 > To: Baesken, Matthias ; net- > dev at openjdk.java.net; Langer, Christoph > Subject: Re: RFR 8007606 : Handle realloc() failure in > unix/native/libnet/net_util_md.c correctly > > Hello! > > Do you think it is good to go now? > > With kind regards, > > Ivan > > > On 1/11/19 11:30 AM, Ivan Gerasimov wrote: > > Good catch, thank you! > > > > Indeed, if we don't reset localifsSize then we could end up accessing > > already freed memory, which is worse than just a memory leak. > > > > Here's the updated webrev: > > > > http://cr.openjdk.java.net/~igerasim/8007606/01/webrev/ > > > > With kind regards, > > Ivan > > > > On 1/11/19 4:43 AM, Baesken, Matthias wrote: > >> Hi Ivan, > >> > >> Shouldn't you reset localifsSize to 0 in case of the early > >> return ? The comment says localifsSize is the size of the array so > >> the size of the array is 0 again after freeing. > >> > >> > >> 637 static struct localinterface *localifs = 0; > >> 638 static int localifsSize = 0; /* size of array */ > >> 639 static int nifs = 0; /* number of entries used in > >> array */ > >> > >> ... > >> > >> 679 if (localifsTemp == 0) { > >> 680 free(localifs); > >> 681 localifs = 0; > >> 682 nifs = 0; > >> 683 fclose(f); > >> 684 return; > >> 685 } > >> > >> > >> > >> > >> Best regards, Matthias > >> > >> > >> > >>> Date: Thu, 10 Jan 2019 20:29:08 -0800 > >>> From: Ivan Gerasimov > >>> To: "net-dev at openjdk.java.net" > >>> Subject: RFR 8007606 : Handle realloc() failure in > >>> unix/native/libnet/net_util_md.c correctly > >>> Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86 at oracle.com> > >>> Content-Type: text/plain; charset=utf-8; format=flowed > >>> > >>> Hello! > >>> > >>> This seems to be the last use of realloc() without proper handling of a > >>> failure. > >>> > >>> Would you please help review a trivial fix? > >>> > >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 > >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ > >>> > >>> Thanks in advance! > >>> > >>> -- > >>> With kind regards, > >>> Ivan Gerasimov > >>> > >>> > >> > > > > -- > With kind regards, > Ivan Gerasimov From matthias.baesken at sap.com Wed Jan 16 10:22:43 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 16 Jan 2019 10:22:43 +0000 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly In-Reply-To: References: <7ec472ce-c15d-fa85-ec52-cd33866bc365@oracle.com> Message-ID: Hi Ivan ,looks good to me too (not a Reviewer however). Do you think we should address the other reallocs with unhandeled return code ? Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Dienstag, 15. Januar 2019 20:58 > To: Ivan Gerasimov ; Baesken, Matthias > ; net-dev at openjdk.java.net > Subject: RE: RFR 8007606 : Handle realloc() failure in > unix/native/libnet/net_util_md.c correctly > > Hi Ivan, > > yes, sure, push it ?? > > Best regards > Christoph > > > -----Original Message----- > > From: Ivan Gerasimov > > Sent: Dienstag, 15. Januar 2019 20:53 > > To: Baesken, Matthias ; net- > > dev at openjdk.java.net; Langer, Christoph > > Subject: Re: RFR 8007606 : Handle realloc() failure in > > unix/native/libnet/net_util_md.c correctly > > > > Hello! > > > > Do you think it is good to go now? > > > > With kind regards, > > > > Ivan > > > > > > On 1/11/19 11:30 AM, Ivan Gerasimov wrote: > > > Good catch, thank you! > > > > > > Indeed, if we don't reset localifsSize then we could end up accessing > > > already freed memory, which is worse than just a memory leak. > > > > > > Here's the updated webrev: > > > > > > http://cr.openjdk.java.net/~igerasim/8007606/01/webrev/ > > > > > > With kind regards, > > > Ivan > > > > > > On 1/11/19 4:43 AM, Baesken, Matthias wrote: > > >> Hi Ivan, > > >> > > >> Shouldn't you reset localifsSize to 0 in case of the early > > >> return ? The comment says localifsSize is the size of the array so > > >> the size of the array is 0 again after freeing. > > >> > > >> > > >> 637 static struct localinterface *localifs = 0; > > >> 638 static int localifsSize = 0; /* size of array */ > > >> 639 static int nifs = 0; /* number of entries used in > > >> array */ > > >> > > >> ... > > >> > > >> 679 if (localifsTemp == 0) { > > >> 680 free(localifs); > > >> 681 localifs = 0; > > >> 682 nifs = 0; > > >> 683 fclose(f); > > >> 684 return; > > >> 685 } > > >> > > >> > > >> > > >> > > >> Best regards, Matthias > > >> > > >> > > >> > > >>> Date: Thu, 10 Jan 2019 20:29:08 -0800 > > >>> From: Ivan Gerasimov > > >>> To: "net-dev at openjdk.java.net" > > >>> Subject: RFR 8007606 : Handle realloc() failure in > > >>> unix/native/libnet/net_util_md.c correctly > > >>> Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86 at oracle.com> > > >>> Content-Type: text/plain; charset=utf-8; format=flowed > > >>> > > >>> Hello! > > >>> > > >>> This seems to be the last use of realloc() without proper handling of a > > >>> failure. > > >>> > > >>> Would you please help review a trivial fix? > > >>> > > >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 > > >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ > > >>> > > >>> Thanks in advance! > > >>> > > >>> -- > > >>> With kind regards, > > >>> Ivan Gerasimov > > >>> > > >>> > > >> > > > > > > > -- > > With kind regards, > > Ivan Gerasimov > From chris.hegarty at oracle.com Wed Jan 16 11:33:48 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 16 Jan 2019 11:33:48 +0000 Subject: [13] RFR: 8217094: HttpClient SSL race if a socket IOException is raised before ALPN is available In-Reply-To: <4d8a4b9d-94a4-7d76-739d-b96bcf7fd24a@oracle.com> References: <4d8a4b9d-94a4-7d76-739d-b96bcf7fd24a@oracle.com> Message-ID: On 15/01/2019 16:52, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8217094: HttpClient SSL race if a socket IOException is raised > ???????? before ALPN is available > https://bugs.openjdk.java.net/browse/JDK-8217094 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8217094/webrev.00/ I think this is good Daniel. -Chris. From michael.x.mcmahon at oracle.com Wed Jan 16 16:46:48 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 16 Jan 2019 16:46:48 +0000 Subject: RFR: 8217237 HttpClient does not deal well with multi-valued WWW-Authenticate challenge headers Message-ID: <5C3F5FF8.9040308@oracle.com> Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/8217237/webrev.1/ Thanks, Michael From daniel.fuchs at oracle.com Wed Jan 16 17:51:51 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 16 Jan 2019 17:51:51 +0000 Subject: RFR: 8217237 HttpClient does not deal well with multi-valued WWW-Authenticate challenge headers In-Reply-To: <5C3F5FF8.9040308@oracle.com> References: <5C3F5FF8.9040308@oracle.com> Message-ID: <54a47df9-4abf-7f43-8c48-d8a9761866ea@oracle.com> Hi Michael, I believe the code changes looks good. WRT to the test: 150 if (response.statusCode() != 200 && !response.body().equals(server.response())) { I believe you meant || not && best regards, -- daniel On 16/01/2019 16:46, Michael McMahon wrote: > Could I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/8217237/webrev.1/ > > Thanks, > > Michael From ivan.gerasimov at oracle.com Thu Jan 17 02:16:34 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 16 Jan 2019 18:16:34 -0800 Subject: RFR 8007606 : Handle realloc() failure in unix/native/libnet/net_util_md.c correctly In-Reply-To: References: <7ec472ce-c15d-fa85-ec52-cd33866bc365@oracle.com> Message-ID: <40080686-85f5-4770-4934-8b2b20c1e784@oracle.com> Thank you Christoph and Mattias! I've filed https://bugs.openjdk.java.net/browse/JDK-8217291 and https://bugs.openjdk.java.net/browse/JDK-8217292 to handle the realloc() issues in other areas. With kind regards, Ivan On 1/16/19 2:22 AM, Baesken, Matthias wrote: > Hi Ivan ,looks good to me too (not a Reviewer however). > > Do you think we should address the other reallocs with unhandeled return code ? > > Best regards, Matthias > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Dienstag, 15. Januar 2019 20:58 >> To: Ivan Gerasimov ; Baesken, Matthias >> ; net-dev at openjdk.java.net >> Subject: RE: RFR 8007606 : Handle realloc() failure in >> unix/native/libnet/net_util_md.c correctly >> >> Hi Ivan, >> >> yes, sure, push it ?? >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: Ivan Gerasimov >>> Sent: Dienstag, 15. Januar 2019 20:53 >>> To: Baesken, Matthias ; net- >>> dev at openjdk.java.net; Langer, Christoph >>> Subject: Re: RFR 8007606 : Handle realloc() failure in >>> unix/native/libnet/net_util_md.c correctly >>> >>> Hello! >>> >>> Do you think it is good to go now? >>> >>> With kind regards, >>> >>> Ivan >>> >>> >>> On 1/11/19 11:30 AM, Ivan Gerasimov wrote: >>>> Good catch, thank you! >>>> >>>> Indeed, if we don't reset localifsSize then we could end up accessing >>>> already freed memory, which is worse than just a memory leak. >>>> >>>> Here's the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~igerasim/8007606/01/webrev/ >>>> >>>> With kind regards, >>>> Ivan >>>> >>>> On 1/11/19 4:43 AM, Baesken, Matthias wrote: >>>>> Hi Ivan, >>>>> >>>>> Shouldn't you reset localifsSize to 0 in case of the early >>>>> return ? The comment says localifsSize is the size of the array so >>>>> the size of the array is 0 again after freeing. >>>>> >>>>> >>>>> 637 static struct localinterface *localifs = 0; >>>>> 638 static int localifsSize = 0; /* size of array */ >>>>> 639 static int nifs = 0; /* number of entries used in >>>>> array */ >>>>> >>>>> ... >>>>> >>>>> 679 if (localifsTemp == 0) { >>>>> 680 free(localifs); >>>>> 681 localifs = 0; >>>>> 682 nifs = 0; >>>>> 683 fclose(f); >>>>> 684 return; >>>>> 685 } >>>>> >>>>> >>>>> >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>>> Date: Thu, 10 Jan 2019 20:29:08 -0800 >>>>>> From: Ivan Gerasimov >>>>>> To: "net-dev at openjdk.java.net" >>>>>> Subject: RFR 8007606 : Handle realloc() failure in >>>>>> unix/native/libnet/net_util_md.c correctly >>>>>> Message-ID: <3dc3c26b-fea7-2538-2c7a-bfa623f2fc86 at oracle.com> >>>>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>>>> >>>>>> Hello! >>>>>> >>>>>> This seems to be the last use of realloc() without proper handling of a >>>>>> failure. >>>>>> >>>>>> Would you please help review a trivial fix? >>>>>> >>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8007606 >>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8007606/00/webrev/ >>>>>> >>>>>> Thanks in advance! >>>>>> >>>>>> -- >>>>>> With kind regards, >>>>>> Ivan Gerasimov >>>>>> >>>>>> >>> -- >>> With kind regards, >>> Ivan Gerasimov -- With kind regards, Ivan Gerasimov From christoph.langer at sap.com Thu Jan 17 09:54:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Jan 2019 09:54:28 +0000 Subject: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix) Message-ID: <776f4e2e575d4fab85aed53ab40af1b1@sap.com> Hi, please help to review a tiny fix. While working on the issue with the AIX multicast tests (https://bugs.openjdk.java.net/browse/JDK-8207404), I found a place where a SocketException thrown in a specific error case could be improved. There already exists code to throw a SocketException with the text "IPV6_MULTICAST_IF failed (interface has IPv4 address only?) " when setsockopt(IPV6_MULTICAST_IF) fails with EINVAL. On AIX, when you have IPv4 addresses only on an interface, you'll run into when setting the option on an AF_INET6 socket. So that specific SocketException text would match very well then. I guess the addition is fine to be platform independent. At best on other platforms EADDRNOTAVAIL is never seen at that place. Or if it was, it would certainly have to do with an IP address problem on the interface... Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217311.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8217311 Thanks and best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From GROEGES at uk.ibm.com Thu Jan 17 10:18:30 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 17 Jan 2019 10:18:30 +0000 Subject: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix) In-Reply-To: <776f4e2e575d4fab85aed53ab40af1b1@sap.com> References: <776f4e2e575d4fab85aed53ab40af1b1@sap.com> Message-ID: Hi Chris, Looks OK to me. That is one of the changes I had made locally while investigating https://bugs.openjdk.java.net/browse/JDK-8207404, so happy to accept it. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Langer, Christoph" To: "net-dev at openjdk.java.net" Date: 17/01/2019 09:55 Subject: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix) Sent by: "net-dev" Hi, please help to review a tiny fix. While working on the issue with the AIX multicast tests ( https://bugs.openjdk.java.net/browse/JDK-8207404), I found a place where a SocketException thrown in a specific error case could be improved. There already exists code to throw a SocketException with the text "IPV6_MULTICAST_IF failed (interface has IPv4 address only?) " when setsockopt(IPV6_MULTICAST_IF) fails with EINVAL. On AIX, when you have IPv4 addresses only on an interface, you?ll run into when setting the option on an AF_INET6 socket. So that specific SocketException text would match very well then. I guess the addition is fine to be platform independent. At best on other platforms EADDRNOTAVAIL is never seen at that place. Or if it was, it would certainly have to do with an IP address problem on the interface... Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217311.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8217311 Thanks and best regards Christoph Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Jan 17 10:44:30 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Jan 2019 10:44:30 +0000 Subject: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix) In-Reply-To: References: <776f4e2e575d4fab85aed53ab40af1b1@sap.com> Message-ID: Looks okay to me too.? I think we should encourage new multicast applications to move to DatagramChannel as it a defines factory methods to specify the protocol family at creation time. Also setOption(IP_MULTICAST_IF, ...) and the join methods are also specified for such cases. Going forward I also need we need to replace PlainDatagramSocketImpl but that's a topic for another thread. -Alan On 17/01/2019 10:18, Steve Groeger wrote: > Hi Chris, > > Looks OK to me. > > That is one of the changes I had made locally while investigating > _https://bugs.openjdk.java.net/browse/JDK-8207404_, so happy to accept > it. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > From: "Langer, Christoph" > To: "net-dev at openjdk.java.net" > Date: 17/01/2019 09:55 > Subject: RFR(XS): 8217311: Improve Exception thrown when > MulticastSocket.setInterface fails on AIX(Unix) > Sent by: "net-dev" > ------------------------------------------------------------------------ > > > > Hi, > > please help to review a tiny fix. > > While working on the issue with the AIX multicast tests > (_https://bugs.openjdk.java.net/browse/JDK-8207404_), I found a place > where a SocketException thrown in a specific error case could be > improved. There already exists code to throw a SocketException with > the text "IPV6_MULTICAST_IF failed (interface has IPv4 address only?) > " when setsockopt(IPV6_MULTICAST_IF) fails with EINVAL. On AIX, when > you have IPv4 addresses only on an interface, you?ll run into when > setting the option on an AF_INET6 socket. So that specific > SocketException text would match very well then. I guess the addition > is fine to be platform independent. At best on other platforms > EADDRNOTAVAIL is never seen at that place. Or if it was, it would > certainly have to do with an IP address problem on the interface... > > Webrev: _http://cr.openjdk.java.net/~clanger/webrevs/8217311.0/_ > Bug: _https://bugs.openjdk.java.net/browse/JDK-8217311_ > > Thanks and best regards > Christoph > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jan 17 10:55:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Jan 2019 10:55:06 +0000 Subject: RFR: 8207404: MulticastSocket tests failing on AIX Message-ID: <672942772ce64693ac5cb584d249d8c7@sap.com> Hi, here is a fix for the MulticastSocket tests failing on AIX (in certain sceanrios): Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207404.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8207404 First of all, I "modernized" the testcases test/jdk/java/net/MulticastSocket/SetGetNetworkInterfaceTest.java and test/jdk/java/net/MulticastSocket/Test.java to make use of test/lib/jdk/test/lib/NetworkConfiguration.java which probes for the network configuration and returns lists of local interfaces or addresses for certain use cases. In NetworkConfiguration.java I made some cleanups and enhancements which will hopefully find some appreciation. These 3 tests will now also be executed with and without -Djava.net.preferIPv4Stack=true. The actual fixes are: test/jdk/java/net/MulticastSocket/JoinLeave.java: test/jdk/java/net/MulticastSocket/SetGetNetworkInterfaceTest.java: -> NetworkConfiguration.ip4MulticastInterfaces() will now, on AIX, in a scenario where IPv6 is available, filter out interfaces that only have IPv4 addresses (line 121ff in test/lib/jdk/test/lib/NetworkConfiguration.java) test/jdk/java/net/MulticastSocket/Test.java: -> The test for node local multicasting is only executed, when NetworkConfiguration::hasTestableIPv6Address is true. For AIX it'll be the case only if a "real" IPv6 address exists (on some interface) which is not loopback or wildcard. This is how it has already been for Solaris. For other operating systems, any IPv6 address on any interface is sufficient for running the test. The coding for the AIX/Solaris check can be found in line 66ff of test/lib/jdk/test/lib/NetworkConfiguration.java. As it is a test only fix, I request to do it in JDK12. Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jan 17 11:03:34 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Jan 2019 11:03:34 +0000 Subject: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix) In-Reply-To: References: <776f4e2e575d4fab85aed53ab40af1b1@sap.com> Message-ID: Thanks Alan and Steve for the reviews. From: net-dev On Behalf Of Alan Bateman Sent: Donnerstag, 17. Januar 2019 11:45 To: net-dev at openjdk.java.net Subject: Re: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix) Looks okay to me too. I think we should encourage new multicast applications to move to DatagramChannel as it a defines factory methods to specify the protocol family at creation time. Also setOption(IP_MULTICAST_IF, ...) and the join methods are also specified for such cases. Going forward I also need we need to replace PlainDatagramSocketImpl but that's a topic for another thread. -Alan On 17/01/2019 10:18, Steve Groeger wrote: Hi Chris, Looks OK to me. That is one of the changes I had made locally while investigating https://bugs.openjdk.java.net/browse/JDK-8207404, so happy to accept it. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Langer, Christoph" To: "net-dev at openjdk.java.net" Date: 17/01/2019 09:55 Subject: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix) Sent by: "net-dev" ________________________________ Hi, please help to review a tiny fix. While working on the issue with the AIX multicast tests (https://bugs.openjdk.java.net/browse/JDK-8207404), I found a place where a SocketException thrown in a specific error case could be improved. There already exists code to throw a SocketException with the text "IPV6_MULTICAST_IF failed (interface has IPv4 address only?) " when setsockopt(IPV6_MULTICAST_IF) fails with EINVAL. On AIX, when you have IPv4 addresses only on an interface, you?ll run into when setting the option on an AF_INET6 socket. So that specific SocketException text would match very well then. I guess the addition is fine to be platform independent. At best on other platforms EADDRNOTAVAIL is never seen at that place. Or if it was, it would certainly have to do with an IP address problem on the interface... Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217311.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8217311 Thanks and best regards Christoph Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Thu Jan 17 11:04:40 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 17 Jan 2019 11:04:40 +0000 Subject: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix) Message-ID: Hi Christoph, I do not even see EADDRNOTAVAIL listed in the list of error codes of setsockopt on AIX 7.1 (manpage). Strange that it shows up (maybe the manpage is incomplete ?). But otherwise it looks good to me (not a Reviewer). Maybe one could mention the error (or errno) in the exception for all cases of setsockopt failing ? Best regards, Matthias > Message: 4 > Date: Thu, 17 Jan 2019 09:54:28 +0000 > From: "Langer, Christoph" > To: "net-dev at openjdk.java.net" > Subject: RFR(XS): 8217311: Improve Exception thrown when > MulticastSocket.setInterface fails on AIX(Unix) > Message-ID: <776f4e2e575d4fab85aed53ab40af1b1 at sap.com> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > please help to review a tiny fix. > > While working on the issue with the AIX multicast tests > (https://bugs.openjdk.java.net/browse/JDK-8207404), I found a place where > a SocketException thrown in a specific error case could be improved. There > already exists code to throw a SocketException with the text > "IPV6_MULTICAST_IF failed (interface has IPv4 address only?) " when > setsockopt(IPV6_MULTICAST_IF) fails with EINVAL. On AIX, when you have > IPv4 addresses only on an interface, you'll run into when setting the option > on an AF_INET6 socket. So that specific SocketException text would match > very well then. I guess the addition is fine to be platform independent. At > best on other platforms EADDRNOTAVAIL is never seen at that place. Or if it > was, it would certainly have to do with an IP address problem on the > interface... > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217311.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8217311 > > Thanks and best regards > Christoph > From chris.hegarty at oracle.com Thu Jan 17 11:23:28 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 17 Jan 2019 11:23:28 +0000 Subject: RFR(XS): 8217311: Improve Exception thrown when MulticastSocket.setInterface fails on AIX(Unix) In-Reply-To: <776f4e2e575d4fab85aed53ab40af1b1@sap.com> References: <776f4e2e575d4fab85aed53ab40af1b1@sap.com> Message-ID: <84A258EA-FF73-4FA3-A8BD-430CBE7FF3E9@oracle.com> > On 17 Jan 2019, at 09:54, Langer, Christoph wrote: > > Hi, > > please help to review a tiny fix. > > While working on the issue with the AIX multicast tests (https://bugs.openjdk.java.net/browse/JDK-8207404 ), I found a place where a SocketException thrown in a specific error case could be improved. There already exists code to throw a SocketException with the text "IPV6_MULTICAST_IF failed (interface has IPv4 address only?) " when setsockopt(IPV6_MULTICAST_IF) fails with EINVAL. On AIX, when you have IPv4 addresses only on an interface, you?ll run into when setting the option on an AF_INET6 socket. So that specific SocketException text would match very well then. I guess the addition is fine to be platform independent. At best on other platforms EADDRNOTAVAIL is never seen at that place. Or if it was, it would certainly have to do with an IP address problem on the interface... > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217311.0/ Looks ok. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Jan 17 11:27:15 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 17 Jan 2019 11:27:15 +0000 Subject: RFR: 8207404: MulticastSocket tests failing on AIX In-Reply-To: <672942772ce64693ac5cb584d249d8c7@sap.com> References: <672942772ce64693ac5cb584d249d8c7@sap.com> Message-ID: > On 17 Jan 2019, at 10:55, Langer, Christoph wrote: > > Hi, > > here is a fix for the MulticastSocket tests failing on AIX (in certain sceanrios): > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207404.0/ Why remove the static imports from NetworkConfiguration? It makes the code more verbose ( and IMO harder to read ). -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jan 17 11:33:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Jan 2019 11:33:15 +0000 Subject: RFR: 8207404: MulticastSocket tests failing on AIX In-Reply-To: References: <672942772ce64693ac5cb584d249d8c7@sap.com> Message-ID: <9437af146b67440fbc6c1453b9b80711@sap.com> Hi Chris, for me it was the other way round... I did not see immediately where the methods came from and had to do some navigation. But I'm happy to revert this. As I had only worked with AIX so far, I'll put the test update into our test system to see whether there'll be issues on other platforms. I'll send an updated webrev tomorrow. Best regards Christoph From: Chris Hegarty Sent: Donnerstag, 17. Januar 2019 12:27 To: Langer, Christoph Cc: net-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR: 8207404: MulticastSocket tests failing on AIX On 17 Jan 2019, at 10:55, Langer, Christoph > wrote: Hi, here is a fix for the MulticastSocket tests failing on AIX (in certain sceanrios): Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207404.0/ Why remove the static imports from NetworkConfiguration? It makes the code more verbose ( and IMO harder to read ). -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Thu Jan 17 12:23:21 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 17 Jan 2019 12:23:21 +0000 Subject: RFR: 8217237 HttpClient does not deal well with multi-valued WWW-Authenticate challenge headers In-Reply-To: <54a47df9-4abf-7f43-8c48-d8a9761866ea@oracle.com> References: <5C3F5FF8.9040308@oracle.com> <54a47df9-4abf-7f43-8c48-d8a9761866ea@oracle.com> Message-ID: <5C4073B9.9010304@oracle.com> Thanks Daniel. Good catch. - Michael. On 16/01/2019, 17:51, Daniel Fuchs wrote: > Hi Michael, > > I believe the code changes looks good. > > WRT to the test: > > 150 if (response.statusCode() != 200 && > !response.body().equals(server.response())) { > > I believe you meant || not && > > best regards, > > -- daniel > > On 16/01/2019 16:46, Michael McMahon wrote: >> Could I get the following change reviewed please? >> >> http://cr.openjdk.java.net/~michaelm/8217237/webrev.1/ >> >> Thanks, >> >> Michael > From GROEGES at uk.ibm.com Thu Jan 17 13:32:24 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 17 Jan 2019 13:32:24 +0000 Subject: RFR: 8207404: MulticastSocket tests failing on AIX In-Reply-To: <9437af146b67440fbc6c1453b9b80711@sap.com> References: <672942772ce64693ac5cb584d249d8c7@sap.com> <9437af146b67440fbc6c1453b9b80711@sap.com> Message-ID: Hi Christoph, Have reviewed you changes and they look OK. I have no preference with regards the static imports, but my view is keep the changes as simple as possible and to not make changes just for the sake of it. Have tested your patches on a couple of AIX systems, both with IPv6 enabled but one didn't have an IPv6 address configured and the other did. All the jdk/java/net/MulticastSocket tests passed. So the change also looks functionally OK. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Langer, Christoph" To: Chris Hegarty Cc: "ppc-aix-port-dev at openjdk.java.net" , "net-dev at openjdk.java.net" Date: 17/01/2019 11:34 Subject: RE: RFR: 8207404: MulticastSocket tests failing on AIX Sent by: "net-dev" Hi Chris, for me it was the other way round? I did not see immediately where the methods came from and had to do some navigation. But I?m happy to revert this. As I had only worked with AIX so far, I?ll put the test update into our test system to see whether there?ll be issues on other platforms. I?ll send an updated webrev tomorrow. Best regards Christoph From: Chris Hegarty Sent: Donnerstag, 17. Januar 2019 12:27 To: Langer, Christoph Cc: net-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR: 8207404: MulticastSocket tests failing on AIX On 17 Jan 2019, at 10:55, Langer, Christoph wrote: Hi, here is a fix for the MulticastSocket tests failing on AIX (in certain sceanrios): Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207404.0/ Why remove the static imports from NetworkConfiguration? It makes the code more verbose ( and IMO harder to read ). -Chris. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jan 17 14:28:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Jan 2019 14:28:10 +0000 Subject: RFR: 8207404: MulticastSocket tests failing on AIX In-Reply-To: References: <672942772ce64693ac5cb584d249d8c7@sap.com> <9437af146b67440fbc6c1453b9b80711@sap.com> Message-ID: <4ee0ceba10c542a48e94002ea1ae2abe@sap.com> Hi Steve, thanks for the review and the additional testing. I?ll post an update tomorrow after I have results from our test system which will test all platforms that we have an eye on. I?ll roll back the change to the import statement and will also add an update to the problem list in order to make the tests run by default on AIX. You could do me a favor though. There?s not only the issue with the IPV6_MULTICAST_IF setsockopt operation but there?s also the other where node local IPv6 multicast does not work when only the loopback interface is configured for IPv6 (as show in Test.java). Could you check this also with the AIX team whether they consider this a bug or working as expected? Thanks & Best regards Christoph From: Steve Groeger Sent: Donnerstag, 17. Januar 2019 14:32 To: Langer, Christoph Cc: Chris Hegarty ; net-dev at openjdk.java.net; net-dev ; ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR: 8207404: MulticastSocket tests failing on AIX Hi Christoph, Have reviewed you changes and they look OK. I have no preference with regards the static imports, but my view is keep the changes as simple as possible and to not make changes just for the sake of it. Have tested your patches on a couple of AIX systems, both with IPv6 enabled but one didn't have an IPv6 address configured and the other did. All the jdk/java/net/MulticastSocket tests passed. So the change also looks functionally OK. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Langer, Christoph" > To: Chris Hegarty > Cc: "ppc-aix-port-dev at openjdk.java.net" >, "net-dev at openjdk.java.net" > Date: 17/01/2019 11:34 Subject: RE: RFR: 8207404: MulticastSocket tests failing on AIX Sent by: "net-dev" > ________________________________ Hi Chris, for me it was the other way round? I did not see immediately where the methods came from and had to do some navigation. But I?m happy to revert this. As I had only worked with AIX so far, I?ll put the test update into our test system to see whether there?ll be issues on other platforms. I?ll send an updated webrev tomorrow. Best regards Christoph From: Chris Hegarty > Sent: Donnerstag, 17. Januar 2019 12:27 To: Langer, Christoph > Cc: net-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR: 8207404: MulticastSocket tests failing on AIX On 17 Jan 2019, at 10:55, Langer, Christoph > wrote: Hi, here is a fix for the MulticastSocket tests failing on AIX (in certain sceanrios): Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207404.0/ Why remove the static imports from NetworkConfiguration? It makes the code more verbose ( and IMO harder to read ). -Chris. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Jan 18 08:54:33 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 18 Jan 2019 08:54:33 +0000 Subject: RFR: 8207404: MulticastSocket tests failing on AIX In-Reply-To: References: <672942772ce64693ac5cb584d249d8c7@sap.com> Message-ID: Hi, here is the updated webrev with modifications to the problem list and reverting the static imports: http://cr.openjdk.java.net/~clanger/webrevs/8207404.1/ It went fine through our test system so I think it's good now. Please review. Thanks Christoph From: Chris Hegarty Sent: Donnerstag, 17. Januar 2019 12:27 To: Langer, Christoph Cc: net-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR: 8207404: MulticastSocket tests failing on AIX On 17 Jan 2019, at 10:55, Langer, Christoph > wrote: Hi, here is a fix for the MulticastSocket tests failing on AIX (in certain sceanrios): Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207404.0/ Why remove the static imports from NetworkConfiguration? It makes the code more verbose ( and IMO harder to read ). -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Jan 18 11:27:32 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 18 Jan 2019 11:27:32 +0000 Subject: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted Message-ID: <8c05134e-e683-637d-9f42-5cf84c6bd7ca@oracle.com> Hi, Please find below a small fix for: 8216561: HttpClient: The logic of retry on connect exception is inverted https://bugs.openjdk.java.net/browse/JDK-8216561 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216561/webrev.01/ The patch now allows retry on connect exception, ensuring that the second attempt takes into account the time spent in the first attempt in order to honor the connect timeout value (if present). best regards, -- daniel From andrej.golovnin at gmail.com Fri Jan 18 12:42:28 2019 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 18 Jan 2019 13:42:28 +0100 Subject: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted In-Reply-To: <8c05134e-e683-637d-9f42-5cf84c6bd7ca@oracle.com> References: <8c05134e-e683-637d-9f42-5cf84c6bd7ca@oracle.com> Message-ID: Hi Daniel, > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216561/webrev.01/ > > > 126 private static class ConnectTimeoutTracker { 127 final Optional max; 128 final AtomicLong startTime = new AtomicLong(); 129 ConnectTimeoutTracker(Optional connectTimeout) { 130 this.max = connectTimeout; 131 } 132 133 Optional getRemaining() { 134 if (max.isEmpty()) return max; 135 long now = System.nanoTime(); 136 long previous = startTime.compareAndExchange(0, now); 137 if (previous == 0 || max.get().isZero()) return max; 138 Duration remaining = max.get().minus(Duration.ofNanos(now - previous)); 139 assert remaining.compareTo(max.get()) <= 0; 140 return Optional.of(remaining.isNegative() ? Duration.ZERO : remaining); 141 } 142 143 void reset() { startTime.set(0); } 144 } An Optional in a class field or in a data structure, is considered a misuse of the API (see the explanation by Stuart Marks: https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794). I would write it this way: private static class ConnectTimeoutTracker { final Duration max; final AtomicLong startTime = new AtomicLong(); ConnectTimeoutTracker(Duration connectTimeout) { this.max = connectTimeout; } Optional getRemaining() { return Optional.ofNullable(max) .map(m -> { long now = System.nanoTime(); long previous = startTime.compareAndExchange(0, now); if (previous == 0 || m.isZero()) { return m; } Duration remaining = m.minus(Duration.ofNanos(now - previous)); assert remaining.compareTo(m) <= 0; return remaining.isNegative() ? Duration.ZERO : remaining; }); } void reset() { startTime.set(0); } } Best regards, Andrej Golovnin -------------- next part -------------- An HTML attachment was scrubbed... URL: From GROEGES at uk.ibm.com Fri Jan 18 12:58:09 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 18 Jan 2019 12:58:09 +0000 Subject: RFR: 8207404: MulticastSocket tests failing on AIX In-Reply-To: References: <672942772ce64693ac5cb584d249d8c7@sap.com> Message-ID: Hi Christoph, Had a look at the latest webrev and everything looks OK to me. Have also re-tested on my AIX systems and all tests oass OK. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Langer, Christoph" To: Chris Hegarty , Steve Groeger Cc: "net-dev at openjdk.java.net" , "ppc-aix-port-dev at openjdk.java.net" Date: 18/01/2019 08:54 Subject: RE: RFR: 8207404: MulticastSocket tests failing on AIX Hi, here is the updated webrev with modifications to the problem list and reverting the static imports: http://cr.openjdk.java.net/~clanger/webrevs/8207404.1/ It went fine through our test system so I think it?s good now. Please review. Thanks Christoph From: Chris Hegarty Sent: Donnerstag, 17. Januar 2019 12:27 To: Langer, Christoph Cc: net-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR: 8207404: MulticastSocket tests failing on AIX On 17 Jan 2019, at 10:55, Langer, Christoph wrote: Hi, here is a fix for the MulticastSocket tests failing on AIX (in certain sceanrios): Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8207404.0/ Why remove the static imports from NetworkConfiguration? It makes the code more verbose ( and IMO harder to read ). -Chris. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Jan 18 13:29:37 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 18 Jan 2019 13:29:37 +0000 Subject: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted In-Reply-To: References: <8c05134e-e683-637d-9f42-5cf84c6bd7ca@oracle.com> Message-ID: <09ef0447-0f48-6996-6cde-1ecc5d34deb3@oracle.com> Hi Andrej, Yes that looks like my first implementation. But then I reflected that avoiding to map Optional to Duration and then back to a new Optional containing the same duration could be avoided by simply storing the original optional obtained from the HttpClient. The current code only creates a new instance of Optional when it needs to. best regards, -- daniel On 18/01/2019 12:42, Andrej Golovnin wrote: > Hi Daniel, > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216561/webrev.01/ > > > > ?126 ? ? private static class ConnectTimeoutTracker { > ?127 ? ? ? ? final Optional max; > ?128 ? ? ? ? final AtomicLong startTime = new AtomicLong(); > ?129 ? ? ? ? ConnectTimeoutTracker(Optional connectTimeout) { > ?130 ? ? ? ? ? ? this.max = connectTimeout; > ?131 ? ? ? ? } > ?132 > ?133 ? ? ? ? Optional getRemaining() { > ?134 ? ? ? ? ? ? if (max.isEmpty()) return max; > ?135 ? ? ? ? ? ? long now = System.nanoTime(); > ?136 ? ? ? ? ? ? long previous = startTime.compareAndExchange(0, now); > ?137 ? ? ? ? ? ? if (previous == 0 || max.get().isZero()) return max; > ?138 ? ? ? ? ? ? Duration remaining = > max.get().minus(Duration.ofNanos(now - previous)); > ?139 ? ? ? ? ? ? assert remaining.compareTo(max.get()) <= 0; > ?140 ? ? ? ? ? ? return Optional.of(remaining.isNegative() ? > Duration.ZERO : remaining); > ?141 ? ? ? ? } > ?142 > ?143 ? ? ? ? void reset() { startTime.set(0); } > ?144 ? ? } > An Optional in a class field or in a data structure, is considered a > misuse of the API (see the explanation by Stuart Marks: > https://stackoverflow.com/questions/23454952/uses-for-optional/23464794#23464794). > I would write it this way: > > ? ? ? private static class ConnectTimeoutTracker { > ? ? ? ? ? final Duration max; > ? ? ? ? ? final AtomicLong startTime = new AtomicLong(); > ? ? ? ? ? ConnectTimeoutTracker(Duration connectTimeout) { > ? ? ? ? ? ? ? this.max = connectTimeout; > ? ? ? ? ? } > ? ? ? ? ? Optional getRemaining() { > ? ? ? ? ? ? ? return Optional.ofNullable(max) > ? ? ? ? ? ? ? ? ? .map(m -> { > ? ? ? ? ? ? ? ? ? ? ? long now = System.nanoTime(); > ? ? ? ? ? ? ? ? ? ? ? long previous = startTime.compareAndExchange(0, now); > ? ? ? ? ? ? ? ? ? ? ? if (previous == 0 || m.isZero()) { > ? ? ? ? ? ? ? ? ? ? ? ? ? return m; > ? ? ? ? ? ? ? ? ? ? ? } > ? ? ? ? ? ? ? ? ? ? ? Duration remaining = m.minus(Duration.ofNanos(now > - previous)); > ? ? ? ? ? ? ? ? ? ? ? assert remaining.compareTo(m) <= 0; > ? ? ? ? ? ? ? ? ? ? ? return remaining.isNegative() ? Duration.ZERO : > remaining; > ? ? ? ? ? ? ? ? ? }); > ? ? ? ? ? } > ? ? ? ? ? void reset() { startTime.set(0); } > ? ? ? } > > Best regards, > Andrej Golovnin From andrej.golovnin at gmail.com Fri Jan 18 14:03:55 2019 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 18 Jan 2019 15:03:55 +0100 Subject: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted In-Reply-To: <09ef0447-0f48-6996-6cde-1ecc5d34deb3@oracle.com> References: <8c05134e-e683-637d-9f42-5cf84c6bd7ca@oracle.com> <09ef0447-0f48-6996-6cde-1ecc5d34deb3@oracle.com> Message-ID: Hi Daniel, Yes that looks like my first implementation. But then > I reflected that avoiding to map Optional to Duration > and then back to a new Optional containing the same > duration could be avoided by simply storing the original > optional obtained from the HttpClient. > > The current code only creates a new instance of Optional > when it needs to. > Is creating new Optionals a real problem? And before you answer please remember what Donald Knuth said: The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming. ;-) Best regards and have a nice weekend, Andrej Golovnin -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Fri Jan 18 14:14:47 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 Jan 2019 14:14:47 +0000 Subject: RFR: 8207404: MulticastSocket tests failing on AIX In-Reply-To: References: <672942772ce64693ac5cb584d249d8c7@sap.com> Message-ID: On 18/01/2019 08:54, Langer, Christoph wrote: > Hi, > > here is the updated webrev with modifications to the problem list and > reverting the static imports: > _http://cr.openjdk.java.net/~clanger/webrevs/8207404.1/__ I think this is ok. -Chris. From daniel.fuchs at oracle.com Fri Jan 18 14:24:05 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 18 Jan 2019 14:24:05 +0000 Subject: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted In-Reply-To: References: <8c05134e-e683-637d-9f42-5cf84c6bd7ca@oracle.com> <09ef0447-0f48-6996-6cde-1ecc5d34deb3@oracle.com> Message-ID: Hi Andrej, On 18/01/2019 14:03, Andrej Golovnin wrote: > Is creating new Optionals a real problem??And before you answer please > remember what Donald Knuth said:?The real problem is that programmers > have spent far too much time worrying about efficiency in the wrong > places and at the wrong times; premature optimization is the root of all > evil (or at least most of it) in programming. ;-) Right - here is a better implementation anyway: http://cr.openjdk.java.net/~dfuchs/webrev_8216561/webrev.02/ best regards, -- daniel > > Best regards and have a nice weekend, > Andrej Golovnin From chris.hegarty at oracle.com Fri Jan 18 14:45:28 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 Jan 2019 14:45:28 +0000 Subject: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted In-Reply-To: References: <8c05134e-e683-637d-9f42-5cf84c6bd7ca@oracle.com> <09ef0447-0f48-6996-6cde-1ecc5d34deb3@oracle.com> Message-ID: On 18/01/2019 14:24, Daniel Fuchs wrote: > Hi Andrej, > > On 18/01/2019 14:03, Andrej Golovnin wrote: >> Is creating new Optionals a real problem??And before you answer please >> remember what Donald Knuth said:?The real problem is that programmers >> have spent far too much time worrying about efficiency in the wrong >> places and at the wrong times; premature optimization is the root of >> all evil (or at least most of it) in programming. ;-) > > Right - here is a better implementation anyway: > http://cr.openjdk.java.net/~dfuchs/webrev_8216561/webrev.02/ This looks good Daniel. -Chris. From andrej.golovnin at gmail.com Fri Jan 18 19:02:59 2019 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 18 Jan 2019 20:02:59 +0100 Subject: [13] RFR: 8216561: HttpClient: The logic of retry on connect exception is inverted In-Reply-To: References: <8c05134e-e683-637d-9f42-5cf84c6bd7ca@oracle.com> <09ef0447-0f48-6996-6cde-1ecc5d34deb3@oracle.com> Message-ID: <9C8DFC8D-2CD4-4F5D-B38C-BED93CBB4E57@gmail.com> Hi Daniel, > Right - here is a better implementation anyway: > http://cr.openjdk.java.net/~dfuchs/webrev_8216561/webrev.02/ > Looks much better. Thanks a lot! Best regards, Andrej Golovnin From trtrmitya at gmail.com Fri Jan 18 20:57:49 2019 From: trtrmitya at gmail.com (Dmitry Sivachenko) Date: Fri, 18 Jan 2019 23:57:49 +0300 Subject: java.net.http.HttpClient: invalid exception when bad status line is returned Message-ID: <69F67A3D-F133-44D1-A734-BD15CF74A94F@gmail.com> Hello, I am tasting java.net.http.HttpClient with openjdk version "11.0.1" 2018-10-16 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.1+13) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.1+13, mixed mode) on Mac OS X 10.14.2. Consider the case when server responds with bad (invalid format) status line: "HTTP/1.1 FOO" The following IllegalArgumentException is thrown: Exception in thread "main" java.lang.IllegalArgumentException: For input string: "FOO" at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:551) at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119) at ru.mitya.test.App.main(App.java:14) Caused by: java.lang.NumberFormatException: For input string: "FOO" at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.base/java.lang.Integer.parseInt(Integer.java:652) at java.base/java.lang.Integer.parseInt(Integer.java:770) at java.net.http/jdk.internal.net.http.Http1HeaderParser.readStatusLineFeed(Http1HeaderParser.java:197) at java.net.http/jdk.internal.net.http.Http1HeaderParser.parse(Http1HeaderParser.java:124) at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:672) at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:603) at java.net.http/jdk.internal.net.http.Http1Response$Receiver.accept(Http1Response.java:594) at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.tryAsyncReceive(Http1Response.java:650) at java.net.http/jdk.internal.net.http.Http1AsyncReceiver.flush(Http1AsyncReceiver.java:228) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(SequentialScheduler.java:175) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:147) at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) instead of the expected ProtocolException: Exception in thread "main" java.io.IOException: Invalid status line: "HTTP/1.1 FOO" at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565) at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119) at ru.mitya.test.App.main(App.java:14) Caused by: java.net.ProtocolException: Invalid status line: "HTTP/1.1 FOO" <...> The suggested fix would be to catch IllegalArgumentException thrown by Integer.parseInt() in readStatusLineFeed() and throw ProtocolException instead of it. What do you think? Thanks. Here is a sample test program: package ru.mitya.test; import java.net.URI; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpResponse; public class App { public static void main(String[] args) throws Exception { HttpClient client = HttpClient.newBuilder().build(); HttpRequest req = HttpRequest.newBuilder(URI.create("http://localhost:8000/")) .version(HttpClient.Version.HTTP_1_1) .build(); HttpResponse resp = client.send(req, HttpResponse.BodyHandlers.ofString()); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Jan 21 07:04:03 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 21 Jan 2019 07:04:03 +0000 Subject: RFR: 8207404: MulticastSocket tests failing on AIX In-Reply-To: References: <672942772ce64693ac5cb584d249d8c7@sap.com> Message-ID: Thanks, Steve and Chris for reviewing. Pushed to jdk12. > -----Original Message----- > From: Chris Hegarty > Sent: Freitag, 18. Januar 2019 15:15 > To: Langer, Christoph ; Steve Groeger > > Cc: net-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR: 8207404: MulticastSocket tests failing on AIX > > > On 18/01/2019 08:54, Langer, Christoph wrote: > > Hi, > > > > here is the updated webrev with modifications to the problem list and > > reverting the static imports: > > _http://cr.openjdk.java.net/~clanger/webrevs/8207404.1/__ > I think this is ok. > > -Chris. From Alan.Bateman at oracle.com Mon Jan 21 17:41:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jan 2019 17:41:56 +0000 Subject: 8217451: ExtendedSocketOptions should encapsulate support for SO_FLOW_SLA Message-ID: <5cd316d2-5467-e3c6-fb33-d086d9686fe5@oracle.com> ExtendSocketOptions is the supporting class that the socket implementations use for JDK-specific socket options. Vyom improved it last year to select options based on the socket type but more is needed to handle socket options that are specific to connecting or listening sockets. As things stand, the Solaris specific SO_FLOW_SLA option is the only one with this complication and it is currently special cased by PlainSocketImpl. I want to push this special casing to ExtendSocketOptions so that the special handing is in one place. The proposed changes are here: ? http://cr.openjdk.java.net/~alanb/8217451/webrev/index.html -Alan From michael.x.mcmahon at oracle.com Mon Jan 21 18:00:22 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 21 Jan 2019 18:00:22 +0000 Subject: 8217451: ExtendedSocketOptions should encapsulate support for SO_FLOW_SLA In-Reply-To: <5cd316d2-5467-e3c6-fb33-d086d9686fe5@oracle.com> References: <5cd316d2-5467-e3c6-fb33-d086d9686fe5@oracle.com> Message-ID: <5C4608B6.7080909@oracle.com> Hi Alan, Looks fine apart from extra space on line 85: ExtendedSocketOptions.java - Michael. On 21/01/2019, 17:41, Alan Bateman wrote: > ExtendSocketOptions is the supporting class that the socket > implementations use for JDK-specific socket options. Vyom improved it > last year to select options based on the socket type but more is > needed to handle socket options that are specific to connecting or > listening sockets. As things stand, the Solaris specific SO_FLOW_SLA > option is the only one with this complication and it is currently > special cased by PlainSocketImpl. I want to push this special casing > to ExtendSocketOptions so that the special handing is in one place. > > The proposed changes are here: > http://cr.openjdk.java.net/~alanb/8217451/webrev/index.html > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Jan 21 18:14:00 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 Jan 2019 18:14:00 +0000 Subject: 8217451: ExtendedSocketOptions should encapsulate support for SO_FLOW_SLA In-Reply-To: <5cd316d2-5467-e3c6-fb33-d086d9686fe5@oracle.com> References: <5cd316d2-5467-e3c6-fb33-d086d9686fe5@oracle.com> Message-ID: <7868a267-75f6-b01c-02a4-fa5b6813417b@oracle.com> On 21/01/2019 17:41, Alan Bateman wrote: > ExtendSocketOptions is the supporting class that the socket > implementations use for JDK-specific socket options. Vyom improved it > last year to select options based on the socket type but more is needed > to handle socket options that are specific to connecting or listening > sockets. As things stand, the Solaris specific SO_FLOW_SLA option is the > only one with this complication and it is currently special cased by > PlainSocketImpl. I want to push this special casing to > ExtendSocketOptions so that the special handing is in one place. > > The proposed changes are here: > ? http://cr.openjdk.java.net/~alanb/8217451/webrev/index.html Looks ok. -Chris. From Alan.Bateman at oracle.com Mon Jan 21 19:10:04 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jan 2019 19:10:04 +0000 Subject: 8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer Message-ID: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> This is a small change to add a method to sun.nio.ch.Net to get the number of bytes in the socket input buffer. The motive for adding this to make it possible for the socket adaptors to implement InputStream::available and also to support an alternative SocketImpl based on NIO. I've used the opportunity to clean up NET_SocketAvailable in libnet so that it returns 0 when it succeeds. The proposed changes are here: ? http://cr.openjdk.java.net/~alanb/8217461/webrev/index.html -Alan From Alan.Bateman at oracle.com Mon Jan 21 19:10:58 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jan 2019 19:10:58 +0000 Subject: 8217451: ExtendedSocketOptions should encapsulate support for SO_FLOW_SLA In-Reply-To: <5C4608B6.7080909@oracle.com> References: <5cd316d2-5467-e3c6-fb33-d086d9686fe5@oracle.com> <5C4608B6.7080909@oracle.com> Message-ID: <811bb12e-da53-becb-79e8-1f840ff90ba8@oracle.com> On 21/01/2019 18:00, Michael McMahon wrote: > Hi Alan, > > Looks fine apart from extra space on line 85: ExtendedSocketOptions.java Thanks, I'll fix that before pushing. -Alan From christoph.langer at sap.com Tue Jan 22 08:07:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 22 Jan 2019 08:07:02 +0000 Subject: 8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer In-Reply-To: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> References: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> Message-ID: <741f5750110f4e51a7bf3bdc645d8878@sap.com> Hi Alan, the change looks good to me. In src/java.base/unix/native/libnio/ch/Net.c and src/java.base/windows/native/libnio/ch/Net.c you could change the code from ... int n = NET_SocketAvailable(fdval(env, fdo), &count); if (n != 0) { ... to one line if (NET_SocketAvailable(fdval(env, fdo), &count) != 0) { as it is done in src/java.base/unix/native/libnet/PlainSocketImpl.c The variable n is not used except for the returncode check. By the way, looking at the 2 implementations of Net.c for unix resp. windows, it seems they have quite some code in common. Isn't that something where the shared parts could be merged into one file? Best regards Christoph > -----Original Message----- > From: nio-dev On Behalf Of Alan > Bateman > Sent: Montag, 21. Januar 2019 20:10 > To: nio-dev at openjdk.java.net; OpenJDK Network Dev list dev at openjdk.java.net> > Subject: 8217461: (ch) Add Net.available to return the number of bytes in the > socket input buffer > > This is a small change to add a method to sun.nio.ch.Net to get the > number of bytes in the socket input buffer. The motive for adding this > to make it possible for the socket adaptors to implement > InputStream::available and also to support an alternative SocketImpl > based on NIO. I've used the opportunity to clean up NET_SocketAvailable > in libnet so that it returns 0 when it succeeds. > > The proposed changes are here: > ? http://cr.openjdk.java.net/~alanb/8217461/webrev/index.html > > -Alan From michael.x.mcmahon at oracle.com Tue Jan 22 08:19:20 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 22 Jan 2019 08:19:20 +0000 Subject: 8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer In-Reply-To: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> References: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> Message-ID: <5C46D208.3030807@oracle.com> Looks fine to me Alan. - Michael. On 21/01/2019, 19:10, Alan Bateman wrote: > This is a small change to add a method to sun.nio.ch.Net to get the > number of bytes in the socket input buffer. The motive for adding this > to make it possible for the socket adaptors to implement > InputStream::available and also to support an alternative SocketImpl > based on NIO. I've used the opportunity to clean up > NET_SocketAvailable in libnet so that it returns 0 when it succeeds. > > The proposed changes are here: > http://cr.openjdk.java.net/~alanb/8217461/webrev/index.html > > -Alan From Alan.Bateman at oracle.com Tue Jan 22 08:40:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jan 2019 08:40:03 +0000 Subject: 8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer In-Reply-To: <741f5750110f4e51a7bf3bdc645d8878@sap.com> References: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> <741f5750110f4e51a7bf3bdc645d8878@sap.com> Message-ID: On 22/01/2019 08:07, Langer, Christoph wrote: > Hi Alan, > > the change looks good to me. > > In src/java.base/unix/native/libnio/ch/Net.c and src/java.base/windows/native/libnio/ch/Net.c you could change the code from > > ... > int n = NET_SocketAvailable(fdval(env, fdo), &count); > if (n != 0) { > ... > > to one line > if (NET_SocketAvailable(fdval(env, fdo), &count) != 0) { > > as it is done in src/java.base/unix/native/libnet/PlainSocketImpl.c > > The variable n is not used except for the returncode check. Sometimes it is useful to have a variable when debugging but point taken that it is inconsistent between the two implementations. > > By the way, looking at the 2 implementations of Net.c for unix resp. windows, it seems they have quite some code in common. Isn't that something where the shared parts could be merged into one file? > Most of the native methods in the Windows implementation are very different so I would prefer not do this. Also I hope to eventually remove NET_SocketAvailable from libnet as part of work to replace the legacy SocketImpl implementations so it means sun.nio.ch.Net.available will have different implementations. -Alan From fweimer at redhat.com Wed Jan 23 09:42:55 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 23 Jan 2019 10:42:55 +0100 Subject: 8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer In-Reply-To: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> (Alan Bateman's message of "Mon, 21 Jan 2019 19:10:04 +0000") References: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> Message-ID: <87lg3bbtgg.fsf@oldenburg2.str.redhat.com> * Alan Bateman: > This is a small change to add a method to sun.nio.ch.Net to get the > number of bytes in the socket input buffer. The motive for adding this > to make it possible for the socket adaptors to implement > InputStream::available and also to support an alternative SocketImpl > based on NIO. Do you plan to read from the socket buffer in the implementation of available()? The problem is that even if there is currently data in the socket buffer, further data that arrives later can clear it. I think this can only happen as part of a connection reset. Maybe that's okay because reading will not block, but throw an exception instead? Thanks, Florian From Alan.Bateman at oracle.com Wed Jan 23 10:35:28 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2019 10:35:28 +0000 Subject: 8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer In-Reply-To: <87lg3bbtgg.fsf@oldenburg2.str.redhat.com> References: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> <87lg3bbtgg.fsf@oldenburg2.str.redhat.com> Message-ID: <0a494094-8c77-1aeb-7215-9c24b960a891@oracle.com> On 23/01/2019 09:42, Florian Weimer wrote: > : > Do you plan to read from the socket buffer in the implementation of > available()? The problem is that even if there is currently data in the > socket buffer, further data that arrives later can clear it. I think > this can only happen as part of a connection reset. Maybe that's okay > because reading will not block, but throw an exception instead? > Not planning for available to read. The long standing behavior in this area is for SIS.available to consistently return 0 after a connection reset has been detected. This is of course awkward to replicate in a new implementation as it requires detecting connection reset, something that was never implemented in the SocketChannel implementation (mostly because it's highly platform/implementation specific as to how read behaves when attempt after a connection reset). -Alan From fweimer at redhat.com Wed Jan 23 10:55:11 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 23 Jan 2019 11:55:11 +0100 Subject: 8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer In-Reply-To: <0a494094-8c77-1aeb-7215-9c24b960a891@oracle.com> (Alan Bateman's message of "Wed, 23 Jan 2019 10:35:28 +0000") References: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> <87lg3bbtgg.fsf@oldenburg2.str.redhat.com> <0a494094-8c77-1aeb-7215-9c24b960a891@oracle.com> Message-ID: <87y37babjk.fsf@oldenburg2.str.redhat.com> * Alan Bateman: > On 23/01/2019 09:42, Florian Weimer wrote: >> : >> Do you plan to read from the socket buffer in the implementation of >> available()? The problem is that even if there is currently data in the >> socket buffer, further data that arrives later can clear it. I think >> this can only happen as part of a connection reset. Maybe that's okay >> because reading will not block, but throw an exception instead? >> > Not planning for available to read. The long standing behavior in this > area is for SIS.available to consistently return 0 after a connection > reset has been detected. This is of course awkward to replicate in a > new implementation as it requires detecting connection reset, > something that was never implemented in the SocketChannel > implementation (mostly because it's highly platform/implementation > specific as to how read behaves when attempt after a connection > reset). Sorry, what I meant is that available() says that there are bytes, and then when you try to read them, you get an exception because they are no longer there. I doubt that's the intent behind the InputStream::available specification, but as I said, it still avoids blocking, so it may match a literal interpretation. But presumably this is already the behavior with SocketInputStream? Thanks, Florian From daniel.fuchs at oracle.com Wed Jan 23 11:10:32 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Jan 2019 11:10:32 +0000 Subject: RFR: 8217264: HttpClient: Blocking operations in mapper function do not work as documented Message-ID: Hi, Please find below a fix for: 8217264: HttpClient: Blocking operations in mapper function do not work as documented [1] https://bugs.openjdk.java.net/browse/JDK-8217264 webrev: [2] http://cr.openjdk.java.net/~dfuchs/webrev_8217264/webrev.00/ The issue here is that if you try to map an InputStream to a GZIPInputStream in a mapper function provided to BodySubscribers::mapping, the response will be wedged. This is because the constructor of GZIPInputStream calls InputStream::read which blocks the current thread. The fix is to ensure that a new executor task will be used when calling BodySubscriber::getBody - which is the point at which the mapping function gets executed, in order to avoid blocking the current task. This is not a completely satisfactory solution, as doing blocking operations in a mapper function will take a thread out of the Executor's pool until the blocking operation eventually succeeds - which might be until the last byte of the response is received (or worse?), and might end up starving the HttpClient of available threads. I believe the documentation of BodySubscribers::mapping should instead promote safer behaviour - and steer users out of executing blocking operations in the mapper function. I have logged [3] JDK-8217627 to that effect. Even if we fix the API documentation as in [3] - and discourage blocking operation in the mapper, I still believe we should support the occasional blocking mapper functions (with the understanding that the response might get wedged if client's executor doesn't have sufficient free threads) - if only to allow mapping from InputStream to GZIPInputStream when the Executor is a sufficiently sized thread pool executor. This is the effect of my proposed fix [2]. best regards, -- daniel [1] https://bugs.openjdk.java.net/browse/JDK-8217264 [2] http://cr.openjdk.java.net/~dfuchs/webrev_8217264/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8217627 From michael.x.mcmahon at oracle.com Wed Jan 23 11:44:28 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 23 Jan 2019 11:44:28 +0000 Subject: RFR: 8216986 Remove unused code from SocksSocketImpl Message-ID: <5C48539C.7080501@oracle.com> Hi Could I get the following webrev reviewed please? It is just to remove dead code from SocksSocketImpl. Most of the code was an (unused) attempt to implement SOCKS for ServerSockets. getLocalPort() was potentially buggy and should not override the super class implementation. So, that was removed too. A couple of other orphaned methods are removed also. http://cr.openjdk.java.net/~michaelm/8216986/webrev.1/ Thanks, Michael. From Alan.Bateman at oracle.com Wed Jan 23 12:11:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2019 12:11:37 +0000 Subject: 8217461: (ch) Add Net.available to return the number of bytes in the socket input buffer In-Reply-To: <87y37babjk.fsf@oldenburg2.str.redhat.com> References: <6c35fe55-01a7-7bcb-5ecf-9e336e0508e6@oracle.com> <87lg3bbtgg.fsf@oldenburg2.str.redhat.com> <0a494094-8c77-1aeb-7215-9c24b960a891@oracle.com> <87y37babjk.fsf@oldenburg2.str.redhat.com> Message-ID: On 23/01/2019 10:55, Florian Weimer wrote: > : > Sorry, what I meant is that available() says that there are bytes, and > then when you try to read them, you get an exception because they are no > longer there. I doubt that's the intent behind the > InputStream::available specification, but as I said, it still avoids > blocking, so it may match a literal interpretation. > > But presumably this is already the behavior with SocketInputStream? > It's very platform specific as to whether you can read bytes in the socket buffer when a connection reset is reported. This was something we discussed on net-dev last year in the context of other changes to detach the write path from interference due to connection reset. Classic networking has always attempted to mask the differences by remembering the connection reset so that subsequent calls to read work consistently across platforms. There's nothing in the proposed changes that touches or changes the long standing behavior. As regards reading after available returns a position value then the spec can only says that it doesn't block. It can't guarantee that the read doesn't throw I/O exception. Calling close between available and read is another scenario where read will fail. -Alan From trtrmitya at gmail.com Wed Jan 23 12:16:40 2019 From: trtrmitya at gmail.com (Dmitry Sivachenko) Date: Wed, 23 Jan 2019 15:16:40 +0300 Subject: java.net.http.HttpClient: invalid exception when bad status line is returned In-Reply-To: <69F67A3D-F133-44D1-A734-BD15CF74A94F@gmail.com> References: <69F67A3D-F133-44D1-A734-BD15CF74A94F@gmail.com> Message-ID: <681C1658-1C71-4026-94F8-5CFCD343041D@gmail.com> Hello, is this ML the correct place to report problems with HttpClient? If not, can you please point me to the right place? Thanks. > On 18 Jan 2019, at 23:57, Dmitry Sivachenko wrote: > > Hello, > > I am tasting java.net.http.HttpClient with > > openjdk version "11.0.1" 2018-10-16 > OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.1+13) > OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.1+13, mixed mode) > > on Mac OS X 10.14.2. > > Consider the case when server responds with bad (invalid format) status line: "HTTP/1.1 FOO" > > The following IllegalArgumentException is thrown: > > Exception in thread "main" java.lang.IllegalArgumentException: For input string: "FOO" > at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:551) > at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119) > at ru.mitya.test.App.main(App.java:14) > Caused by: java.lang.NumberFormatException: For input string: "FOO" > at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.base/java.lang.Integer.parseInt(Integer.java:652) > at java.base/java.lang.Integer.parseInt(Integer.java:770) > at java.net.http/jdk.internal.net.http.Http1HeaderParser.readStatusLineFeed(Http1HeaderParser.java:197) > at java.net.http/jdk.internal.net.http.Http1HeaderParser.parse(Http1HeaderParser.java:124) > at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:672) > at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:603) > at java.net.http/jdk.internal.net.http.Http1Response$Receiver.accept(Http1Response.java:594) > at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.tryAsyncReceive(Http1Response.java:650) > at java.net.http/jdk.internal.net.http.Http1AsyncReceiver.flush(Http1AsyncReceiver.java:228) > at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(SequentialScheduler.java:175) > at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:147) > at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > > > instead of the expected ProtocolException: > > Exception in thread "main" java.io.IOException: Invalid status line: "HTTP/1.1 FOO" > at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565) > at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119) > at ru.mitya.test.App.main(App.java:14) > Caused by: java.net.ProtocolException: Invalid status line: "HTTP/1.1 FOO" > <...> > > The suggested fix would be to catch IllegalArgumentException thrown by Integer.parseInt() in readStatusLineFeed() and throw > ProtocolException instead of it. > > What do you think? > > Thanks. From daniel.fuchs at oracle.com Wed Jan 23 12:32:01 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Jan 2019 12:32:01 +0000 Subject: java.net.http.HttpClient: invalid exception when bad status line is returned In-Reply-To: <681C1658-1C71-4026-94F8-5CFCD343041D@gmail.com> References: <69F67A3D-F133-44D1-A734-BD15CF74A94F@gmail.com> <681C1658-1C71-4026-94F8-5CFCD343041D@gmail.com> Message-ID: Hi Dmitry, Thanks for reporting this. Right - the IllegalArgumentException is a bit strange there, and an IOException (or subclass of it) wrapping the NumberFormatException would be more appropriate. If you have OpenJDK author status and a JBS account then you could log a bug at https://bugs.openjdk.java.net/ otherwise then https://bugs.java.com/bugdatabase/ would be the place. best regards, -- daniel On 23/01/2019 12:16, Dmitry Sivachenko wrote: > Hello, > > is this ML the correct place to report problems with HttpClient? > > If not, can you please point me to the right place? > > Thanks. > > >> On 18 Jan 2019, at 23:57, Dmitry Sivachenko wrote: >> >> Hello, >> >> I am tasting java.net.http.HttpClient with >> >> openjdk version "11.0.1" 2018-10-16 >> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.1+13) >> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.1+13, mixed mode) >> >> on Mac OS X 10.14.2. >> >> Consider the case when server responds with bad (invalid format) status line: "HTTP/1.1 FOO" >> >> The following IllegalArgumentException is thrown: >> >> Exception in thread "main" java.lang.IllegalArgumentException: For input string: "FOO" >> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:551) >> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119) >> at ru.mitya.test.App.main(App.java:14) >> Caused by: java.lang.NumberFormatException: For input string: "FOO" >> at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) >> at java.base/java.lang.Integer.parseInt(Integer.java:652) >> at java.base/java.lang.Integer.parseInt(Integer.java:770) >> at java.net.http/jdk.internal.net.http.Http1HeaderParser.readStatusLineFeed(Http1HeaderParser.java:197) >> at java.net.http/jdk.internal.net.http.Http1HeaderParser.parse(Http1HeaderParser.java:124) >> at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:672) >> at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.handle(Http1Response.java:603) >> at java.net.http/jdk.internal.net.http.Http1Response$Receiver.accept(Http1Response.java:594) >> at java.net.http/jdk.internal.net.http.Http1Response$HeadersReader.tryAsyncReceive(Http1Response.java:650) >> at java.net.http/jdk.internal.net.http.Http1AsyncReceiver.flush(Http1AsyncReceiver.java:228) >> at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(SequentialScheduler.java:175) >> at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:147) >> at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198) >> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> at java.base/java.lang.Thread.run(Thread.java:834) >> >> >> instead of the expected ProtocolException: >> >> Exception in thread "main" java.io.IOException: Invalid status line: "HTTP/1.1 FOO" >> at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565) >> at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119) >> at ru.mitya.test.App.main(App.java:14) >> Caused by: java.net.ProtocolException: Invalid status line: "HTTP/1.1 FOO" >> <...> >> >> The suggested fix would be to catch IllegalArgumentException thrown by Integer.parseInt() in readStatusLineFeed() and throw >> ProtocolException instead of it. >> >> What do you think? >> >> Thanks. > From Alan.Bateman at oracle.com Wed Jan 23 12:37:39 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2019 12:37:39 +0000 Subject: RFR: 8216986 Remove unused code from SocksSocketImpl In-Reply-To: <5C48539C.7080501@oracle.com> References: <5C48539C.7080501@oracle.com> Message-ID: <38f904cb-a353-fb09-8113-dcd55dd37cfc@oracle.com> On 23/01/2019 11:44, Michael McMahon wrote: > Hi > > Could I get the following webrev reviewed please? > It is just to remove dead code from SocksSocketImpl. > Most of the code was an (unused) attempt to implement > SOCKS for ServerSockets. getLocalPort() was potentially buggy > and should not override the super class implementation. > So, that was removed too. A couple of other orphaned methods > are removed also. > > http://cr.openjdk.java.net/~michaelm/8216986/webrev.1/ This is a good cleanup. Seems wrong for getLocalPort to return the "remote" address of the SOCKS server so that fix looks correct. Does it need a test? At some point I think we need to get this SocketImpl changed so that it delegates rather than extends PlainSocketImpl. I suspect that work will identify a few other oddities with SOCKS connections that may not be obvious now. -Alan From michael.x.mcmahon at oracle.com Wed Jan 23 14:30:52 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 23 Jan 2019 14:30:52 +0000 Subject: RFR: 8216986 Remove unused code from SocksSocketImpl In-Reply-To: <38f904cb-a353-fb09-8113-dcd55dd37cfc@oracle.com> References: <5C48539C.7080501@oracle.com> <38f904cb-a353-fb09-8113-dcd55dd37cfc@oracle.com> Message-ID: <5C487A9C.8070500@oracle.com> On 23/01/2019, 12:37, Alan Bateman wrote: > On 23/01/2019 11:44, Michael McMahon wrote: >> Hi >> >> Could I get the following webrev reviewed please? >> It is just to remove dead code from SocksSocketImpl. >> Most of the code was an (unused) attempt to implement >> SOCKS for ServerSockets. getLocalPort() was potentially buggy >> and should not override the super class implementation. >> So, that was removed too. A couple of other orphaned methods >> are removed also. >> >> http://cr.openjdk.java.net/~michaelm/8216986/webrev.1/ > This is a good cleanup. Seems wrong for getLocalPort to return the > "remote" address of the SOCKS server so that fix looks correct. Does > it need a test? > I can add a test for that. > At some point I think we need to get this SocketImpl changed so that > it delegates rather than extends PlainSocketImpl. I suspect that work > will identify a few other oddities with SOCKS connections that may not > be obvious now. > Yes, that's what I plan to do next. Thanks, Michael. From christoph.langer at sap.com Wed Jan 23 16:05:55 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Jan 2019 16:05:55 +0000 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test Message-ID: <3f45b06bb6654a42b70f4184970878b9@sap.com> Hi, please review a small test update. Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ I'd like to move the test for the correct default value of security property "jdk.includeInExceptions" into an own testcase in the jdk.security area. This seems a bit more natural than to hide this check in a java/net specific test and will help finding/maintaining tests when the (default-)value for that property changes. For instance new values get added or other OpenJDK builds have different defaults (e.g. SAPMachine). Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From trtrmitya at gmail.com Wed Jan 23 20:38:40 2019 From: trtrmitya at gmail.com (Dmitry Sivachenko) Date: Wed, 23 Jan 2019 23:38:40 +0300 Subject: java.net.http.HttpClient: invalid exception when bad status line is returned In-Reply-To: References: <69F67A3D-F133-44D1-A734-BD15CF74A94F@gmail.com> <681C1658-1C71-4026-94F8-5CFCD343041D@gmail.com> Message-ID: <7724699A-83A0-42A1-84C2-A0936324FDCF@gmail.com> > On 23 Jan 2019, at 15:32, Daniel Fuchs wrote: > > Hi Dmitry, > > Thanks for reporting this. > > Right - the IllegalArgumentException is a bit strange there, > and an IOException (or subclass of it) wrapping the NumberFormatException would be more appropriate. > > If you have OpenJDK author status and a JBS account then you > could log a bug at https://bugs.openjdk.java.net/ > otherwise then https://bugs.java.com/bugdatabase/ > would be the place. > Thanks! I followed second link and filed bug report #9059077 We have more bugs for HttpClient to report, this was the simplest one, I will report them one at a time. From goetz.lindenmaier at sap.com Thu Jan 24 07:47:46 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 24 Jan 2019 07:47:46 +0000 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test In-Reply-To: <3f45b06bb6654a42b70f4184970878b9@sap.com> References: <3f45b06bb6654a42b70f4184970878b9@sap.com> Message-ID: <076017e21cc0495a990e67e7b9bcf2e8@sap.com> Hi Christoph, it is a good idea to keep testing these two matters separately. Could you please document in the new test that in OpenJDK it is decided to keep this property empty? Something like: @comment In OpenJDK, this property is empty by default and on purpose. This test assures the default is not changed. Otherwise, looks good. Best regards, Goetz. From: net-dev On Behalf Of Langer, Christoph Sent: Mittwoch, 23. Januar 2019 17:06 To: OpenJDK Dev list ; OpenJDK Network Dev list Subject: [CAUTION] RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test Hi, please review a small test update. Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ I'd like to move the test for the correct default value of security property "jdk.includeInExceptions" into an own testcase in the jdk.security area. This seems a bit more natural than to hide this check in a java/net specific test and will help finding/maintaining tests when the (default-)value for that property changes. For instance new values get added or other OpenJDK builds have different defaults (e.g. SAPMachine). Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Jan 24 10:50:22 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 24 Jan 2019 10:50:22 +0000 Subject: RFR: 8217264: HttpClient: Blocking operations in mapper function do not work as documented In-Reply-To: References: Message-ID: Daniel, On 23/01/2019 11:10, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8217264: HttpClient: Blocking operations in mapper function do not > ???????? work as documented > [1] https://bugs.openjdk.java.net/browse/JDK-8217264 > > webrev: > [2] http://cr.openjdk.java.net/~dfuchs/webrev_8217264/webrev.00/ I agree with the approach, and the changes look good ( in fact less invasive that I expected ). Thanks for adding such a comprehensive test, it gives confidence that things are operating as expected. I also agree with updating the example in the API documentation. It should not promote blocking in the mapper function. I look forward to reviewing that change too. -Chris. From christoph.langer at sap.com Thu Jan 24 10:58:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 24 Jan 2019 10:58:57 +0000 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test In-Reply-To: <076017e21cc0495a990e67e7b9bcf2e8@sap.com> References: <3f45b06bb6654a42b70f4184970878b9@sap.com> <076017e21cc0495a990e67e7b9bcf2e8@sap.com> Message-ID: <61ce165f2159441e9fb8e95bacdccdbb@sap.com> Hi Goetz, thanks for the review. I've added the comment as you suggested: http://cr.openjdk.java.net/~clanger/webrevs/8217657.1/ Will run it through our nightly tests before submitting... /Christoph From: Lindenmaier, Goetz Sent: Donnerstag, 24. Januar 2019 08:48 To: Langer, Christoph ; OpenJDK Dev list ; OpenJDK Network Dev list Subject: RE: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test Hi Christoph, it is a good idea to keep testing these two matters separately. Could you please document in the new test that in OpenJDK it is decided to keep this property empty? Something like: @comment In OpenJDK, this property is empty by default and on purpose. This test assures the default is not changed. Otherwise, looks good. Best regards, Goetz. From: net-dev > On Behalf Of Langer, Christoph Sent: Mittwoch, 23. Januar 2019 17:06 To: OpenJDK Dev list >; OpenJDK Network Dev list > Subject: [CAUTION] RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test Hi, please review a small test update. Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ I'd like to move the test for the correct default value of security property "jdk.includeInExceptions" into an own testcase in the jdk.security area. This seems a bit more natural than to hide this check in a java/net specific test and will help finding/maintaining tests when the (default-)value for that property changes. For instance new values get added or other OpenJDK builds have different defaults (e.g. SAPMachine). Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Jan 24 11:05:09 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 24 Jan 2019 11:05:09 +0000 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test In-Reply-To: <61ce165f2159441e9fb8e95bacdccdbb@sap.com> References: <3f45b06bb6654a42b70f4184970878b9@sap.com> <076017e21cc0495a990e67e7b9bcf2e8@sap.com> <61ce165f2159441e9fb8e95bacdccdbb@sap.com> Message-ID: <40756eaef100449fb9a6b9767a7e0e5e@sap.com> Thanks! I should have stated that I don't need a new webrev, thanks anyways. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 24. Januar 2019 11:59 > To: Lindenmaier, Goetz ; OpenJDK Dev list > ; OpenJDK Network Dev list dev at openjdk.java.net> > Subject: RE: RFR 8217657: Move the test for default value of > jdk.includeInExceptions into own test > > Hi Goetz, > > > > thanks for the review. > > > > I've added the comment as you suggested: > http://cr.openjdk.java.net/~clanger/webrevs/8217657.1/ > > > > Will run it through our nightly tests before submitting... > > > > /Christoph > > > > > > From: Lindenmaier, Goetz > Sent: Donnerstag, 24. Januar 2019 08:48 > To: Langer, Christoph ; OpenJDK Dev list > ; OpenJDK Network Dev list dev at openjdk.java.net> > Subject: RE: RFR 8217657: Move the test for default value of > jdk.includeInExceptions into own test > > > > Hi Christoph, > > > > it is a good idea to keep testing these two matters separately. > > > > Could you please document in the new test that in OpenJDK > > it is decided to keep this property empty? > > Something like: > > @comment In OpenJDK, this property is empty by default and on purpose. This > test assures the default is not changed. > > > > Otherwise, looks good. > > > > Best regards, > > Goetz. > > > > From: net-dev bounces at openjdk.java.net> > On Behalf Of Langer, Christoph > Sent: Mittwoch, 23. Januar 2019 17:06 > To: OpenJDK Dev list dev at openjdk.java.net> >; OpenJDK Network Dev list dev at openjdk.java.net > > Subject: [CAUTION] RFR 8217657: Move the test for default value of > jdk.includeInExceptions into own test > > > > Hi, > > > > please review a small test update. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ > > > > I'd like to move the test for the correct default value of security property > "jdk.includeInExceptions" into an own testcase in the jdk.security area. This > seems a bit more natural than to hide this check in a java/net specific test and > will help finding/maintaining tests when the (default-)value for that property > changes. For instance new values get added or other OpenJDK builds have > different defaults (e.g. SAPMachine). > > > > Thanks > > Christoph > > From michael.x.mcmahon at oracle.com Thu Jan 24 13:09:34 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 24 Jan 2019 13:09:34 +0000 Subject: RFR: 8216986 Remove unused code from SocksSocketImpl In-Reply-To: <5C487A9C.8070500@oracle.com> References: <5C48539C.7080501@oracle.com> <38f904cb-a353-fb09-8113-dcd55dd37cfc@oracle.com> <5C487A9C.8070500@oracle.com> Message-ID: <5C49B90E.4050407@oracle.com> I've updated the webrev at http://cr.openjdk.java.net/~michaelm/8216986/webrev.2/ to add some tests and also I found the same dubious implementation of getLocalPort() in HttpConnectSocketImpl.java. The test infrastructure needed some cleanup also. Thanks, Michael. On 23/01/2019, 14:30, Michael McMahon wrote: > > > On 23/01/2019, 12:37, Alan Bateman wrote: >> On 23/01/2019 11:44, Michael McMahon wrote: >>> Hi >>> >>> Could I get the following webrev reviewed please? >>> It is just to remove dead code from SocksSocketImpl. >>> Most of the code was an (unused) attempt to implement >>> SOCKS for ServerSockets. getLocalPort() was potentially buggy >>> and should not override the super class implementation. >>> So, that was removed too. A couple of other orphaned methods >>> are removed also. >>> >>> http://cr.openjdk.java.net/~michaelm/8216986/webrev.1/ >> This is a good cleanup. Seems wrong for getLocalPort to return the >> "remote" address of the SOCKS server so that fix looks correct. Does >> it need a test? >> > > I can add a test for that. > >> At some point I think we need to get this SocketImpl changed so that >> it delegates rather than extends PlainSocketImpl. I suspect that work >> will identify a few other oddities with SOCKS connections that may >> not be obvious now. >> > > Yes, that's what I plan to do next. > > Thanks, > > Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Jan 24 14:38:49 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Jan 2019 14:38:49 +0000 Subject: RFR: 8216986 Remove unused code from SocksSocketImpl In-Reply-To: <5C49B90E.4050407@oracle.com> References: <5C48539C.7080501@oracle.com> <38f904cb-a353-fb09-8113-dcd55dd37cfc@oracle.com> <5C487A9C.8070500@oracle.com> <5C49B90E.4050407@oracle.com> Message-ID: <4dc641c7-0697-2246-7893-f60746870ea0@oracle.com> On 24/01/2019 13:09, Michael McMahon wrote: > I've updated the webrev at > http://cr.openjdk.java.net/~michaelm/8216986/webrev.2/ > to add some tests and also I found the same dubious implementation of > getLocalPort() > in HttpConnectSocketImpl.java. The test infrastructure needed some > cleanup also. The changes to SocksSocketImpl and in HttpConnectSocketImpl look good to me. The test changes look okay too. A potential improvement is to have SocksServer implement Closeable and rename its terminate method to close as that would allow the tests to use try-with-resources and ensure connections are closed in the event of an exception. Not important if you don't want to spend time on it of course. -Alan From michael.x.mcmahon at oracle.com Thu Jan 24 15:38:04 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 24 Jan 2019 15:38:04 +0000 Subject: RFR: 8216986 Remove unused code from SocksSocketImpl In-Reply-To: <4dc641c7-0697-2246-7893-f60746870ea0@oracle.com> References: <5C48539C.7080501@oracle.com> <38f904cb-a353-fb09-8113-dcd55dd37cfc@oracle.com> <5C487A9C.8070500@oracle.com> <5C49B90E.4050407@oracle.com> <4dc641c7-0697-2246-7893-f60746870ea0@oracle.com> Message-ID: <5C49DBDC.9060300@oracle.com> On 24/01/2019, 14:38, Alan Bateman wrote: > On 24/01/2019 13:09, Michael McMahon wrote: >> I've updated the webrev at >> http://cr.openjdk.java.net/~michaelm/8216986/webrev.2/ >> to add some tests and also I found the same dubious implementation of >> getLocalPort() >> in HttpConnectSocketImpl.java. The test infrastructure needed some >> cleanup also. > The changes to SocksSocketImpl and in HttpConnectSocketImpl look good > to me. > > The test changes look okay too. A potential improvement is to have > SocksServer implement Closeable and rename its terminate method to > close as that would allow the tests to use try-with-resources and > ensure connections are closed in the event of an exception. Not > important if you don't want to spend time on it of course. > > -Alan > Yeah, considering the test runs in samevm mode, it would be better to ensure full cleanup. I will push after changing that. Thanks! Michael. From sean.mullan at oracle.com Thu Jan 24 16:42:35 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Jan 2019 11:42:35 -0500 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test In-Reply-To: <3f45b06bb6654a42b70f4184970878b9@sap.com> References: <3f45b06bb6654a42b70f4184970878b9@sap.com> Message-ID: <24498b4b-ece1-180c-2598-e7fe709d5f4b@oracle.com> I don't think you really need to run the test with the othervm flag, unless you are concerned other tests may be setting this property and (incorrectly) not running in a separate VM, which would be a bug in my opinion. Well, then maybe you should run it in othervm just in case. Otherwise, looks ok to me. --Sean On 1/23/19 11:05 AM, Langer, Christoph wrote: > Hi, > > please review a small test update. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ > > I?d like to move the test for the correct default value of security > property ?jdk.includeInExceptions? into an own testcase in the > jdk.security area. This seems a bit more natural than to hide this check > in a java/net specific test and will help finding/maintaining tests when > the (default-)value for that property changes. For instance new values > get added or other OpenJDK builds have different defaults (e.g. SAPMachine). > > Thanks > > Christoph > From Roger.Riggs at oracle.com Thu Jan 24 18:58:08 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 24 Jan 2019 13:58:08 -0500 Subject: RFR 8217740: SocksIPv6Test.java compilation error Message-ID: <51311060-2486-9fc7-1ef1-14e944f2e8d7@oracle.com> Please review a quick fix for a test compilation error, as a side effect of 8216986. diff --git a/test/jdk/java/net/Socks/SocksIPv6Test.java b/test/jdk/java/net/Socks/SocksIPv6Test.java --- a/test/jdk/java/net/Socks/SocksIPv6Test.java +++ b/test/jdk/java/net/Socks/SocksIPv6Test.java @@ -173,7 +173,7 @@ public class SocksIPv6Test { ???????????? server.stop(1); ???????? } ???????? if (socks != null) { -??????????? socks.terminate(); +??????????? socks.close(); ???????? } ???? } ?} Thanks, Roger From brian.burkhalter at oracle.com Thu Jan 24 19:19:57 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 24 Jan 2019 11:19:57 -0800 Subject: RFR 8217740: SocksIPv6Test.java compilation error In-Reply-To: <51311060-2486-9fc7-1ef1-14e944f2e8d7@oracle.com> References: <51311060-2486-9fc7-1ef1-14e944f2e8d7@oracle.com> Message-ID: <021876EB-483A-40F7-9EB5-888740332828@oracle.com> Verified against current repo. +1 Brian > On Jan 24, 2019, at 10:58 AM, Roger Riggs wrote: > > Please review a quick fix for a test compilation error, as a side effect of 8216986. > > diff --git a/test/jdk/java/net/Socks/SocksIPv6Test.java b/test/jdk/java/net/Socks/SocksIPv6Test.java > --- a/test/jdk/java/net/Socks/SocksIPv6Test.java > +++ b/test/jdk/java/net/Socks/SocksIPv6Test.java > @@ -173,7 +173,7 @@ public class SocksIPv6Test { > server.stop(1); > } > if (socks != null) { > - socks.terminate(); > + socks.close(); > } > } > } -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Thu Jan 24 19:38:40 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 24 Jan 2019 14:38:40 -0500 Subject: RFR 8217740: SocksIPv6Test.java compilation error In-Reply-To: <021876EB-483A-40F7-9EB5-888740332828@oracle.com> References: <51311060-2486-9fc7-1ef1-14e944f2e8d7@oracle.com> <021876EB-483A-40F7-9EB5-888740332828@oracle.com> Message-ID: <5f9f7d20-eda9-775e-82ac-a84e57c831ec@oracle.com> Thanks? Brian On 01/24/2019 02:19 PM, Brian Burkhalter wrote: > Verified against current repo. > > +1 > > Brian > >> On Jan 24, 2019, at 10:58 AM, Roger Riggs > > wrote: >> >> Please review a quick fix for a test compilation error, as a side >> effect of 8216986. >> >> diff --git a/test/jdk/java/net/Socks/SocksIPv6Test.java >> b/test/jdk/java/net/Socks/SocksIPv6Test.java >> --- a/test/jdk/java/net/Socks/SocksIPv6Test.java >> +++ b/test/jdk/java/net/Socks/SocksIPv6Test.java >> @@ -173,7 +173,7 @@ public class SocksIPv6Test { >> server.stop(1); >> ???????? } >> ???????? if (socks != null) { >> - socks.terminate(); >> + socks.close(); >> ???????? } >> ???? } >> ?} > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jan 24 22:06:13 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 24 Jan 2019 22:06:13 +0000 Subject: RFR 8217657: Move the test for default value of jdk.includeInExceptions into own test In-Reply-To: <24498b4b-ece1-180c-2598-e7fe709d5f4b@oracle.com> References: <3f45b06bb6654a42b70f4184970878b9@sap.com> <24498b4b-ece1-180c-2598-e7fe709d5f4b@oracle.com> Message-ID: <7bc9884027b94df1b4c4722245d0b451@sap.com> Hi Sean, thanks for looking at this. I agree. Will remove othervm... Best regards Christoph > -----Original Message----- > From: Sean Mullan > Sent: Donnerstag, 24. Januar 2019 17:43 > To: Langer, Christoph ; OpenJDK Dev list > ; OpenJDK Network Dev list dev at openjdk.java.net> > Subject: Re: RFR 8217657: Move the test for default value of > jdk.includeInExceptions into own test > > I don't think you really need to run the test with the othervm flag, > unless you are concerned other tests may be setting this property and > (incorrectly) not running in a separate VM, which would be a bug in my > opinion. Well, then maybe you should run it in othervm just in case. > Otherwise, looks ok to me. > > --Sean > > On 1/23/19 11:05 AM, Langer, Christoph wrote: > > Hi, > > > > please review a small test update. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217657 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/ > > > > I'd like to move the test for the correct default value of security > > property "jdk.includeInExceptions" into an own testcase in the > > jdk.security area. This seems a bit more natural than to hide this check > > in a java/net specific test and will help finding/maintaining tests when > > the (default-)value for that property changes. For instance new values > > get added or other OpenJDK builds have different defaults (e.g. > SAPMachine). > > > > Thanks > > > > Christoph > > From Alan.Bateman at oracle.com Fri Jan 25 14:08:35 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Jan 2019 14:08:35 +0000 Subject: NIO based SocketImpl to replace legacy PlainSocketImpl Message-ID: <3225f8f0-08f2-c9bb-6dc4-b7eb7cfc4aa4@oracle.com> I've created a branch in the sandbox, named "niosocketimpl-branch", with a prototype SocketImpl implementation based on the infrastructure in sun.nio.ch package that supports the NIO channel implementations. The branch also includes the changes to java.net.Socket and ServerSocket to use this SocketImpl by default. There are several motivations for this prototype: The existing PlainSocketImpl is not fit for purpose in the potential future world of fibers that park instead of blocking carrier threads in syscalls. As I'm sure most people are on net-dev are aware, PlainSocketImpl is horrible to maintain due to the complexity of the code paths in its native methods. Replacing PlainSocketImpl, along with its associates SocketInputStream and SocketOutputStream, bring other benefits such as not needing to use the thread stack for I/O and not needing the fd table data structure to support asynchronous close. We have to be a cautious about replacing the PlainSocket/SIS/SOS after 20 years of service. It is likely that there is behavior in unspecified areas and corner case scenarios that existing applications or libraries may depend upon. There is performance work to do but it's possible there are cases where the performance might degrade, e.g. many years ago there were attempts to fix a synchronization issue in PlainSocketImpl that lead to complaints from usages involving hundreds of threads blocking on ServerSocket::accept. To that end, we are planning to evolve the prototype to allow the old and new SocketImpls to co-exist, maybe switched by a system property or some other means. Going there may require a bit yak shaving, for example in the SOCKS and HTTP proxy implementations as they need to be re-worked to forward rather than sub-class. If the prototype goes further then the idea is that both implementations could be included in the JDK for a few releases before removing the old code. The prototype doesn't have a replacement for PlainDagramSocketImpl at this time. There are a few issues around how legacy MulticastSocket behaves that will take a bit of time to sort out. Ideally its replacement will use the same infrastructure as the DatgramChannel implementation as that supports modern muilticasting features and is a lot easier to maintain. For now, we (= Michael McMahon and myself for now) will iterate on this prototype in the sandbox. If we go forward with it then we'll likely create a JEP. -Alan From daniel.fuchs at oracle.com Fri Jan 25 14:10:23 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 25 Jan 2019 14:10:23 +0000 Subject: [13] RFR (doc): 8217627: HttpClient: The API documentation of BodySubscribers::mapping promotes bad behavior Message-ID: Hi, Please find below a doc clarification change for: 8217627: HttpClient: The API documentation of BodySubscribers::mapping promotes bad behavior https://bugs.openjdk.java.net/browse/JDK-8217627 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8217627/webrev.00 New API doc: For better readability the new generated API documentation of BodySubscribers::mapping can be seen here: http://cr.openjdk.java.net/~dfuchs/webrev_8217627/webrev.00/api/java.net.http/java/net/http/HttpResponse.BodySubscribers.html#mapping(java.net.http.HttpResponse.BodySubscriber,java.util.function.Function) best regards, -- daniel From chris.hegarty at oracle.com Fri Jan 25 14:21:08 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 Jan 2019 14:21:08 +0000 Subject: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers Message-ID: <9C59FE8C-7FA9-478C-BD44-50BD53A026CA@oracle.com> When tunneling WebSocket over a proxy requiring authentication, the implementation must ensure that the appropriate Upgrade headers are not lost after the tunnel has been established. The source changes are quite straight forward, the remaining bulk of the changes are to address a deficiency in the testing of proxying and authentication, when establishing a WebSocket connection. Webrev: http://cr.openjdk.java.net/~chegar/8217429/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8217429 -Chris From chris.hegarty at oracle.com Fri Jan 25 14:33:27 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 Jan 2019 14:33:27 +0000 Subject: [13] RFR (doc): 8217627: HttpClient: The API documentation of BodySubscribers::mapping promotes bad behavior In-Reply-To: References: Message-ID: <01B80541-D460-4702-8BC7-0EFD20C840F5@oracle.com> > On 25 Jan 2019, at 14:10, Daniel Fuchs wrote: > > Hi, > > Please find below a doc clarification change for: > > 8217627: HttpClient: The API documentation of BodySubscribers::mapping > promotes bad behavior > https://bugs.openjdk.java.net/browse/JDK-8217627 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8217627/webrev.00 This looks good Daniel. -Chris. From pavel.rappo at oracle.com Fri Jan 25 15:16:38 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 25 Jan 2019 15:16:38 +0000 Subject: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers In-Reply-To: <9C59FE8C-7FA9-478C-BD44-50BD53A026CA@oracle.com> References: <9C59FE8C-7FA9-478C-BD44-50BD53A026CA@oracle.com> Message-ID: <74DDB742-5910-4958-A078-670DE9B7C118@oracle.com> Chris, thanks for doing this! I have two questions on this change. 1. After this change has been applied, there will be a circular dependency between HttpRequestImpl and OpeningHandshake. If this code is used by these two classes maybe we are better off extracting it into some (already existing) third class? 2. Why does this change add server.close() to each and every test method of WebSocketTest? If I'm not mistaken that's what @AfterTest public void cleanup() is supposed to do. > On 25 Jan 2019, at 14:21, Chris Hegarty wrote: > > When tunneling WebSocket over a proxy requiring authentication, the > implementation must ensure that the appropriate Upgrade headers are > not lost after the tunnel has been established. The source changes are > quite straight forward, the remaining bulk of the changes are to address > a deficiency in the testing of proxying and authentication, when > establishing a WebSocket connection. > > Webrev: > http://cr.openjdk.java.net/~chegar/8217429/webrev.01/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8217429 > > -Chris From daniel.fuchs at oracle.com Fri Jan 25 15:34:03 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 25 Jan 2019 15:34:03 +0000 Subject: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers In-Reply-To: <9C59FE8C-7FA9-478C-BD44-50BD53A026CA@oracle.com> References: <9C59FE8C-7FA9-478C-BD44-50BD53A026CA@oracle.com> Message-ID: Hi Chris, Looks good. I had the same question than Pavel about server.close(). No test for both proxy + server authorization with -Djdk.http.auth.tunneling.disabledSchemes ? cheers, -- daniel On 25/01/2019 14:21, Chris Hegarty wrote: > When tunneling WebSocket over a proxy requiring authentication, the > implementation must ensure that the appropriate Upgrade headers are > not lost after the tunnel has been established. The source changes are > quite straight forward, the remaining bulk of the changes are to address > a deficiency in the testing of proxying and authentication, when > establishing a WebSocket connection. > > Webrev: > http://cr.openjdk.java.net/~chegar/8217429/webrev.01/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8217429 > > -Chris > From chris.hegarty at oracle.com Fri Jan 25 17:04:16 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 Jan 2019 17:04:16 +0000 Subject: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers In-Reply-To: <74DDB742-5910-4958-A078-670DE9B7C118@oracle.com> References: <9C59FE8C-7FA9-478C-BD44-50BD53A026CA@oracle.com> <74DDB742-5910-4958-A078-670DE9B7C118@oracle.com> Message-ID: <97E87EE6-5CF6-4889-9B9A-3A4E5EAFB5F8@oracle.com> Pavel, > On 25 Jan 2019, at 15:16, Pavel Rappo wrote: > > Chris, thanks for doing this! I have two questions on this change. > > 1. After this change has been applied, there will be a circular dependency > between HttpRequestImpl and OpeningHandshake. If this code is used by these two > classes maybe we are better off extracting it into some (already existing) third > class? I moved the code to common.Utils, to avoid any unnecessary dependency. > 2. Why does this change add server.close() to each and every test method of > WebSocketTest? If I'm not mistaken that's what @AfterTest public void cleanup() > is supposed to do. I think @AfterTest does not do what you think it does. @AfterTest: The annotated method will be run after all the test methods belonging to the classes inside the tag have run. Really, these tests should use try-with-resources, but I wanted avoid obfuscating the changes. That can be done separately. -Chris. From chris.hegarty at oracle.com Fri Jan 25 17:07:43 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 Jan 2019 17:07:43 +0000 Subject: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers In-Reply-To: References: <9C59FE8C-7FA9-478C-BD44-50BD53A026CA@oracle.com> Message-ID: Daniel, > On 25 Jan 2019, at 15:34, Daniel Fuchs wrote: > > Hi Chris, > > Looks good. > I had the same question than Pavel about server.close(). Answered already in reply to Pavel?s question. > No test for both proxy + server authorization with > -Djdk.http.auth.tunneling.disabledSchemes ? No, not yet. It's easy to add a test for that scenario, but there is a separate, kinda, unrelated issue that prevents it from working. Since fixing that issue requires changing code that will affect secure HTTP connections too, I prefer to separate that out into a different JIRA issue. -Chris. From pavel.rappo at oracle.com Fri Jan 25 17:17:39 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 25 Jan 2019 17:17:39 +0000 Subject: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers In-Reply-To: <97E87EE6-5CF6-4889-9B9A-3A4E5EAFB5F8@oracle.com> References: <9C59FE8C-7FA9-478C-BD44-50BD53A026CA@oracle.com> <74DDB742-5910-4958-A078-670DE9B7C118@oracle.com> <97E87EE6-5CF6-4889-9B9A-3A4E5EAFB5F8@oracle.com> Message-ID: > On 25 Jan 2019, at 17:04, Chris Hegarty wrote: > > I moved the code to common.Utils, to avoid any unnecessary dependency. Thanks. >> 2. Why does this change add server.close() to each and every test method of >> WebSocketTest? If I'm not mistaken that's what @AfterTest public void cleanup() >> is supposed to do. > > I think @AfterTest does not do what you think it does. You are right, I was mistaken. I will have to make sure WebSocket test cases perform their cleanup correctly. Looks like it's not the only test file that has this issue. Try-with-resources might be okay and self-contained, true. However, for my liking it's a bit messy for this purpose. It's a duplication in every method and eats up one full indentation block. @AfterMethod [1] seems to be the right thing to do. -------------------------------------------------------------------------------- [1] http://testng.org/doc/documentation-main.html#annotations From daniel.fuchs at oracle.com Fri Jan 25 17:20:11 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 25 Jan 2019 17:20:11 +0000 Subject: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers In-Reply-To: References: <9C59FE8C-7FA9-478C-BD44-50BD53A026CA@oracle.com> Message-ID: <570abb52-450b-794a-3b49-5a98fde93616@oracle.com> Thanks Chris. Makes sense, and looks good! best regards, -- daniel On 25/01/2019 17:07, Chris Hegarty wrote: > Daniel, > >> On 25 Jan 2019, at 15:34, Daniel Fuchs wrote: >> >> Hi Chris, >> >> Looks good. >> I had the same question than Pavel about server.close(). > > Answered already in reply to Pavel?s question. > >> No test for both proxy + server authorization with >> -Djdk.http.auth.tunneling.disabledSchemes ? > > No, not yet. It's easy to add a test for that scenario, but there is a > separate, kinda, unrelated issue that prevents it from working. Since > fixing that issue requires changing code that will affect secure HTTP > connections too, I prefer to separate that out into a different JIRA > issue. > > -Chris. > From daniel.fuchs at oracle.com Mon Jan 28 12:03:42 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 28 Jan 2019 12:03:42 +0000 Subject: RFR (testbug): 8210130: java/net/httpclient/UnknownBodyLengthTest.java failed Message-ID: <1e636c78-c6bd-a25c-bdff-6abeff5bf6da@oracle.com> Hi, Please find below a test for: 8210130: java/net/httpclient/UnknownBodyLengthTest.java failed https://bugs.openjdk.java.net/browse/JDK-8210130 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8210130/webrev.00/ This test has been seen failing from time to time, often Caused by: java.io.IOException: An established connection was aborted by the software in your host machine The fix makes the test retry the operation once. As far as my testing goes this does seem to make it more robust. best regards, -- daniel From chris.hegarty at oracle.com Mon Jan 28 14:34:38 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 28 Jan 2019 14:34:38 +0000 Subject: RFR (testbug): 8210130: java/net/httpclient/UnknownBodyLengthTest.java failed In-Reply-To: <1e636c78-c6bd-a25c-bdff-6abeff5bf6da@oracle.com> References: <1e636c78-c6bd-a25c-bdff-6abeff5bf6da@oracle.com> Message-ID: On 28/01/2019 12:03, Daniel Fuchs wrote: > Hi, > > Please find below a test for: > > 8210130: java/net/httpclient/UnknownBodyLengthTest.java failed > https://bugs.openjdk.java.net/browse/JDK-8210130 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8210130/webrev.00/ Looks good Daniel. -Chris. From daniel.fuchs at oracle.com Mon Jan 28 17:42:36 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 28 Jan 2019 17:42:36 +0000 Subject: RFR (testbug): 8217882: java/net/httpclient/MaxStreams.java failed once Message-ID: Hi, Please find below a patch for: 8217882: java/net/httpclient/MaxStreams.java failed once https://bugs.openjdk.java.net/browse/JDK-8217882 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8217882/webrev.00/ The patch simply instruments the test with some more traces so that we might have a better diagnosis next time it fails. best regards, -- daniel From brian.burkhalter at oracle.com Mon Jan 28 17:45:50 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 28 Jan 2019 09:45:50 -0800 Subject: RFR (testbug): 8217882: java/net/httpclient/MaxStreams.java failed once In-Reply-To: References: Message-ID: <8DDA4637-9195-4A62-91E9-D2C90F586777@oracle.com> Hi Daniel, Perhaps consistently capitalize the first word in each message? Otherwise OK. No need to refresh. Thanks, Brian > On Jan 28, 2019, at 9:42 AM, Daniel Fuchs wrote: > > Please find below a patch for: > > 8217882: java/net/httpclient/MaxStreams.java failed once > https://bugs.openjdk.java.net/browse/JDK-8217882 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8217882/webrev.00/ > > The patch simply instruments the test with > some more traces so that we might have a better > diagnosis next time it fails. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Mon Jan 28 17:57:48 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 28 Jan 2019 17:57:48 +0000 Subject: RFR: (testbug) 8217903: java/net/httpclient/Response204.java fails with 404 Message-ID: <7ba2686a-85ab-d147-a102-c2f9fced5a42@oracle.com> Hi, Please find below a test for: 8217903: java/net/httpclient/Response204.java fails with 404 https://bugs.openjdk.java.net/browse/JDK-8217903 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8217903/webrev.00/ This is most certainly a port reuse issue. This test should be using the loopback address but doesn't. best regards, -- daniel From daniel.fuchs at oracle.com Mon Jan 28 18:05:18 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 28 Jan 2019 18:05:18 +0000 Subject: RFR (testbug): 8217882: java/net/httpclient/MaxStreams.java failed once In-Reply-To: <8DDA4637-9195-4A62-91E9-D2C90F586777@oracle.com> References: <8DDA4637-9195-4A62-91E9-D2C90F586777@oracle.com> Message-ID: Thanks Brian. Done. Also added a missing volatile. http://cr.openjdk.java.net/~dfuchs/webrev_8217882/webrev.01 On 28/01/2019 17:45, Brian Burkhalter wrote: > Hi Daniel, > > Perhaps consistently capitalize the first word in each message? > Otherwise OK. > > No need to refresh. > > Thanks, > > Brian > >> On Jan 28, 2019, at 9:42 AM, Daniel Fuchs > > wrote: >> >> Please find below a patch for: >> >> 8217882: java/net/httpclient/MaxStreams.java failed once >> https://bugs.openjdk.java.net/browse/JDK-8217882 >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8217882/webrev.00/ >> >> The patch simply instruments the test with >> some more traces so that we might have a better >> diagnosis next time it fails. > From chris.hegarty at oracle.com Mon Jan 28 18:18:48 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 28 Jan 2019 18:18:48 +0000 Subject: RFR: (testbug) 8217903: java/net/httpclient/Response204.java fails with 404 In-Reply-To: <7ba2686a-85ab-d147-a102-c2f9fced5a42@oracle.com> References: <7ba2686a-85ab-d147-a102-c2f9fced5a42@oracle.com> Message-ID: <4be79393-264d-44eb-d34c-4cd08d5f249a@oracle.com> On 28/01/2019 17:57, Daniel Fuchs wrote: > Hi, > > Please find below a test for: > > 8217903: java/net/httpclient/Response204.java fails with 404 > https://bugs.openjdk.java.net/browse/JDK-8217903 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8217903/webrev.00/ Ship it! -Chris. From ismaelj at gmail.com Tue Jan 29 04:45:31 2019 From: ismaelj at gmail.com (Ismael Juma) Date: Mon, 28 Jan 2019 20:45:31 -0800 Subject: NIO based SocketImpl to replace legacy PlainSocketImpl In-Reply-To: <3225f8f0-08f2-c9bb-6dc4-b7eb7cfc4aa4@oracle.com> References: <3225f8f0-08f2-c9bb-6dc4-b7eb7cfc4aa4@oracle.com> Message-ID: Nice to see this, hope it works out. Ismael On Fri, Jan 25, 2019, 6:11 AM Alan Bateman > I've created a branch in the sandbox, named "niosocketimpl-branch", with > a prototype SocketImpl implementation based on the infrastructure in > sun.nio.ch package that supports the NIO channel implementations. The > branch also includes the changes to java.net.Socket and ServerSocket to > use this SocketImpl by default. > > There are several motivations for this prototype: The existing > PlainSocketImpl is not fit for purpose in the potential future world of > fibers that park instead of blocking carrier threads in syscalls. As I'm > sure most people are on net-dev are aware, PlainSocketImpl is horrible > to maintain due to the complexity of the code paths in its native > methods. Replacing PlainSocketImpl, along with its associates > SocketInputStream and SocketOutputStream, bring other benefits such as > not needing to use the thread stack for I/O and not needing the fd table > data structure to support asynchronous close. > > We have to be a cautious about replacing the PlainSocket/SIS/SOS after > 20 years of service. It is likely that there is behavior in unspecified > areas and corner case scenarios that existing applications or libraries > may depend upon. There is performance work to do but it's possible there > are cases where the performance might degrade, e.g. many years ago there > were attempts to fix a synchronization issue in PlainSocketImpl that > lead to complaints from usages involving hundreds of threads blocking on > ServerSocket::accept. To that end, we are planning to evolve the > prototype to allow the old and new SocketImpls to co-exist, maybe > switched by a system property or some other means. Going there may > require a bit yak shaving, for example in the SOCKS and HTTP proxy > implementations as they need to be re-worked to forward rather than > sub-class. If the prototype goes further then the idea is that both > implementations could be included in the JDK for a few releases before > removing the old code. > > The prototype doesn't have a replacement for PlainDagramSocketImpl at > this time. There are a few issues around how legacy MulticastSocket > behaves that will take a bit of time to sort out. Ideally its > replacement will use the same infrastructure as the DatgramChannel > implementation as that supports modern muilticasting features and is a > lot easier to maintain. > > For now, we (= Michael McMahon and myself for now) will iterate on this > prototype in the sandbox. If we go forward with it then we'll likely > create a JEP. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Tue Jan 29 10:21:34 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 29 Jan 2019 10:21:34 +0000 Subject: NIO based SocketImpl to replace legacy PlainSocketImpl In-Reply-To: References: <3225f8f0-08f2-c9bb-6dc4-b7eb7cfc4aa4@oracle.com>, Message-ID: How will that look like on Windows, will it use IO Completion Ports? I guess scalability becomes much more of an issue with typical thousands of classic sockets. What?s the expected performance of this? The blocking IO had a lot less latency compared to Channels, is there some regression expected or is a goal to also improve latency compared with the classic implementation? Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: net-dev im Auftrag von Ismael Juma Gesendet: Dienstag, Januar 29, 2019 11:05 AM An: Alan Bateman Cc: nio-dev at openjdk.java.net; OpenJDK Network Dev list Betreff: Re: NIO based SocketImpl to replace legacy PlainSocketImpl Nice to see this, hope it works out. Ismael On Fri, Jan 25, 2019, 6:11 AM Alan Bateman wrote: I've created a branch in the sandbox, named "niosocketimpl-branch", with a prototype SocketImpl implementation based on the infrastructure in sun.nio.ch package that supports the NIO channel implementations. The branch also includes the changes to java.net.Socket and ServerSocket to use this SocketImpl by default. There are several motivations for this prototype: The existing PlainSocketImpl is not fit for purpose in the potential future world of fibers that park instead of blocking carrier threads in syscalls. As I'm sure most people are on net-dev are aware, PlainSocketImpl is horrible to maintain due to the complexity of the code paths in its native methods. Replacing PlainSocketImpl, along with its associates SocketInputStream and SocketOutputStream, bring other benefits such as not needing to use the thread stack for I/O and not needing the fd table data structure to support asynchronous close. We have to be a cautious about replacing the PlainSocket/SIS/SOS after 20 years of service. It is likely that there is behavior in unspecified areas and corner case scenarios that existing applications or libraries may depend upon. There is performance work to do but it's possible there are cases where the performance might degrade, e.g. many years ago there were attempts to fix a synchronization issue in PlainSocketImpl that lead to complaints from usages involving hundreds of threads blocking on ServerSocket::accept. To that end, we are planning to evolve the prototype to allow the old and new SocketImpls to co-exist, maybe switched by a system property or some other means. Going there may require a bit yak shaving, for example in the SOCKS and HTTP proxy implementations as they need to be re-worked to forward rather than sub-class. If the prototype goes further then the idea is that both implementations could be included in the JDK for a few releases before removing the old code. The prototype doesn't have a replacement for PlainDagramSocketImpl at this time. There are a few issues around how legacy MulticastSocket behaves that will take a bit of time to sort out. Ideally its replacement will use the same infrastructure as the DatgramChannel implementation as that supports modern muilticasting features and is a lot easier to maintain. For now, we (= Michael McMahon and myself for now) will iterate on this prototype in the sandbox. If we go forward with it then we'll likely create a JEP. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 29 10:48:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Jan 2019 10:48:56 +0000 Subject: NIO based SocketImpl to replace legacy PlainSocketImpl In-Reply-To: References: <3225f8f0-08f2-c9bb-6dc4-b7eb7cfc4aa4@oracle.com> Message-ID: <0c0308de-175f-2f6a-0e9a-df6dfba77ae5@oracle.com> On 29/01/2019 10:21, Bernd Eckenfels wrote: > How will that look like on Windows, will it use IO Completion Ports? I > guess scalability becomes much more of an issue with typical thousands > of classic sockets. > > What?s the expected performance of this? The blocking IO had a lot > less latency compared to Channels, is there some regression expected > or is a goal to also improve latency compared with the classic > implementation? > There's nothing specific to Windows in this. Reading and writing ends up doing WSARecv/WSASend on sockets configured blocking, non-blocking with using timeouts. So no I/O completion ports in the picture, also no channels either. There is a lot of old code using Socket/ServerSocket so we don't want to regress performance. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Jan 29 12:15:21 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 29 Jan 2019 12:15:21 +0000 Subject: RFR [13] 8217976: test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java fails intermittently Message-ID: <2C33AC8F-6272-4027-855C-8F0853D26DE7@oracle.com> WebSocketProxyTest is a new test that was added recently. It fails once in every few hundred runs. The test uses a preexisting test-only proxy server. There is a race when closing the server; the close method iterates over all connections while another thread may be adding a new connection. The solution proposed here is to take a copy of the connection list and iterate over it, rather than the connection list itself. ( I also did a little clean up and added some consistency to proxy debug messages, since it was more difficult to reason about the test's behavior from its log than it should have been ) http://cr.openjdk.java.net/~chegar/8217976/webrev.00/ -Chris. From daniel.fuchs at oracle.com Tue Jan 29 12:31:07 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 29 Jan 2019 12:31:07 +0000 Subject: RFR [13] 8217976: test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java fails intermittently In-Reply-To: <2C33AC8F-6272-4027-855C-8F0853D26DE7@oracle.com> References: <2C33AC8F-6272-4027-855C-8F0853D26DE7@oracle.com> Message-ID: Hi Chris, 116 List localList = List.copyOf(connections); I think it is still possible for CME to happen during the copyOf operation, even though it can reduce the window in which that might happen. The best would be to use CopyOnWriteArrayList instead of synchronizedList(). Otherwise you'd still need to copy the list within a synchronize(connections) { } block to prevent CME. best regards, -- daniel On 29/01/2019 12:15, Chris Hegarty wrote: > WebSocketProxyTest is a new test that was added recently. It fails once > in every few hundred runs. The test uses a preexisting test-only proxy > server. There is a race when closing the server; the close method > iterates over all connections while another thread may be adding a new > connection. The solution proposed here is to take a copy of the > connection list and iterate over it, rather than the connection list > itself. ( I also did a little clean up and added some consistency to > proxy debug messages, since it was more difficult to reason about the > test's behavior from its log than it should have been ) > > http://cr.openjdk.java.net/~chegar/8217976/webrev.00/ > > -Chris. > From chris.hegarty at oracle.com Tue Jan 29 12:53:19 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 29 Jan 2019 12:53:19 +0000 Subject: RFR [13] 8217976: test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java fails intermittently In-Reply-To: References: <2C33AC8F-6272-4027-855C-8F0853D26DE7@oracle.com> Message-ID: <4F27B178-9603-4E3C-B3C9-C881C65CACC7@oracle.com> > On 29 Jan 2019, at 12:31, Daniel Fuchs wrote: > > ... > The best would be to use CopyOnWriteArrayList instead > of synchronizedList(). Otherwise you'd still need to copy the list > within a synchronize(connections) { } block to prevent CME. Agreed. Should be good enough for test cleanup. http://cr.openjdk.java.net/~chegar/8217976/webrev.01/ -Chris. From daniel.fuchs at oracle.com Tue Jan 29 13:03:22 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 29 Jan 2019 13:03:22 +0000 Subject: RFR [13] 8217976: test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java fails intermittently In-Reply-To: <4F27B178-9603-4E3C-B3C9-C881C65CACC7@oracle.com> References: <2C33AC8F-6272-4027-855C-8F0853D26DE7@oracle.com> <4F27B178-9603-4E3C-B3C9-C881C65CACC7@oracle.com> Message-ID: Looks good. While you're at it you could make: 123 CopyOnWriteArrayList connections; final. No need for a new webrev. best regards, -- daniel On 29/01/2019 12:53, Chris Hegarty wrote: > Agreed. Should be good enough for test cleanup. > > http://cr.openjdk.java.net/~chegar/8217976/webrev.01/ > > -Chris. From daniel.fuchs at oracle.com Tue Jan 29 17:31:22 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 29 Jan 2019 17:31:22 +0000 Subject: RFR (testbug): 8216562: UnknownBodyLength sometimes fails due to "Connection reset by peer" Message-ID: <1a6db423-c497-6bee-e014-6006f503c414@oracle.com> Hi, Please find below a fix for: 8216562: UnknownBodyLength sometimes fails due to "Connection reset by peer" https://bugs.openjdk.java.net/browse/JDK-8216562 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8216562/webrev.00/ My previous attempt at at fixing this test proved unsuccessful, as I was still seeing some very infrequent failures - caused by connection reset, with https. The present fix does 3 things: 1. increase the SO_LINGER time, to reduce the risk of generating a reset (1s -> 30s). 2. keep the accepted socket around (server side) until the client finishes - to avoid it to be prematurely gc'ed and its file descriptor released. 3. calls shutdownOutput() - but delay closing the socket until the client finishes. This should also reduce the risk of generating a reset. with this, I haven't been able to reproduce the issue yet. I believe it does fix it - though I'm afraid only time will tell... best regards, -- daniel From chris.hegarty at oracle.com Wed Jan 30 16:25:10 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 30 Jan 2019 16:25:10 +0000 Subject: RFR (testbug): 8216562: UnknownBodyLength sometimes fails due to "Connection reset by peer" In-Reply-To: <1a6db423-c497-6bee-e014-6006f503c414@oracle.com> References: <1a6db423-c497-6bee-e014-6006f503c414@oracle.com> Message-ID: <482ce873-9aab-3b1e-1d92-2ebba93e5780@oracle.com> On 29/01/2019 17:31, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8216562: UnknownBodyLength sometimes fails due to > ???????? "Connection reset by peer" > https://bugs.openjdk.java.net/browse/JDK-8216562 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8216562/webrev.00/ Looks ok, Daniel. -Chris. From daniel.fuchs at oracle.com Thu Jan 31 19:23:45 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 31 Jan 2019 19:23:45 +0000 Subject: RFR (testbug) 8218133: sun/net/www/protocol/http/ProtocolRedirect.java failed with "java.net.ConnectException" Message-ID: <9aa780a7-799d-60d5-aacd-af9105ea994d@oracle.com> 8218133: sun/net/www/protocol/http/ProtocolRedirect.java failed with "java.net.ConnectException" https://bugs.openjdk.java.net/browse/JDK-8218133 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8218133/webrev.00/ Connection refused are usually a symptom of port reuse issue, and using the loopback interface reduces the risk of this happening. The test was also missing some cleanup. best regards, -- daniel From wenboz at google.com Thu Jan 31 23:56:40 2019 From: wenboz at google.com (Wenbo Zhu) Date: Thu, 31 Jan 2019 15:56:40 -0800 Subject: Question about com.sun.net.httpserver.HttpExchange#sendResponseHeaders Message-ID: Per the HTTP spec, chunked encoding may not be needed if "Connection: close" is set and the TCP connection will be closed (FIN) to complete the response body. I am yet to write a test for this but the javadoc needs to address this behavior.. This behavior can be supported using the existing API, e.g. by asking the application to add the Connection header before #sendResponseHeaders is called. === I am adding com.sun.net.httpserver. as a lightweight http/1 server runtime for a framework. The (low-level) com.sun.net APIs are very well documented. Thanks for your work on this library. - Wenbo -------------- next part -------------- An HTML attachment was scrubbed... URL: