Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

Hi Vladimir, On 06/05/2020 00:36, Ivanov, Vladimir A wrote: I was failed to get non-zero value for the ServerSocket and according to clarification from the network experts: " NAPI IDs is not marked on listening sockets. A listening socket can accept multiple connections coming on different que

Re: 8244205: HTTP/2 tunnel connections through proxy may be reused regardless of which proxy is selected

> On 1 May 2020, at 15:38, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > 8244205: HTTP/2 tunnel connections through proxy may be > reused regardless of which proxy is selected > https://bugs.openjdk.java.net/browse/JDK-8244205 > > webrev: > http://cr.openjdk.java.net

Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

Hi, Yes, we've had some discussion about it internally, and while others may yet have an opinion, I think this approach is a reasonable one, with a spec change that captures the behavior. The main thing we need to capture is that while connect() to a non existing resource may fail, getJarFile

RFR 8240666: Websocket client’s OpeningHandshake discards the HTTP response body

  Hello, Request to have my fix reviewed for the issue:     JDK-8240666: Websocket client’s OpeningHandshake discards the HTTP response body. The fix updates jdk.internal.net.http.websocket.OpeningHandshake.send() to process the response body received from server instead of di

Re: RFR 8240666: Websocket client’s OpeningHandshake discards the HTTP response body

An assertion of the form assertEquals(true, ((String)wse.getResponse().body()).contains("404")); looks odd. I'd suggest using any of assertTrue(boolean condition) assertTrue(boolean condition, String message) -Pavel > On 6 May 2020, at 14:12, Rahul wrote: > > http://cr.openjdk.ja

Re: RFR 8240666: Websocket client’s OpeningHandshake discards the HTTP response body

Hi Pavel, Thank you for the comment, the webrev has been updated. webrev : http://cr.openjdk.java.net/~ryadav/webrev_8240666/webrev.00/index.html - rahul On 06/05/2020, 14:26, "Pavel Rappo" wrote: An assertion of the form assertEquals(true, ((String)wse.getResponse().body())

Re: RFR 8240666: Websocket client’s OpeningHandshake discards the HTTP response body

Hi Rahul, LGTM. 111 WebSocketHandshakeException wse = (WebSocketHandshakeException) t; 112 out.println("Status code is " + wse.getResponse().statusCode()); 113 out.println("Response is " + wse.getResponse().body()); 114 asse

Re: RFR 8240666: Websocket client’s OpeningHandshake discards the HTTP response body

> On 6 May 2020, at 16:16, Daniel Fuchs wrote: > > Hi Rahul, > > LGTM. +1 -Chris.

Re: RFR 8240666: Websocket client’s OpeningHandshake discards the HTTP response body

Thanks Daniel , webrev updated. - rahul On 06/05/2020 16:16, Daniel Fuchs wrote: Hi Rahul, LGTM.  111 WebSocketHandshakeException wse = (WebSocketHandshakeException) t;  112 out.println("Status code is " + wse.getResponse().statusCode());  113

Re: RFR 8240666: Websocket client’s OpeningHandshake discards the HTTP response body

On 06/05/2020 16:48, rahul.r.ya...@oracle.com wrote: Thanks Daniel , webrev updated. Looks good! -- daniel

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

Hi Alan, With regards to the SetGetSendBufferSize.java test: yes, it was created to increase the test coverage for the DatagramSocket class. However, it was decided that it should be handled separately and was pushed to the mainline in advance of this RFR - (JDK-8243488

RE: RFR 15 8243099: SO_INCOMING_NAPI_ID support

The socket option SO_INCOMING_NAPI_ID returns the integer value that is associated with the hardware queue of the device the last packet is received on. This is true for UDP Datagram sockets as well. In case the socket is receiving the packets from multiple NIC Devices or the incoming packets of

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

Alan, thank you for the review! New webrev coming. Meanwhile comments inline.. > On May 4, 2020, at 1:49 AM, Alan Bateman wrote: > > On 04/05/2020 06:12, Mikael Vidstedt wrote: >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

Thank you for reviewing, Max! Cheers, Mikael > On May 4, 2020, at 7:22 AM, Weijun Wang wrote: > > There are several security-related files (name.contains("security")) and they > all look fine. > > --Max > > >> On May 4, 2020, at 1:12 PM, Mikael Vidstedt >> wrote: >> >> >> Please revie

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

> On May 4, 2020, at 2:33 PM, Brent Christian > wrote: > > Hi, > > Looks fine to me. I have just one minor observation: > > src/java.base/share/native/libjli/emessages.h > > *** 92,102 > #define JRE_ERROR5 "Error: Failed to start a %d-bit JVM process from a > %d-bit JVM." > !

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

> On May 4, 2020, at 9:27 AM, naoto.s...@oracle.com wrote: > > Hi Mikael, > > I took a look at i18n related files. It looks good overall. > > One nit in java/nio/charset/Charset/DefaultCharsetTest.java: If the test is > only applicable to linux (@requires os.family == "linux" in jtreg tag af

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

I have always wondered what “solinux” is supposed to mean - though not enough to actually ask anybody :) I’ll file a follow-up enhancement to cover renaming the files. Thank you for the review! Cheers, Mikael > On May 4, 2020, at 7:59 AM, Roger Riggs wrote: > > Hi Michael, > > Looks good.

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

> On May 5, 2020, at 5:42 AM, Daniel Fuchs wrote: > > Hi Mikael, > > I spotted another place where a residual reference to Solaris > remains in a comment: > src/java.base/unix/native/libnet/PlainSocketImpl.c > > 857 #if defined(_AIX) > 858 if (errno == EINVAL) { > 859 //

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

New webrev addressing the feedback/comments I have received: webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/corelibs/open/webrev/ incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/corelibs.incr/open/webrev/ I hope I caught everything. Some outstan

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

On 07/05/2020 05:56, Mikael Vidstedt wrote: : * File follow-up enhancement for the removal of SO_FLOW_SA and jdk.net.SocketFlow I've created JDK-8244582 to track this, we should try to this in the same release as JEP 381. : * Get confirmation from Alan that the Socket.setTrafficClass(int)