Re: RFR[8236105]: Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent

Hi Patrick, DatagramSocket.java: 694 * is not set. this line needs to be removed. Otherwise this looks good to me. A release note might get requested by the CSR lead. best regards, -- daniel On 13/01/2020 16:30, Patrick Concannon wrote: Hi, Could someone please review m

Re: RFR[8237571]: java/net/DatagramSocket/SendCheck.java is failing on Solaris

Looks good to me Patrick! Thanks for jumping on this. best regards, -- daniel On 21/01/2020 10:07, Patrick Concannon wrote: Hi, Could someone please review my fix for issue JDK-8237571 'java/net/DatagramSocket/SendCheck.java is failing on Solaris' ? A test case in java/net/DatagramSocket/

8236596: HttpClient leaves HTTP/2 sockets in CLOSE_WAIT, when using proxy tunnel

Hi, Please find below a fix for: 8236596: HttpClient leaves HTTP/2 sockets in CLOSE_WAIT, when using proxy tunnel https://bugs.openjdk.java.net/browse/JDK-8236596 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8236596/webrev.00/ The issue seems to appear when the client is garbage

Re: RFR[7021373]: DatagramPacket exception conditions are not clear

Hi Alan, On 24/01/2020 11:41, Alan Bateman wrote: CSR: https://bugs.openjdk.java.net/browse/JDK-8237774 webrev: http://cr.openjdk.java.net/~pconcannon/7021373/webrevs/webrev.00/ I just skimmed over this (not a complete review) but getSocketAddress() throwing IllegalArgumentException doesn't str

Re: RFR [15] 8237817: Clean up net-properties.html

Hi Pavel, That looks good to me. Thanks for improving this file! I didn't know that javadoc tags could be used in plain HTML files. Maybe another pair of eyes would be good. best regards, -- daniel On 24/01/2020 12:31, Pavel Rappo wrote: Hello, Please review the following change for https:

8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting.

Hi, Please find below a doc-only fix for: 8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting. https://bugs.openjdk.java.net/browse/JDK-8237896 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8237896/webrev.00/ best regards, -- daniel

Re: 8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting.

Hi Alan, On 27/01/2020 19:30, Alan Bateman wrote: webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8237896/webrev.00/ The API note for the class description looks good. I'm less sure about the API notes added ot the joinGroup method because you can't get a MulticastChannel from a MulticastSo

Re: 8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting.

Hi Alan. Alright. I've transformed the second note in an @see: http://cr.openjdk.java.net/~dfuchs/webrev_8237896/webrev.02/ best regards, -- daniel On 29/01/2020 08:20, Alan Bateman wrote: If someone has a MulticastSocket then they can't get to a DatagramChannel to use the alternative join m

8238231: Custom DatagramSocketImpl's create method not called when with protected constructor

Hi, Please find below a fix for: 8238231: Custom DatagramSocketImpl's create method not called when with protected constructor https://bugs.openjdk.java.net/browse/JDK-8238231 This is a behavioral regression introduced by JDK-8236925 [1]. Thanks Alan for providing a suggested fix. I ha

Re: 8238231: Custom DatagramSocketImpl's create method not called when with protected constructor

Hi Alan! On 31/01/2020 17:10, Alan Bateman wrote: On 31/01/2020 16:46, Daniel Fuchs wrote: http://cr.openjdk.java.net/~dfuchs/webrev_8238231/webrev.00/ This seems to have a few problems. Consider two threads calling getImpl() at around the same time. This can only work if "create

Re: 8238231: Custom DatagramSocketImpl's create method not called when with protected constructor

On 31/01/2020 17:47, Alan Bateman wrote: On 31/01/2020 17:30, Daniel Fuchs wrote: http://cr.openjdk.java.net/~dfuchs/webrev_8238231/webrev.01 This has the same bug as it reads "created" outside of the synchronized block. If you change it to volatile then it will fix that issue.

