RE: RFR 15 8243099: SO_INCOMING_NAPI_ID support

Thanks for your comments and questions. > In terms of retrieval, is `0` a valid value for this option? if so then > uninitialized versus initialized states are indistinguishable. > Maybe not be a problem, I dunno yet without further investigation. The zero possible for sockets that not received m

Re: RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

On 01/05/2020 16:53, Patrick Concannon wrote: Hi, I've refactored the test to use the name 'DatagramSocketSupplier' instead of 'DSF' for the @FunctionalInterface, and used the supplier method as Daniel suggested. The updates can be found in the patch below. http://cr.openjdk.java.net/~pcon

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

On 01/05/2020 19:44, Ivanov, Vladimir A wrote: Thanks for your comments. The patch with updated doc available as: http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.06/ I think the javadoc is in good shape now but we do need to address Chris's point that the exception thrown when

RE: RFR 15 8243099: SO_INCOMING_NAPI_ID support

Thanks for your comments. The patch with updated doc available as: http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.06/ Thanks, Vladimir -Original Message- From: Alan Bateman Sent: Friday, May 1, 2020 5:04 AM To: Ivanov, Vladimir A ; OpenJDK Network Dev list Subject:

Re: RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

>> >> .. >> http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.03/ Ship it! -Chris.

Re: RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

Thanks Patrick! Looks good to me! best regards, -- daniel On 01/05/2020 16:53, Patrick Concannon wrote: Hi, I've refactored the test to use the name 'DatagramSocketSupplier' instead of 'DSF' for the @FunctionalInterface, and used the supplier method as Daniel suggested. The updates can b

Re: RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

Hi, I've refactored the test to use the name 'DatagramSocketSupplier' instead of 'DSF' for the @FunctionalInterface, and used the supplier method as Daniel suggested. The updates can be found in the patch below. http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.03/ Kind regards

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

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/~dfuchs/webrev_8244205/webrev.00/index.html If a tunnel connection i

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

On 01/05/2020 14:19, Chris Hegarty wrote: : Has any consideration been given to restricting the set of allowable integer values that may be set for this option - say, to none? Which would then lead to an IllegalArgumentException if `setOption` is invoked in an attempt to set this socket option -

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

> On 30 Apr 2020, at 22:20, Ivanov, Vladimir A > wrote: > > One more update at > http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.05/ > The @apiNote section was updated a little bit to concentrate on > SO_INCOMING_NAPI_ID. I have not seen much discussion relating to possible

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

On 30/04/2020 22:20, Ivanov, Vladimir A wrote: One more update at http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.05/ The @apiNote section was updated a little bit to concentrate on SO_INCOMING_NAPI_ID. I think this is getting better but it switches from "receive queue" to "d

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

Hi, Pinging politely about this issue. I wonder whether it would be appropriate to file a CSR about getJarFile() behaviour change at this point? Concise description of the change is: "So should the getJarFile return be a reference to JarFile for an URL specifying an non existent entry i.e.