Re: 8238231: Custom DatagramSocketImpl's create method not called when with protected constructor

On 31/01/2020 20:45, Alan Bateman wrote: On 31/01/2020 19:42, Daniel Fuchs wrote: Good, this version is correct. I see that getImpl() is synchronizing on "this". I guess that is okay but synchronizing on the impl is another choice here. Yes. Well I syncronized on `this` because oth

Re: RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version

Hi John, Looks good to me. Thanks for taking care of this! I'm glad to see the binary files go away :-) Would it be possible to include a comment in Cert.java that contains the command you used to generate the certificates? That will be a great help to future maintainers if the certificates eve

Re: RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version

On 08/02/2020 07:46, sha.ji...@oracle.com wrote: Hi Daniel, I'll do that. Please review this updated webrev: http://cr.openjdk.java.net/~jjiang/8238677/webrev.01/ The script, exactly gen-certs.sh, can be used to generate the certs. Looks good to me John! best regards, -- daniel

Re: RFR[15] JDK-8234718: java/net/httpclient tests should cover TLSv1.3

Hi John, This looks good to me. Thanks for taking care of that and for logging JDK-8238990! best regards, -- daniel On 13/02/2020 05:23, sha.ji...@oracle.com wrote: Hi, java/net/httpclient/HandshakeFailureTest.java should cover TLSv1.3 as well. java/net/httpclient/ShortResponseBody.java would

Re: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with proxy

Hi, On 13/02/2020 10:52, Ravi Reddy wrote: I notice that the `break` from the original code has not been reintroduced. I don't think that it is strictly needed, but did you give it any consideration? Chris , in original code since we were doing retry with direct connection and not proceeding

Re: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with proxy

Thanks Vyom. I was suspecting as much. Ravi, could you come up with a test that fails without the fix and pass with it? best regards, -- daniel On 13/02/2020 14:26, Vyom Tiwari wrote: Hi Ravi/Daniel, At my local env(REL 7) test is passing without fix as well. Although my local repo contai

Re: RFR[15] JDK-8239025: ProblemList java/net/httpclient/HandshakeFailureTest.java due to JDK-8238990

+1 I thought I had a possible fix for this test, but unfortunately I couldn't manage to push it yesterday. I still need a bit of time to experiment with several options. best regards, -- daniel On 13/02/2020 23:06, sha.ji...@oracle.com wrote: Hi, java/net/httpclient/HandshakeFailureTest.java

Re: RFR[8237480]: Add micros for DatagramSocket send/receive

Looks good to me too. best regards, -- daniel On 14/02/2020 11:57, Patrick Concannon wrote: Hi, With further discussion on this benchmark test with Claes off-list, I've updated the code to use more descriptive names. The updated webrev can be found below. http://cr.openjdk.java.net/~pconc

Re: RFR 8238579: HttpsURLConnection drops the timeout and hangs forever in read

Hi Vyom, On the surface, your patch seems reasonable. I would be more confident if there was a test, but I understand it might well be one of these noreg-hard issues. I've put it on my TODO list to import your patch and try to test it in our test system. I'll get back to you when I have managed

8238990: java/net/httpclient/HandshakeFailureTest.java failed against TLSv1.3 on Windows

Hi, Please find below a fix for: 8238990: java/net/httpclient/HandshakeFailureTest.java failed against TLSv1.3 on Windows https://bugs.openjdk.java.net/browse/JDK-8238990 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8238990/webrev.00/ The issue here is that we get a race conditio

8239052: java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java failed with BufferUnderflowException against TLSv1.3

Hi, Please find below a test fix for: 8239052: java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java failed with BufferUnderflowException against TLSv1.3 https://bugs.openjdk.java.net/browse/JDK-8239052 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8239052/webrev.00/ The test th

Re: 8239052: java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java failed with BufferUnderflowException against TLSv1.3

a specific TLS protocol, this configuration could be removed. The default TLS protocol, exactly TLSv1.3 now, will be applied. Best regards, John Jiang On 2020/2/21 18:01, Daniel Fuchs wrote: Hi, Please find below a test fix for: 8239052: java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java  

Re: 8239052: java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java failed with BufferUnderflowException against TLSv1.3

Thanks Chris! I was going to answer that this was not possible as it requires multiple return values but I found a way: http://cr.openjdk.java.net/~dfuchs/webrev_8239052/webrev.02/ best regards, -- daniel On 22/02/2020 13:53, Chris Hegarty wrote: On 21 Feb 2020, at 17:41, Daniel Fuchs

Re: RFR 8238579: HttpsURLConnection drops the timeout and hangs forever in read

Hi Vyom, I tried out your patch and got no suspicious failures so you have my review :-) best regards, -- daniel On 15/02/2020 04:14, Vyom Tewari26 wrote: I'll get back to you when I have managed to find some cycles to do so. best regards, -- daniel On 14/02/2020 04:57, Vyom Tiwari wrote:

(solaris) 8059309: network tests fail with "java.net.SocketException: Couldn't obtain phys addr" when run as "root"

Hi, Please find below a fix for: 8059309: network tests fail with "java.net.SocketException: Couldn't obtain phys addr" when run as "root" https://bugs.openjdk.java.net/browse/JDK-8059309 http://cr.openjdk.java.net/~dfuchs/webrev_8059309/webrev.00/ Recent reports have shown that the f

Re: (solaris) 8059309: network tests fail with "java.net.SocketException: Couldn't obtain phys addr" when run as "root"

back interface is being queried or not - I believe that return 0 when the query is not supported is the right thing to do here. best regards, -- daniel -- http://bernd.eckenfels.net -------- *Von:* net-dev im Auftrag von Daniel F

Re: (solaris) 8059309: network tests fail with "java.net.SocketException: Couldn't obtain phys addr" when run as "root"

Hi Alan, On 29/02/2020 07:54, Alan Bateman wrote: On 28/02/2020 22:06, Bernd Eckenfels wrote: I'm also curious if there are any platforms or configurations where the loopback has a hardware address. Mostly wondering if this should be short circuited to consistently return null (I would expect

Re: RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with proxy

HttpURLConWithProxy test fails without the fix. Webrev: http://cr.openjdk.java.net/~pkoppula/8183369/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8183369 Thanks, Ravi -Original Message- From: Ravi Reddy Sent: Thursday, February 13, 2020 10:10 PM To: Daniel Fuchs ; Vyom Tiwari

Re: (solaris) 8059309: network tests fail with "java.net.SocketException: Couldn't obtain phys addr" when run as "root"

Hi Bernd, On 02/03/2020 20:44, Bernd Eckenfels wrote: However the question is, if other conditions (address families for tunnels, x.25 etc) than loopback can also trigger this unsupported case - but would actually return something in the fallback. So maybe for compatibility trying the fallback

8240754: Instrument FlowTest.java to provide more debug traces.

Hi, Please find below a changeset that adds some more debugging output to FlowTest.java for better test failure diagnosis. 8240754: Instrument FlowTest.java to provide more debug traces. https://bugs.openjdk.java.net/browse/JDK-8240754 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8240754/w

Re: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)'

Hi Alan, On 09/03/2020 17:01, Alan Bateman wrote: On 09/03/2020 12:39, Patrick Concannon wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8239355 webrev: http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.00/index.html This is a change to the DatagramChannel implementation. I

Re: RFR[15] JDK-8238740: java/net/httpclient/whitebox/FlowTestDriver.java would not specify a TLS protocol

Hi John, Looks good to me. best regards, -- daniel On 02/03/2020 08:08, sha.ji...@oracle.com wrote: Hi, java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java would not use a specific TLS protocol, instead just use the default TLS protocol, exactly TLSv1.3 now. dif

Re: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR incorrectly

Hi Vyom, I have sent your proposed fix to our test system and observed no regression. I agree your proposed changes seem to address the issue adequately. However, I'd like to hear a second opinion on the possible side effects of this fix, since NET_Timeout may be called at many other places. I s

Re: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR incorrectly

osted the patch to cr.openjdk.net(http://cr.openjdk.java.net/~vtewari/8237858/webrev/index.html). Thanks, Vyom - Original message - From: Daniel Fuchs To: Vyom Tewari26 , net-dev@openjdk.java.net Cc: Subject: [EXTERNAL] Re: RFR 8237858: PlainSocketImpl.socketAccept()

Re: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)'

Hi Alan, On 10/03/2020 19:59, Alan Bateman wrote: On 10/03/2020 18:32, Patrick Concannon wrote: http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.02 Thanks for adding a test for getOption(SO_SNDBUF). That test (testGetOption) should be checking that SO_SNDBUF is >= expected value

Re: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)'

Hi Alan, On 11/03/2020 12:08, Alan Bateman wrote: Do we really? I am not sure we do. We just want to verify that we don't get the "packet too large" exception caused by the SO_SNDBUF buffer being too small. It would be great if we had a test to send large datagrams on the network as that is the

Re: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)'

On 11/03/2020 16:54, Patrick Concannon wrote: http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.03/ Looks good to me Patrick! best regards, -- daniel

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

Hi Julia, I think we need to revisit the public static FilePublisher create(Path path) a bit. We should try to call Path::toFile first - whether there is a security manager or not. In the case where that succeeds, we can use new FileInputStream(), otherwise, we use Files.newInputStream. It's

Re: RFR JDK-8241039, Retire the deprecated SSLSession.getPeerCertificateChain() method

Hi Xuelei, HandshakeCompletedEvent.java: typo: 186 "This method has retired, pleaase use the " + Same in SSLSession.java: 303 "This method has retired, pleaase use the " + WRT to the HttpClient code I wonder whether the deprecated method should be kept. On the on

Re: RFR: JDK-8241138: http.nonProxyHosts=* causes StringIndexOutOfBoundsException in DefaultProxySelector

Hi Jaikiran, This looks reasonable to me. I will happily sponsor it - unless there are other takers. best regards, -- daniel On 18/03/2020 11:18, Jaikiran Pai wrote: Can I please get a review and a sponsor for a patch which fixes the issue reported in JDK-8241138[1]? The patch is hosted as a

Re: RFR JDK-8240921: Minor correction to HttpResponse.BodySubscribers example

Hi Rahul, This looks good to me. Thanks for fixing it! best regards, -- daniel On 19/03/2020 10:29, rahul.r.ya...@oracle.com wrote: Hello,  Can I please have my fix reviewed for issue JDK-8240921 - Minor correction to HttpResponse.BodySubscribers example?  The fix updates the incorrect

Re: [14-dev] RFR : (dc) MulticastSendReceiveTests.java failing with ENOMEM when joining group (OS X 10.9)

Hi Ivan, Looks good to me. I wonder if you should add @bug 8044365 to the MulticastSendReceiveTests.java while you're at it. best regards, -- daniel On 20/03/2020 07:19, Ivan Gerasimov wrote: Hello! An OOM error is intermittently observed on MacOS when joining a multicast group. A workaro

8241443: Problem list some java.net tests failing with NoRouteToHostException on macOS with special network configuration

Hi, Please find below a changeset for: 8241443: Problem list some java.net tests failing with NoRouteToHostException on macOS with special network configuration We are observing some net/nio tests failing on some of our mac machines. While we investigate the issue we would lik

Re: 8241443: Problem list some java.net tests failing with NoRouteToHostException on macOS with special network configuration

hanks Alan! I'll reorder before pushing. -- daniel -Alan On 23/03/2020 13:22, Daniel Fuchs wrote: Hi, Please find below a changeset for: 8241443: Problem list some java.net tests failing with NoRouteToHostException on macOS with special network configuration We are

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

Hi Julia, * @run testng/othervm/java.security.policy=FilePublisherPermsTest1.policy Does this actually work as expected? I thought the syntax was: @run testng/othervm/policy= And FWIW there some subtlety with othervm/policy= versus othervm/policy== and I never remember which one should be

Re: RFR: 8235459: HttpRequest.BodyPublishers#ofFile(Path) assumes the default file system

OK, thanks for double checking Julia. Looks good to me then! best regards, -- daniel On 24/03/2020 16:33, Julia Boes wrote: Hi Daniel, * @run testng/othervm/java.security.policy=FilePublisherPermsTest1.policy Does this actually work as expected? I thought the syntax was: @run testng/other

Re: 8241674 (XS): Fix incorrect jtreg option in FilePublisherPermsTest

Thanks for jumping on this Julia! Reviewed. Since this is making some noise in the CI I suggest to push it asap. best regards, -- daniel On 26/03/2020 14:32, Julia Boes wrote: Hi, Could someone please review this small fix of a recently pushed test? The option to extend the policy file has

8241336: Some java.net tests failed with NoRouteToHostException on MacOS with special network configuration

Hi, Please find below a fix for: 8241336: Some java.net tests failed with NoRouteToHostException on MacOS with special network configuration https://bugs.openjdk.java.net/browse/JDK-8241336 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.01/index.html The crux of the i

Re: 8241336: Some java.net tests failed with NoRouteToHostException on MacOS with special network configuration

Hi Alan. On 26/03/2020 17:29, Alan Bateman wrote: NetworkConfiguration.isTestable - is the hardcoded check for "awdl" needed? I don't think I've seen it with non-link local address so I can't tell if it is needed. I'm It might no longer be needed, but we know that awdl is always the wrong cho

Re: 8241336: Some java.net tests failed with NoRouteToHostException on MacOS with special network configuration

Hi Alan, On 27/03/2020 09:06, Alan Bateman wrote: http://cr.openjdk.java.net/~dfuchs/webrev_8241336/webrev.02/ This mostly looks good except that I'd prefer if the the code in assertNotSame be moved into testSendNoReceive (it was an oversight in the original test that testSendNoReceive didn't

Re: [15] RFR 8241760 : Typos: empty lines in javadoc, inconsistent indents, etc. (net and nio)

Looks good to me Ivan. Thanks for this cleanup! best regards, -- daniel On 30/03/2020 03:34, Ivan Gerasimov wrote: Thank you Alan and Pavel! My apologies for a wrong link in the initial request. Here's the new webrev with the changes suggested by Pavel: http://cr.openjdk.java.net/~igerasi

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

This looks good to me Patrick. I'm happy to see that all implementations now have a consistent and predictable behavior. Also - as Alan noted - this is not really a behavioral change as some subclass of IOException (or IOException itself) was already thrown before. +1 best regards, -- daniel

Re: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

Looks good to me Chris! best regards, -- daniel On 01/04/2020 16:04, Chris Hegarty wrote: On 1 Apr 2020, at 15:12, mark sheppard > wrote: Hi Chris,       just looking at the supportedOptions method in the two classes DatagramSocket and MulticastSocket, if I ha

8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Hi, Please find below a fix for: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available" https://bugs.openjdk.java.net/browse/JDK-8241786 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.01/ The real fix is

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Hi Alan, On 01/04/2020 20:50, Alan Bateman wrote: The change to java.net.DefaultInterface to workaround bad configurations on macOS looks good. Hopefully existing usages of the 1-arg joinGroup will migrate to the 2-arg variant and avoid needing the JDK to choose on multi-homed systems. Thank

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Hi Chris, On 02/04/2020 09:40, Chris Hegarty wrote: This is a functional change that affects the product build. Maybe that would be a little clearer from a different bug synopsis. Suggest something like: Improve heuristic to determine default network interface on macOS I can do that - or I

Re: RFR [15] 8242044: Add basic HTTP/1.1 support to the HTTP/2 Test Server

Looks good to me Chris. best regards, -- daniel On 02/04/2020 15:11, Chris Hegarty wrote: To more easily write HTTP Client test scenarios for different protocol versions and different TLS versions, it would be very convenient if the HTTP/2 server, that is part of the JDK regression test suite,

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Hi Alan, Hopefully that's fixed now. Only change is in AdaptorMulticasting.java http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.03 best regards, -- daniel On 02/04/2020 09:56, Alan Bateman wrote: All I'm asking is that additional tracing being consistent with the existing traces. St

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/

 <http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/> Kind regards, Patrick On 31/03/2020 15:33, Chris Hegarty wrote: Patrick, On 31 Mar 2020, at 15:08, Daniel Fuchs wrote: .. bug:https://bugs.openjdk.java.

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

Looks good to me Patrick! best regards, -- daniel On 04/04/2020 16:26, Patrick Concannon wrote: Hi Chris and Daniel, Well spotted, Chris. Thanks for that! Thanks too Daniel, that's a good idea. I've made those changes and included them in a new webrev, which you can find below. http://cr

Re: Need sponsor to fix Javadoc warnings

Hi Pavel, On 08/04/2020 13:56, David Holmes wrote: and `@exception` tags for checked exceptions that were neither thrown nor imported Hopefully that's only on internal classes. It might be prudent to separate this out in a different changeset. It's not always obvious where an exception is thro

Re: Need sponsor to fix Javadoc warnings

On 08/04/2020 12:50, Pavel Rappo wrote: Vipin, here you go: https://bugs.openjdk.java.net/browse/JDK-8242366 http://cr.openjdk.java.net/~prappo/8242366/webrev.00/ Hi Pavel, That looks good to me. WRT to the @exception changes I'll leave that responsibility to Sean ;-) best regards,

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

Good work Rahul! I am not sure whether that deserves a CSR (probably not) but we may want to create some release note to explain that the HttpClient is no longer overriding the default protocols selected by the SSLContext. So HTTP 1.1 over TLSv1.1 might now get negotiated where previously an han

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

Thanks Rahul. I believe you can mark it as Delivered now. On 09/04/2020 14:13, Rahul wrote: Thanks for the review Daniel. I have created a release note. RN :https://bugs.openjdk.java.net/browse/JDK-8242387

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

Hi Alan, On 12/04/2020 16:51, Alan Bateman wrote: I don't think SetGetSendBufferSize should be in the webrev. It has @bug 8239355 so it's for a different issue. Patrick will confirm but IIRC this test was added because coverage testing reported that DS::setSendBufferSize was never called (pres

Re: 8241995: Clarify InetSocketAddress::toString specification

On 14/04/2020 15:00, Michael McMahon wrote: Hi Chris,     possible wording for your last paragraph: To retrieve a string representation of the hostname, or in the absence of a hostname, the string form of the address, use {@link #getHostString()}, rather than parsing the toString string represen

8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

Hi, Please find below a fix for: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response https://bugs.openjdk.java.net/browse/JDK-8238270 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.00/index.html For convenience reason, the Http2C

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

On 15/04/2020 17:40, Chris Hegarty wrote: The new test is good, but has an unnecessary reference to AbstractThrowingSubscribers.TestExecutor. Good catch. I'll send a new webrev after I have received further feedback. (or in a couple of days if none are forthcoming :-) ) -- daniel

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

Hi Chris, On 15/04/2020 17:40, Chris Hegarty wrote: It is allowable for a HEADERS frame to carry an END_STREAM, but not an END_HEADERS. If this happens, then CONTINUATION frames must follow, the last of which will carry END_HEADERS. That probably explains why the END_STREAM handling is done the

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

Argh! On 15/04/2020 19:46, Chris Hegarty wrote: From section 6.2 - HEADERS: END_STREAM (0x1): When set, bit 0 indicates that the header block (Section 4.3 ) is the last that the endpoint will send for the identified stream.

Re: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'

Thanks Patrick. Looks good me. best regards, -- daniel On 16/04/2020 14:39, Patrick Concannon wrote: Hi Chris, Thanks for that. I've added the new testcases as requested, and you can find them in the new webrev below. http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.02/ Ki

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

Hi Chris, The fix ensures that any pending data frame will still be processed after 204 has been received - thus triggering the logic that eventually closes the stream. I suppose that a 204 response MUST have an END_STREAM in its final HEADERS / CONTINUATION frame, right? I have rescanned th

Re: RFR[8243408]: 'Inconsistent Exceptions are thrown by MulticastSocket when sending a DatagramPacket to port 0'

Thanks Patrick! LGTM. best regards, -- daniel On 22/04/2020 20:18, Patrick Concannon wrote: Hi, Could someone please review my fix for JDK-8243408 'Inconsistent Exceptions are thrown by MulticastSocket when sending a DatagramPacket to port 0'? Currently, MulticastSocket.send(DatagramPack

8243246: HTTP Client sometimes gets java.io.IOException -> Invalid chunk header byte 32

Hi, Please find below a fix for: 8243246: HTTP Client sometimes gets java.io.IOException -> Invalid chunk header byte 32 https://bugs.openjdk.java.net/browse/JDK-8243246 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8243246/webrev.00/ Some websites add extraneous white space after

Re: 8243246: HTTP Client sometimes gets java.io.IOException -> Invalid chunk header byte 32

Hi Alan, On 24/04/2020 07:09, Alan Bateman wrote: It looks like there are >3000 lines of embedded data, is a reason why these responses can't be loaded from data files? Some of these could be text blocks too of course but they are really long and might be better as data files. I originally h

Re: 8243246: HTTP Client sometimes gets java.io.IOException -> Invalid chunk header byte 32

Hi Chris, On 23/04/2020 19:36, Chris Hegarty wrote: How do you feel about adding a byte-at-a-time final scenario? static final List REQ5_RESPONSE_BODY = List.of( "B", " ", "\r", "\n", "L", "o", "r", "e", "m", " ", "i", "p", "s", "u", "m", "\r" ,"\n", "0", ";", " ", "\

Re: RFR 8242999: http/2 client may not handle continuation frames correctly

Hi Rahul, That looks very good! Thanks for taking that on. Not related to your fix, but could you update the code that creates the HttpClient to explicitly require no proxy? I suggest to update: 166 client = HttpClient.newBuilder().sslContext(sslContext).build(); to:

Re: RFR 8242999: http/2 client may not handle continuation frames correctly

On 27/04/2020 14:04, Rahul wrote: Thanks for the review comments. I have updated the webrev : http://cr.openjdk.java.net/~pconcannon/rayayada/8242999/webrevs/webrev.01/ Thanks Rahul! LGTM. -- daniel

Re: RFR[8243507]: 'DatagramSocket constructors don’t always specify what happens when passed invalid parameters'

Hi Patrick, Looks good to me. I realize we haven't specified what happens if the `laddr` is null. Are you planning to fix that in a separate changeset or tag it to this one? Maybe we should unify the description of the `port` parameter in the two constructors: 327 * @param port port

Re: RFR[8243507]: 'DatagramSocket constructors don’t always specify what happens when passed invalid parameters'

On 29/04/2020 21:08, Patrick Concannon wrote: webrev: http://cr.openjdk.java.net/~pconcannon/8243507/webrevs/webrev.01/ Thanks Patrick. LGTM. Pedantically, this test might temporarily leak instances of DatagramSocket when it detects a bug. That is, for instance - in the case where `new Datagra

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

Hi Alan, On 30/04/2020 11:48, Alan Bateman wrote: http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.02/ Another approach would be replace DSF with a simple supplier like this:     @FunctionalInterface     interface DatagramSocketSupplier {     DatagramSocket get() throws I

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

On 30/04/2020 12:24, Alan Bateman wrote: It's a naming issue mostly. If DSF is renamed to something like DatagramSocketSupplier then it might be a bit clearer. We have something similar in PrintSupportedOptions - I was reminded of that with the changes for ADQ that are currently under discussio

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[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: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

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 // On Solaris setsockopt will set errno to EINVAL if the socket 860

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: 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 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, On 07/05/2020 07:59, Alan Bateman wrote: I'd prefer to see JDK-8242885 fixed and SetGetSendBufferSize/testInitialSendBufferSize updated to test a maximally sized IPv6 packet (we should probably have done that in advance of the JEP). OK - let's remove the SendBufCheck before pushing.

8244031: HttpClient should have more tests for HEAD requests

Hi, Please find a fix for: 8244031: HttpClient should have more tests for HEAD requests https://bugs.openjdk.java.net/browse/JDK-8244031 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8244031/webrev.00/ The test was developed while investigating https://bugs.openjdk.java.net/browse/JDK-8243

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

Hi Alex, On 08/05/2020 15:35, Alex Kashchenko wrote: On 05/06/2020 01:11 PM, Michael McMahon wrote: 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. I'

Re: RFR 8244652: Add test for non utf-8 response handling by websocket client

Hi Rahul, That looks good to me thanks! I am still teetering on whether we should also have altered the specification of WSHandshakeException, and explicitly changed the signature of WSHandshakeException::getResponse to return an HttpResponse instead of an HttpResponse. On the one hand - our im

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

Hi Vladimir, Patrick, The new tests look very good. There's just a small issue I noticed. It's present in all the new tests - here is an example on AsynchronousSocketChannelNAPITest.java: This code in @BeforeTest: 63 try (var s = AsynchronousSocketChannel.open()) { 64

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

Thanks Vladimir! The tests look good to me now. best regards, -- daniel On 14/05/2020 22:50, Ivanov, Vladimir A wrote: Thanks a lot Daniel! I missed these double checks. Updated webrev may be reviewed ashttp://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.14 I use only one cond

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

Hi Vladimir, On 14/05/2020 22:50, Ivanov, Vladimir A wrote: Thanks a lot Daniel! I missed these double checks. Updated webrev may be reviewed as http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.14 I use only one condition for the 'if' in the 'startup' method while kernel shoul

Re: [JBS] {Updated} (JDK-8245517) java/net/SocketOption/AfterClose.java fails with Invalid value 'READ_ONLY'

Hi Vladimir, The changes look good to me. I imported your patch and sent it to our test systems. Please wait until I report back that all is clear before pushing. best regards, -- daniel On 21/05/2020 19:10, Ivanov, Vladimir A wrote: Hello everyone, seems, the test java/net/SocketOption/Afte

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

Hi Vladimir, That looks good. Give me time to send that to our test system and I'll report back. best regards, -- daniel On 21/05/2020 18:07, Ivanov, Vladimir A wrote: Thanks Daniel, the exception was updated. Could you please review: Bug ID:https://bugs.openjdk.java.net/browse/JDK-8245569 We

Re: RFR [15] 8241378: j.net.URLConnection::getHeaderFieldKey(int) behavior does not reliably conform to its specification

Hi Michael, This looks good to me. best regards, -- daniel On 22/05/2020 09:36, Michael McMahon wrote: Hi, Could I get the following small spec clarification reviewed please? Bug: https://bugs.openjdk.java.net/browse/JDK-8241378 CSR: https://bugs.openjdk.java.net/browse/JDK-8245582 Webrev

Re: RFR 8241389: URLConnection::getHeaderFields returns result inconsistent with getHeaderField/Key for FileURLConnection, FtpURLConnection

Hi Michael, Two comments: URLConnection.java: 1. I don't think getHeaderFields() should return null, but an empty map instead. 122 return null; should probably return super.getHeaderFields(); instead. 2. Other methods in this class seem to assume that `properties` c

<    1   2   3   4   5   6   7   8   9   10   >