From Nikola.Grcevski at microsoft.com Tue Aug 4 15:36:16 2020 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Tue, 4 Aug 2020 15:36:16 +0000 Subject: RFR(s): Improving performance of Windows socket connect on the loopback adapter In-Reply-To: <7a6cfe16-e126-4ef3-d22a-bcd7c0a18b8f@oracle.com> References: <6753161d-6879-3727-4824-ba10a5d68a37@oracle.com> <4e7c31b3-e8c4-7bc1-341c-927fc8292a8d@oracle.com> <05a54b93-0475-99a3-6b86-d41173806504@oracle.com> <628cac66-4872-4821-3a29-f8c25b1666f6@oracle.com> <7a6cfe16-e126-4ef3-d22a-bcd7c0a18b8f@oracle.com> Message-ID: Hi Alan, > What cheap is VerifyVersionInfoW? The check is done everytime but the overhead might be in the noise. Overall it looks good to me. I wrote a small benchmark to measure the overhead of the version check (attached below). On my SurfaceBook 2 running Windows 10 Build 19041, the version check measures about ~2.2us (micro seconds) on average, when the version matches. Elapsed time 2244us. (for 1,000 iterations) On a Windows 2016 Data Center Server the version check is much smaller ~0.13us (micro seconds) on average, when the version doesn't match. Elapsed time 128us. (for 1,000 iterations) I think the overhead is reasonably small compared to everything else. Please let me know if it's acceptable and if we can proceed. Thanks, Nikola Benchmark program: int main() { LARGE_INTEGER start_time, end_time, elapsed_us; LARGE_INTEGER frequency; QueryPerformanceFrequency(&frequency); QueryPerformanceCounter(&start_time); int count = 0; for (int i = 0; i < 1000; i++) { count += IsWindows10RS3OrGreater(); } QueryPerformanceCounter(&end_time); elapsed_us.QuadPart = end_time.QuadPart - start_time.QuadPart; elapsed_us.QuadPart *= 1000000; elapsed_us.QuadPart /= frequency.QuadPart; printf("Elapsed time %lldus.\n", elapsed_us.QuadPart); } -----Original Message----- From: Alan Bateman Sent: July 31, 2020 1:29 PM To: Nikola Grcevski ; net-dev at openjdk.java.net Subject: Re: RFR(s): Improving performance of Windows socket connect on the loopback adapter On 28/07/2020 15:03, Nikola Grcevski wrote: > Hi Alan, > > Thanks again for testing this change. I dug deep into the issue yesterday and got some answers from the Windows Networking team. > > The issue is that the flag TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS, which we passed in to completely eliminate the network delay, isn't defined (or checked) on Windows 10 versions prior to RS3 (Redstone 3). The flag was interpreted as TCP_INITIAL_RTO_DEFAULT_MAX_SYN_RETRANSMISSIONS, causing a retry of 255 times, each one taking 500ms. This made each individual connect delay take 128 seconds in total. > > I was advised to change the code to perform a runtime check on the exact Windows version and unless it's Windows 10RS3 or later, we should set the retransmissions to 1. Strangely enough, we can't set it to 0, which is a special value interpreted as use the default. With retransmission count of 1, we speed up the localhost connects on older versions of Windows by factor of 2. > > I have prepared a new webrev with the runtime check for review here: > http://cr.openjdk.java.net/~adityam/nikola/fast_connect_loopback_4/ > > For the Windows version check function I followed the naming standards the SDK uses in: > https://docs.microsoft.com/en-us/windows/win32/api/versionhelpers/ > > If it's not a suitable function name please let me know. They have added this helper function for .NET 4.8 but it's not there yet for Win32. Hopefully, it comes provided by Microsoft in a future SDK update and we can remove the helper. I attempted to use IsWindowsVersionOrGreater, but unfortunately that API doesn't allow me to specify the build number to detect RS3. > What cheap is VerifyVersionInfoW? The check is done everytime but the overhead might be in the noise. Overall it looks good to me. -Alan From patrick.concannon at oracle.com Thu Aug 6 12:29:14 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Thu, 6 Aug 2020 13:29:14 +0100 Subject: RFR[8250886]: java/net/DatagramSocket/SendReceiveMaxSize.java fails in timeout Message-ID: <1D480B63-7894-44D8-B2E2-ABD66E3E1012@oracle.com> Hi, Could someone please review my fix for JDK-8250886 ? ?java/net/DatagramSocket/SendReceiveMaxSize.java fails in timeout? ? The default value of SO_RCVBUF is much larger than the SO_SNDBUF limit so it no longer needs to be set to match it. This mismatch caused the corresponding test 'java/net/DatagramSocket/SendReceiveMaxSize.java` to fail. The proposed fix is to leave SO_RCVBUF as configured by default by the kernel. issue: https://bugs.openjdk.java.net/browse/JDK-8250886 webrev: http://cr.openjdk.java.net/~pconcannon/8250886/webrevs/webrev.00/ Kind regards, Patrick From Alan.Bateman at oracle.com Thu Aug 6 12:41:17 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Aug 2020 13:41:17 +0100 Subject: RFR[8250886]: java/net/DatagramSocket/SendReceiveMaxSize.java fails in timeout In-Reply-To: <1D480B63-7894-44D8-B2E2-ABD66E3E1012@oracle.com> References: <1D480B63-7894-44D8-B2E2-ABD66E3E1012@oracle.com> Message-ID: On 06/08/2020 13:29, Patrick Concannon wrote: > Hi, > > Could someone please review my fix for JDK-8250886 ? ?java/net/DatagramSocket/SendReceiveMaxSize.java fails in timeout? ? > > The default value of SO_RCVBUF is much larger than the SO_SNDBUF limit so it no longer needs to be set to match it. This mismatch caused the corresponding test 'java/net/DatagramSocket/SendReceiveMaxSize.java` to fail. > The proposed fix is to leave SO_RCVBUF as configured by default by the kernel. > > > issue: https://bugs.openjdk.java.net/browse/JDK-8250886 > webrev: http://cr.openjdk.java.net/~pconcannon/8250886/webrevs/webrev.00/ > Looks okay to me, that code should been removed a long time ago. -Alan From Alan.Bateman at oracle.com Thu Aug 6 13:48:34 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Aug 2020 14:48:34 +0100 Subject: RFR(s): Improving performance of Windows socket connect on the loopback adapter In-Reply-To: References: <4e7c31b3-e8c4-7bc1-341c-927fc8292a8d@oracle.com> <05a54b93-0475-99a3-6b86-d41173806504@oracle.com> <628cac66-4872-4821-3a29-f8c25b1666f6@oracle.com> <7a6cfe16-e126-4ef3-d22a-bcd7c0a18b8f@oracle.com> Message-ID: <6d808965-7eb3-ba20-2cb0-14b33ef32fe3@oracle.com> On 04/08/2020 16:36, Nikola Grcevski wrote: > Hi Alan, > >> What cheap is VerifyVersionInfoW? The check is done everytime but the overhead might be in the noise. Overall it looks good to me. > I wrote a small benchmark to measure the overhead of the version check (attached below). > > On my SurfaceBook 2 running Windows 10 Build 19041, the version check measures about ~2.2us (micro seconds) on average, when the > version matches. > > Elapsed time 2244us. (for 1,000 iterations) > > On a Windows 2016 Data Center Server the version check is much smaller ~0.13us (micro seconds) on average, when the version doesn't > match. > > Elapsed time 128us. (for 1,000 iterations) > > I think the overhead is reasonably small compared to everything else. Please let me know if it's acceptable and if we can proceed. > > Okay. So do you me to sponsor this? -Alan From daniel.fuchs at oracle.com Thu Aug 6 14:33:01 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 6 Aug 2020 15:33:01 +0100 Subject: RFR[8250886]: java/net/DatagramSocket/SendReceiveMaxSize.java fails in timeout In-Reply-To: <1D480B63-7894-44D8-B2E2-ABD66E3E1012@oracle.com> References: <1D480B63-7894-44D8-B2E2-ABD66E3E1012@oracle.com> Message-ID: <47c06663-4ca7-8a28-758a-5914d72c2ae7@oracle.com> Hi Patrick, Thanks for the good detective work in finding the reason for the test failure. The proposed change looks good to me! Good riddance :-) Since this is not a test bug after all, can you add 8250886 to the @bug clause in the test? best regards, -- daniel On 06/08/2020 13:29, Patrick Concannon wrote: > Hi, > > Could someone please review my fix for JDK-8250886 ? ?java/net/DatagramSocket/SendReceiveMaxSize.java fails in timeout? ? > > The default value of SO_RCVBUF is much larger than the SO_SNDBUF limit so it no longer needs to be set to match it. This mismatch caused the corresponding test 'java/net/DatagramSocket/SendReceiveMaxSize.java` to fail. > The proposed fix is to leave SO_RCVBUF as configured by default by the kernel. > > > issue: https://bugs.openjdk.java.net/browse/JDK-8250886 > webrev: http://cr.openjdk.java.net/~pconcannon/8250886/webrevs/webrev.00/ > > Kind regards, > Patrick > From Nikola.Grcevski at microsoft.com Thu Aug 6 14:37:59 2020 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Thu, 6 Aug 2020 14:37:59 +0000 Subject: RFR(s): Improving performance of Windows socket connect on the loopback adapter In-Reply-To: <6d808965-7eb3-ba20-2cb0-14b33ef32fe3@oracle.com> References: <4e7c31b3-e8c4-7bc1-341c-927fc8292a8d@oracle.com> <05a54b93-0475-99a3-6b86-d41173806504@oracle.com> <628cac66-4872-4821-3a29-f8c25b1666f6@oracle.com> <7a6cfe16-e126-4ef3-d22a-bcd7c0a18b8f@oracle.com> <6d808965-7eb3-ba20-2cb0-14b33ef32fe3@oracle.com> Message-ID: Yes, please. Thank you, Nikola -----Original Message----- From: Alan Bateman Sent: August 6, 2020 9:49 AM To: Nikola Grcevski ; net-dev at openjdk.java.net Subject: Re: RFR(s): Improving performance of Windows socket connect on the loopback adapter On 04/08/2020 16:36, Nikola Grcevski wrote: > Hi Alan, > >> What cheap is VerifyVersionInfoW? The check is done everytime but the overhead might be in the noise. Overall it looks good to me. > I wrote a small benchmark to measure the overhead of the version check (attached below). > > On my SurfaceBook 2 running Windows 10 Build 19041, the version check > measures about ~2.2us (micro seconds) on average, when the version matches. > > Elapsed time 2244us. (for 1,000 iterations) > > On a Windows 2016 Data Center Server the version check is much smaller > ~0.13us (micro seconds) on average, when the version doesn't match. > > Elapsed time 128us. (for 1,000 iterations) > > I think the overhead is reasonably small compared to everything else. Please let me know if it's acceptable and if we can proceed. > > Okay. So do you me to sponsor this? -Alan From chris.hegarty at oracle.com Fri Aug 7 08:44:27 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 7 Aug 2020 09:44:27 +0100 Subject: 8249786: java/net/httpclient/websocket/PendingPingTextClose.java fails very infrequently In-Reply-To: References: <1db3eaac-a595-209d-cef4-1ae46073d39a@oracle.com> Message-ID: Daniel, > On 23 Jul 2020, at 16:02, Daniel Fuchs wrote: > > Hi, > > More testing revealed that some other tests of the same family > kept on failing intermittently, though my changes to > PendingOperation.java should have fixed them. > > So here is a broader fix - which seems to have fixed the issue. > But as a consequence - I am no longer planning to push it to > 15 as it also changes some source files: > > http://cr.openjdk.java.net/~dfuchs/webrev_8249786/webrev.02/ LGTM - extending repeatable to cover Windows platforms too. ( the previous problems with these tests came flooding back when reading the comment in PendingOperations! ) -Chris. From rahul.r.yadav at oracle.com Fri Aug 7 09:09:24 2020 From: rahul.r.yadav at oracle.com (Rahul Yadav) Date: Fri, 7 Aug 2020 10:09:24 +0100 Subject: RFR 8248006 : Revisit exceptions thrown when creating an HttpClient fails due to unavailability of underlying resources. In-Reply-To: References: Message-ID: <9822a31d-c3fa-3463-d97d-cacc1c8235f4@oracle.com> Hello, Request to have my fix reviewed for issue: JDK-8248006:? Revisit exceptions thrown when creating an HttpClient fails due to unavailability of underlying resources. This fix updates jdk.internal.net.http.HttpClientImpl to throw an UncheckedIOException instead of InternalError, when creating the HttpClient fails due to underlying resources being not available, when Selector.open(), which is called from the underlying HttpClient implementation constructor, throws an IOException. Issue:? https://bugs.openjdk.java.net/browse/JDK-8248006 webrev: http://cr.openjdk.java.net/~ryadav/webrev_8248006/index.html csr :?? https://bugs.openjdk.java.net/browse/JDK-8251198 - rahul From daniel.fuchs at oracle.com Fri Aug 7 09:11:26 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 7 Aug 2020 10:11:26 +0100 Subject: 8249786: java/net/httpclient/websocket/PendingPingTextClose.java fails very infrequently In-Reply-To: References: <1db3eaac-a595-209d-cef4-1ae46073d39a@oracle.com> Message-ID: Thanks Chris! best regards, -- daniel On 07/08/2020 09:44, Chris Hegarty wrote: >> http://cr.openjdk.java.net/~dfuchs/webrev_8249786/webrev.02/ > LGTM - extending repeatable to cover Windows platforms too. > ( the previous problems with these tests came flooding back > when reading the comment in PendingOperations! ) > From daniel.fuchs at oracle.com Fri Aug 7 09:15:27 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 7 Aug 2020 10:15:27 +0100 Subject: RFR 8248006 : Revisit exceptions thrown when creating an HttpClient fails due to unavailability of underlying resources. In-Reply-To: <9822a31d-c3fa-3463-d97d-cacc1c8235f4@oracle.com> References: <9822a31d-c3fa-3463-d97d-cacc1c8235f4@oracle.com> Message-ID: <673898d8-35a6-16ae-c8fc-e01db7d538df@oracle.com> Hi Rahul, Thanks for taking this on. This looks good to me. Trivially, there is a space missing before "and" there: 362 * if the implementation requires a {@link Selector},and opening No need to publish a new webrev, just make sure to add the missing space before pushing. best regards, -- daniel On 07/08/2020 10:09, Rahul Yadav wrote: > Hello, > > Request to have my fix reviewed for issue: > > JDK-8248006:? Revisit exceptions thrown when creating an HttpClient > fails due to unavailability of underlying resources. > > This fix updates jdk.internal.net.http.HttpClientImpl to throw an > UncheckedIOException instead of InternalError, > when creating the HttpClient fails due to underlying resources being not > available, when Selector.open(), which is > called from the underlying HttpClient implementation constructor, throws > an IOException. > > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8248006 > webrev: http://cr.openjdk.java.net/~ryadav/webrev_8248006/index.html > csr :?? https://bugs.openjdk.java.net/browse/JDK-8251198 > > - rahul From chris.hegarty at oracle.com Fri Aug 7 11:04:06 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 7 Aug 2020 12:04:06 +0100 Subject: 8229822: ThrowingPushPromises tests sometimes fail due to EOF In-Reply-To: <058c1dcb-688d-d9fd-52ce-9d58fe7fcd31@oracle.com> References: <058c1dcb-688d-d9fd-52ce-9d58fe7fcd31@oracle.com> Message-ID: Daniel, > On 31 Jul 2020, at 15:56, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8229822: ThrowingPushPromises tests sometimes fail due to EOF > https://bugs.openjdk.java.net/browse/JDK-8229822 > > While trying to write a good test for JDK-8245462 I stumbled > on two issues - which I believe are at the root of the > ThrowingPushPromises failures: > > - SocketTube: I found an issue where the scheduler might not > be restarted if resuming/pausing event from within > the scheduler loop (that runs in the selector manager > thread) failed due to the socket being asynchronously > closed by another thread. > That could cause some tests to fail in timeout. Good sleuthing. I?m surprised that we?ve not come across this before, but what you have seems to catch these corner cases, ( the last one on L889 was non-obvious ). > - Http2Connection/Stream: there was an issue where DataFrames > could be sent after a ResetFrame was sent. That caused the > server to close down the connection. The next test would > start opening a new stream on the same connection while > the server was concurrently closing it, and the test > would eventually fail - sometimes with a message saying > "EOF reached while reading?. Wow, there?s a lot going on in this change, that covers cases where connection / streams are closed at various different points especially very early in their lifecycle. > The webrev below includes these two fixes; The test have simply been > update to list 8229822 for verification purposes. > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8229822/webrev.00/ I think that this is fine, and I know that you have further changes coming to add additional tests and scenarios where closure / cancellation can occur. -Chris. From chris.hegarty at oracle.com Fri Aug 7 11:07:21 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 7 Aug 2020 12:07:21 +0100 Subject: RFR 8248006 : Revisit exceptions thrown when creating an HttpClient fails due to unavailability of underlying resources. In-Reply-To: <9822a31d-c3fa-3463-d97d-cacc1c8235f4@oracle.com> References: <9822a31d-c3fa-3463-d97d-cacc1c8235f4@oracle.com> Message-ID: <166CC7B0-80DE-4F13-8B7A-5EA6BE933867@oracle.com> Rahul, > On 7 Aug 2020, at 10:09, Rahul Yadav wrote: > > Hello, > > ... > Issue: https://bugs.openjdk.java.net/browse/JDK-8248006 > webrev: http://cr.openjdk.java.net/~ryadav/webrev_8248006/index.html > csr : https://bugs.openjdk.java.net/browse/JDK-8251198 > Looks good to me. I?m happy that these methods are not declared to throw IOException - I would have also used unchecked IO ( if I had of encountered the issue early on ) -Chris. From pavel.rappo at oracle.com Fri Aug 7 12:49:48 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 7 Aug 2020 13:49:48 +0100 Subject: 8249786: java/net/httpclient/websocket/PendingPingTextClose.java fails very infrequently In-Reply-To: References: <1db3eaac-a595-209d-cef4-1ae46073d39a@oracle.com> Message-ID: <41075260-F504-41C3-8A8C-AAC3709BF526@oracle.com> Daniel, The changes in TransportImpl look okay to me. I cannot see how they break anything. On the other hand, I guess it will take some time to see if the (complete) changeset fixes the issue. One minor thing that makes me a tad bit uncomfortable is the new assert statements. Firstly, they may have visibility side effects. Secondly, they could be more informative. May I suggest we use this? ChannelState s; assert (s = writeState.get()) == CLOSED : s; Or better still, ChannelState s = writeState.get(); assert s == CLOSED : s; -Pavel > On 23 Jul 2020, at 16:02, Daniel Fuchs wrote: > > Hi, > > More testing revealed that some other tests of the same family > kept on failing intermittently, though my changes to > PendingOperation.java should have fixed them. > > So here is a broader fix - which seems to have fixed the issue. > But as a consequence - I am no longer planning to push it to > 15 as it also changes some source files: > > http://cr.openjdk.java.net/~dfuchs/webrev_8249786/webrev.02/ > > best regards, > > -- daniel > > On 21/07/2020 18:53, Daniel Fuchs wrote: >> Hi, >> Please find below a fix for: >> 8249786: java/net/httpclient/websocket/PendingPingTextClose.java >> fails very infrequently >> https://bugs.openjdk.java.net/browse/JDK-8249786 >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8249786/webrev.00/ >> This test has been observed failing on windows in the JDK 15 CI. >> The most troublesome issue is that the test was producing so >> much output that the actual reason for the failure was lost >> in the output overflow. >> After instrumenting the test to limit the output and >> adding a few higher level traces, I was able to reproduce >> once (out of 250 runs) and see the actual stack trace. >> The test fails just after calling websocket.abort() when it tries >> to verify that the cfPing CompletableFuture completed >> exceptionally, and found that it actually successfully completed. >> The logic of the test is to try to fill up the local send buffer >> by sending ping messages, so that an attempt to write to the >> socket will block. >> For that it creates a server that will accept a websocket >> connection, but will not read anything from the socket input. >> The client side sends ping packets until the socket buffer >> is full - which is detected by setting up a 10s timeout and >> observing that the ping data could not be written during >> this time. The assumption of the test is that a write call >> that takes more than 10s is indicative that the buffers are >> full, and will never succeed. >> The problem occurs when the write succeeds after ~10s either >> because the kernel was busy doing some other things, or because >> the kernel suddenly decided to resize (increase) the buffers, >> which causes the write call to unblock and succeed after 10s. >> The test already had some provision and a workaround for that >> issue - via a repeatable( ) operation - but the workaround >> was only enabled for macOS where such behavior had first been >> observed. >> The fix extends that workaround for Windows - since the later >> failure shows that something similar is happening there. >> The fix also moves the websocket.abort() and following check >> inside the repeatable loop for better reliability. >> Since pushing test fixes during rampdown 2 is permitted, >> and since the failure was observed in the JDK 15 CI, I'm >> planning to push this test fix to the jdk15 repo, >> unless I hear any objection. >> best regards, >> -- daniel > From daniel.fuchs at oracle.com Fri Aug 7 12:59:24 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 7 Aug 2020 13:59:24 +0100 Subject: 8249786: java/net/httpclient/websocket/PendingPingTextClose.java fails very infrequently In-Reply-To: <41075260-F504-41C3-8A8C-AAC3709BF526@oracle.com> References: <1db3eaac-a595-209d-cef4-1ae46073d39a@oracle.com> <41075260-F504-41C3-8A8C-AAC3709BF526@oracle.com> Message-ID: <48eccf3e-56c0-b909-baa4-372f090dbee7@oracle.com> Hi Pavel, Thanks for the review! On 07/08/2020 13:49, Pavel Rappo wrote: > May I suggest we use this? > > ChannelState s; > assert (s = writeState.get()) == CLOSED : s; > > Or better still, > > ChannelState s = writeState.get(); > assert s == CLOSED : s; > I'll do that before pushing. best regards, -- daniel From daniel.fuchs at oracle.com Fri Aug 7 18:19:25 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 7 Aug 2020 19:19:25 +0100 Subject: 8245462: HttpClient send throws InterruptedException when interrupted but does not cancel request In-Reply-To: <58b7a5f8-00bf-34e0-e156-72a603c15961@oracle.com> References: <14613d53-0105-cc57-b082-7c2691a8be6e@oracle.com> <4a7b1202-f8d1-eb3f-fd45-6d9523d28bf3@oracle.com> <6dd0519f-242f-3c10-d87b-ede941bf6bfa@oracle.com> <7ec6590b-638e-bc0b-2ea3-52c94e2cfdd7@oracle.com> <58b7a5f8-00bf-34e0-e156-72a603c15961@oracle.com> Message-ID: <1c609b47-d23b-b063-0a64-4a6561b1ad39@oracle.com> Hi, Here is the new webrev that goes on top of the changes from 8229822 (which are already pushed). http://cr.openjdk.java.net/~dfuchs/webrev_8245462/webrev.02/ I have also written the CSR: https://bugs.openjdk.java.net/browse/JDK-8251312 feedback - and reviewers - welcome :-) best regards, -- daniel On 31/07/2020 10:46, Daniel Fuchs wrote: > I wonder if I should try to extract those > two fixes though - as it might be worthwile to backport > them independently: > > http://cr.openjdk.java.net/~dfuchs/webrev_8245462/webrev.01/index.html > > best regards, > > -- daniel From patrick.concannon at oracle.com Tue Aug 11 14:43:14 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Tue, 11 Aug 2020 15:43:14 +0100 Subject: RFR[8240901]: 'Add a test to check that large datagrams are sent/received on the network correctly' Message-ID: <13681CB5-677E-437F-A5E8-F1AF757C6A1D@oracle.com> Hi, Could someone please review my fix for JDK-8240901 ? ?Add a test to check that large datagrams are sent/received on the network correctly? ? The tests `java/net/DatagramSocket/SendReceiveMaxSize.java` and `java/net/DatagramSocket/SendReceiveMaxSize.java` have been updated to check (on all platforms) that the sending and receiving of large datagrams across a network are sent, fragmented, and re-assembled correctly. Previously, this check was performed on macOS only. issue: https://bugs.openjdk.java.net/browse/JDK-8240901 webrev: http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.00/ Kind regards, Patrick From daniel.fuchs at oracle.com Tue Aug 11 15:41:05 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 11 Aug 2020 16:41:05 +0100 Subject: RFR[8240901]: 'Add a test to check that large datagrams are sent/received on the network correctly' In-Reply-To: <13681CB5-677E-437F-A5E8-F1AF757C6A1D@oracle.com> References: <13681CB5-677E-437F-A5E8-F1AF757C6A1D@oracle.com> Message-ID: <82e1a740-9598-83c3-33fa-50998878f9cf@oracle.com> Hi Patrick, I thought I had mentioned it before, but the DatagramChannel test looks wrong: if I am not mistaken the assertTrue check that compare the two buffers will always succeed, even if the data in the two buffers is different. It only requires that the two buffers are filled to their limit: 1. Can you add a system.println before verifying that the two buffers are equals, that prints both buffers' positions and limit? 2. Can we use assertEquals instead of assertTrue? 3. hint: there are two lines that need to be moved around (at two different places) and that should become clear when you look at the traces printed in 1. best, -- daniel On 11/08/2020 15:43, Patrick Concannon wrote: > Hi, > > Could someone please review my fix for JDK-8240901 ? ?Add a test to check that large datagrams are sent/received on the network correctly? ? > > The tests `java/net/DatagramSocket/SendReceiveMaxSize.java` and `java/net/DatagramSocket/SendReceiveMaxSize.java` have been updated to check (on all platforms) that the sending and receiving of large datagrams across a network are sent, fragmented, and re-assembled correctly. Previously, this check was performed on macOS only. > > issue: https://bugs.openjdk.java.net/browse/JDK-8240901 > webrev: http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.00/ > > Kind regards, > Patrick > From patrick.concannon at oracle.com Tue Aug 11 19:45:12 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Tue, 11 Aug 2020 20:45:12 +0100 Subject: RFR[8240901]: 'Add a test to check that large datagrams are sent/received on the network correctly' In-Reply-To: <82e1a740-9598-83c3-33fa-50998878f9cf@oracle.com> References: <13681CB5-677E-437F-A5E8-F1AF757C6A1D@oracle.com> <82e1a740-9598-83c3-33fa-50998878f9cf@oracle.com> Message-ID: <5B96D5E2-570D-4115-B8EC-F89257DC0B85@oracle.com> Hi Daniel, Thanks for pointing this out. Please find the corrections in the updated webrev below. http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.01/ Kind regards, Patrick > On 11 Aug 2020, at 16:41, Daniel Fuchs wrote: > > Hi Patrick, > > I thought I had mentioned it before, but the DatagramChannel test > looks wrong: if I am not mistaken the assertTrue check that compare > the two buffers will always succeed, even if the data in the two > buffers is different. It only requires that the two buffers are > filled to their limit: > > 1. Can you add a system.println before verifying that the two > buffers are equals, that prints both buffers' positions and limit? > > 2. Can we use assertEquals instead of assertTrue? > > 3. hint: there are two lines that need to be moved around (at two > different places) and that should become clear when you look at > the traces printed in 1. > > best, > > -- daniel > > > On 11/08/2020 15:43, Patrick Concannon wrote: >> Hi, >> Could someone please review my fix for JDK-8240901 ? ?Add a test to check that large datagrams are sent/received on the network correctly? ? >> The tests `java/net/DatagramSocket/SendReceiveMaxSize.java` and `java/net/DatagramSocket/SendReceiveMaxSize.java` have been updated to check (on all platforms) that the sending and receiving of large datagrams across a network are sent, fragmented, and re-assembled correctly. Previously, this check was performed on macOS only. >> issue: https://bugs.openjdk.java.net/browse/JDK-8240901 >> webrev: http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.00/ >> Kind regards, >> Patrick > From daniel.fuchs at oracle.com Wed Aug 12 09:18:05 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 12 Aug 2020 10:18:05 +0100 Subject: RFR[8240901]: 'Add a test to check that large datagrams are sent/received on the network correctly' In-Reply-To: <5B96D5E2-570D-4115-B8EC-F89257DC0B85@oracle.com> References: <13681CB5-677E-437F-A5E8-F1AF757C6A1D@oracle.com> <82e1a740-9598-83c3-33fa-50998878f9cf@oracle.com> <5B96D5E2-570D-4115-B8EC-F89257DC0B85@oracle.com> Message-ID: Hi Patrick, Still one more thing: test/jdk/java/net/DatagramSocket/SendReceiveMaxSize.java 124 // check packet data has been fragmented and re-assembled correctly at receiver 125 assertTrue(Arrays.equals(receivePkt.getData(), testData)); 1. I think you should first check that the length matches: assertEquals(receivePacket.getLength(), capacity); 2. You can use assertEquals to compare two byte[] arrays as well, since org.testng.Assert has an assertEquals overload for byte[] assertEquals(receivePkt.getData(), testData); Otherwise LGTM! best regards, -- daniel On 11/08/2020 20:45, Patrick Concannon wrote: > Hi Daniel, > > Thanks for pointing this out. > > Please find the corrections in the updated webrev below. > > http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.01/ > > Kind regards, > Patrick > From Alan.Bateman at oracle.com Wed Aug 12 09:21:20 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Aug 2020 10:21:20 +0100 Subject: RFR[8240901]: 'Add a test to check that large datagrams are sent/received on the network correctly' In-Reply-To: <13681CB5-677E-437F-A5E8-F1AF757C6A1D@oracle.com> References: <13681CB5-677E-437F-A5E8-F1AF757C6A1D@oracle.com> Message-ID: On 11/08/2020 15:43, Patrick Concannon wrote: > Hi, > > Could someone please review my fix for JDK-8240901 ? ?Add a test to check that large datagrams are sent/received on the network correctly? ? > > The tests `java/net/DatagramSocket/SendReceiveMaxSize.java` and `java/net/DatagramSocket/SendReceiveMaxSize.java` have been updated to check (on all platforms) that the sending and receiving of large datagrams across a network are sent, fragmented, and re-assembled correctly. Previously, this check was performed on macOS only. > > issue: https://bugs.openjdk.java.net/browse/JDK-8240901 > webrev: http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.00/ > The @bug list in this test is accumulating the list of issues that the test covers so you can add to that. Also add `@key randomness` as the test now depends on Random bytes in the payload. Did you mean to leave in the debug messages? If this is for tracing purposes then you can print sendBuf and receiveBuf as their output has the buffer position, limit and capacity in a more compact format. -Alan. From patrick.concannon at oracle.com Thu Aug 13 08:40:45 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Thu, 13 Aug 2020 09:40:45 +0100 Subject: =?utf-8?Q?RFR=5B8189744=5D=3A_=27Deprecate_the_JDK-specific_API_f?= =?utf-8?Q?or_setting_socket_options=2C_jdk=2Enet=2ESockets=E2=80=99?= Message-ID: <51947503-05BF-4684-A8A5-B96FF283FD29@oracle.com> Hi, Could someone please review my fix for JDK-8189744 ? 'Deprecate the JDK-specific API for setting socket options, jdk.net.Sockets? ? The JDK-specific API `jdk.net.Sockets` has been redundant since Java SE 9 added standard methods to get/set socket options and retrieve per-Socket supported options. This fix deprecates the class and its public methods. webrev: http://cr.openjdk.java.net/~pconcannon/8189744/webrevs/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8189744 Kind regards, Patrick From daniel.fuchs at oracle.com Thu Aug 13 09:58:46 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Aug 2020 10:58:46 +0100 Subject: =?UTF-8?Q?Re=3a_RFR=5b8189744=5d=3a_=27Deprecate_the_JDK-specific_A?= =?UTF-8?Q?PI_for_setting_socket_options=2c_jdk=2enet=2eSockets=e2=80=99?= In-Reply-To: <51947503-05BF-4684-A8A5-B96FF283FD29@oracle.com> References: <51947503-05BF-4684-A8A5-B96FF283FD29@oracle.com> Message-ID: Hi Patrick, This looks fine to me. You will need a CSR though. best regards, -- daniel On 13/08/2020 09:40, Patrick Concannon wrote: > Hi, > > Could someone please review my fix for JDK-8189744 ? 'Deprecate the JDK-specific API for setting socket options, jdk.net.Sockets? ? > > The JDK-specific API `jdk.net.Sockets` has been redundant since Java SE 9 added standard methods to get/set socket options and retrieve per-Socket supported options. This fix deprecates the class and its public methods. > > webrev: http://cr.openjdk.java.net/~pconcannon/8189744/webrevs/webrev.00/ > issue: https://bugs.openjdk.java.net/browse/JDK-8189744 > > Kind regards, > Patrick > From patrick.concannon at oracle.com Thu Aug 13 10:07:13 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Thu, 13 Aug 2020 11:07:13 +0100 Subject: RFR[8240901]: 'Add a test to check that large datagrams are sent/received on the network correctly' In-Reply-To: References: <13681CB5-677E-437F-A5E8-F1AF757C6A1D@oracle.com> Message-ID: <3B268C7E-7FBA-4594-8C02-9FB6EC12DB71@oracle.com> Hi, Daniel: Thanks for spotting these. I?ve made these changes and incorporated them into the new webrev below. Alan: I?ve added the tags, and trimmed the debug message as you?ve suggested. http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.02/ Kind regards, Patrick > On 12 Aug 2020, at 10:21, Alan Bateman wrote: > > > > On 11/08/2020 15:43, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my fix for JDK-8240901 ? ?Add a test to check that large datagrams are sent/received on the network correctly? ? >> >> The tests `java/net/DatagramSocket/SendReceiveMaxSize.java` and `java/net/DatagramSocket/SendReceiveMaxSize.java` have been updated to check (on all platforms) that the sending and receiving of large datagrams across a network are sent, fragmented, and re-assembled correctly. Previously, this check was performed on macOS only. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8240901 >> webrev: http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.00/ >> > The @bug list in this test is accumulating the list of issues that the test covers so you can add to that. Also add `@key randomness` as the test now depends on Random bytes in the payload. > > Did you mean to leave in the debug messages? If this is for tracing purposes then you can print sendBuf and receiveBuf as their output has the buffer position, limit and capacity in a more compact format. > > -Alan. From daniel.fuchs at oracle.com Thu Aug 13 10:21:30 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Aug 2020 11:21:30 +0100 Subject: RFR[8240901]: 'Add a test to check that large datagrams are sent/received on the network correctly' In-Reply-To: <3B268C7E-7FBA-4594-8C02-9FB6EC12DB71@oracle.com> References: <13681CB5-677E-437F-A5E8-F1AF757C6A1D@oracle.com> <3B268C7E-7FBA-4594-8C02-9FB6EC12DB71@oracle.com> Message-ID: <5f30ed98-e500-6f53-1b76-c98297651ae4@oracle.com> Thanks Patrick! That looks good to me. best regards, -- daniel On 13/08/2020 11:07, Patrick Concannon wrote: > Hi, > > Daniel: Thanks for spotting these. I?ve made these changes and incorporated them into the new webrev below. > > Alan: I?ve added the tags, and trimmed the debug message as you?ve suggested. > > http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.02/ > > Kind regards, > Patrick From nicolas.henneaux at gmail.com Thu Aug 13 10:51:42 2020 From: nicolas.henneaux at gmail.com (Nicolas Henneaux) Date: Thu, 13 Aug 2020 12:51:42 +0200 Subject: [java.net.http.HttpClient] Active monitoring of resolved IP addresses In-Reply-To: References: <5738e764-c8f6-c5ba-c7a6-c88dfdca96de@oracle.com> Message-ID: Hi, Were you able to have a quick look at what I have done to see whether it might be better integrated into OpenJDK? Do you think the use case is valuable to be better handled? I actually use such mechanisms in production to have a proper view on what are the IP available for a service API. In cloud environments, the underlying IP of a hostname might indeed move on a regular basis. Thank you in advance for your feedback, Best regards, Nicolas Henneaux On Wed, 29 Jul 2020 at 16:53, Nicolas Henneaux wrote: > Hi Daniel, > > It is needed since the hostname sent in the HTTP client is the IP instead > of the actual hostname to force the usage of a single IP. However, a > specific SSLContext is used to ensure the hostname TLS validation is still > done. > Usage of the IP in the HTTP request > > Check of the hostname during TLS handshake > > > > I hope it is more clear why this property should be disabled in the way > the HTTP client force a single IP. > > Best regards, > > Nicolas > > On Wed, 29 Jul 2020 at 14:31, Daniel Fuchs > wrote: > >> Hi Nicolas, >> >> On 29/07/2020 13:20, Nicolas Henneaux wrote: >> > >> System.setProperty("jdk.internal.httpclient.disableHostnameVerification", >> Boolean.TRUE.toString()); >> > System.setProperty("jdk.httpclient.allowRestrictedHeaders", "host"); >> >> I don't believe it's a good idea to disable/customize >> hostname verification. This property is merely intended for >> test environments - where you might need to pretend that you're >> talking to some other servers... >> >> And it shouldn't be needed if the certificate presented by the >> server contained the proper host names? >> >> best regards, >> >> -- daniel >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.concannon at oracle.com Thu Aug 13 13:08:45 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Thu, 13 Aug 2020 14:08:45 +0100 Subject: =?utf-8?Q?Re=3A_RFR=5B8189744=5D=3A_=27Deprecate_the_JDK-specific?= =?utf-8?Q?_API_for_setting_socket_options=2C_jdk=2Enet=2ESockets=E2=80=99?= In-Reply-To: References: <51947503-05BF-4684-A8A5-B96FF283FD29@oracle.com> Message-ID: <02B96BD3-F707-440D-A2CD-D911F31295B2@oracle.com> Hi Daniel, Thanks for taking a look. Here is a link to the CSR: https://bugs.openjdk.java.net/browse/JDK-8251532 Kind regards, Patrick > On 13 Aug 2020, at 10:58, Daniel Fuchs wrote: > > Hi Patrick, > > This looks fine to me. > You will need a CSR though. > > best regards, > > -- daniel > > On 13/08/2020 09:40, Patrick Concannon wrote: >> Hi, >> Could someone please review my fix for JDK-8189744 ? 'Deprecate the JDK-specific API for setting socket options, jdk.net.Sockets? ? >> The JDK-specific API `jdk.net.Sockets` has been redundant since Java SE 9 added standard methods to get/set socket options and retrieve per-Socket supported options. This fix deprecates the class and its public methods. >> webrev: http://cr.openjdk.java.net/~pconcannon/8189744/webrevs/webrev.00/ >> issue: https://bugs.openjdk.java.net/browse/JDK-8189744 >> Kind regards, >> Patrick > From chris.hegarty at oracle.com Thu Aug 13 13:44:42 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 13 Aug 2020 14:44:42 +0100 Subject: =?utf-8?Q?Re=3A_RFR=5B8189744=5D=3A_=27Deprecate_the_JDK-specific?= =?utf-8?Q?_API_for_setting_socket_options=2C_jdk=2Enet=2ESockets=E2=80=99?= In-Reply-To: <02B96BD3-F707-440D-A2CD-D911F31295B2@oracle.com> References: <51947503-05BF-4684-A8A5-B96FF283FD29@oracle.com> <02B96BD3-F707-440D-A2CD-D911F31295B2@oracle.com> Message-ID: <6FBB3567-5C4A-451F-86FA-8DDEFA442901@oracle.com> > On 13 Aug 2020, at 14:08, Patrick Concannon wrote: > > Hi Daniel, > > Thanks for taking a look. > > Here is a link to the CSR: https://bugs.openjdk.java.net/browse/JDK-8251532 LGTM. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From julia.boes at oracle.com Thu Aug 13 15:05:51 2020 From: julia.boes at oracle.com (Julia Boes) Date: Thu, 13 Aug 2020 16:05:51 +0100 Subject: Fix for Javadoc errors in java.base In-Reply-To: References: Message-ID: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> Hi Vipin, Thanks for providing this fix, I'm happy to sponsor your change. To complete the review, we still need someone to green light the remaining changes below. I'm looping in net-dev and security-dev to have a look. Bug: https://bugs.openjdk.java.net/browse/JDK-8251542 Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/ Once the review is completed, please provide me with a patch that includes a changeset comment as described here: https://openjdk.java.net/guide/producingChangeset.html If you have any questions, let me know. Cheers, Julia > --- old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java > 2020-07-25 23:46:21.233726447 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java > 2020-07-25 23:46:20.721720857 +0530 > @@ -96,8 +96,6 @@ > * @param p the prime modulus > * @param g the base generator > * @param l the private-value length > - * > - * @exception InvalidKeyException if the key cannot be encoded > */ > DHPrivateKey(BigInteger x, BigInteger p, BigInteger g, int l) { > this.x = x; > --- old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java > 2020-07-25 23:46:22.241737383 +0530 > +++ new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java > 2020-07-25 23:46:21.745732013 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -208,7 +208,7 @@ > * > * @return a CallSite, which, when invoked, will return an instance of the > * functional interface > - * @throws ReflectiveOperationException > + * @throws LambdaConversionException > */ > abstract CallSite buildCallSite() > throws LambdaConversionException; > --- old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java > 2020-07-25 23:46:23.261748361 +0530 > +++ new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java > 2020-07-25 23:46:22.761742991 +0530 > @@ -200,7 +200,6 @@ > * > * @return a CallSite, which, when invoked, will return an instance of the > * functional interface > - * @throws ReflectiveOperationException > * @throws LambdaConversionException If properly formed functional interface > * is not found > */ > --- old/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25 > 23:46:26.449782093 +0530 > +++ new/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25 > 23:46:25.937776742 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2020, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -315,7 +315,7 @@ > /** > * Creates the socket implementation. > * > - * @throws IOException if creation fails > + * @throws SocketException if creation fails > * @since 1.4 > */ > void createImpl() throws SocketException { > --- old/src/java.base/share/classes/java/net/Socket.java 2020-07-25 > 23:46:27.485792869 +0530 > +++ new/src/java.base/share/classes/java/net/Socket.java 2020-07-25 > 23:46:26.973787565 +0530 > @@ -533,7 +533,7 @@ > * > * @param stream a {@code boolean} value : {@code true} for a TCP socket, > * {@code false} for UDP. > - * @throws IOException if creation fails > + * @throws SocketException if creation fails > * @since 1.4 > */ > void createImpl(boolean stream) throws SocketException { From Alan.Bateman at oracle.com Thu Aug 13 15:42:44 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Aug 2020 16:42:44 +0100 Subject: RFR[8240901]: 'Add a test to check that large datagrams are sent/received on the network correctly' In-Reply-To: <3B268C7E-7FBA-4594-8C02-9FB6EC12DB71@oracle.com> References: <13681CB5-677E-437F-A5E8-F1AF757C6A1D@oracle.com> <3B268C7E-7FBA-4594-8C02-9FB6EC12DB71@oracle.com> Message-ID: On 13/08/2020 11:07, Patrick Concannon wrote: > Hi, > > Daniel: Thanks for spotting these. I?ve made these changes and incorporated them into the new webrev below. > > Alan: I?ve added the tags, and trimmed the debug message as you?ve suggested. > > http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.02/ > Okay. From daniel.fuchs at oracle.com Thu Aug 13 16:07:30 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Aug 2020 17:07:30 +0100 Subject: Fix for Javadoc errors in java.base In-Reply-To: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> Message-ID: <17593e07-0ae1-c881-47df-17643698d53f@oracle.com> Hi Vipin, Julia, On 13/08/2020 16:05, Julia Boes wrote: > Hi Vipin, > > Thanks for providing this fix, I'm happy to sponsor your change. To > complete the review, we still need someone to green light the remaining > changes below. I'm looping in net-dev and security-dev to have a look. Changes to Socket and ServerSocket look fine. No CSR needed since this is a package private API. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251542 > > Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/ best regards, -- daniel From sean.mullan at oracle.com Thu Aug 13 17:13:06 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Aug 2020 13:13:06 -0400 Subject: Fix for Javadoc errors in java.base In-Reply-To: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> Message-ID: <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> On 8/13/20 11:05 AM, Julia Boes wrote: > Hi Vipin, > > Thanks for providing this fix, I'm happy to sponsor your change. To > complete the review, we still need someone to green light the remaining > changes below. I'm looping in net-dev and security-dev to have a look. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251542 > > Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/ > > Once the review is completed, please provide me with a patch that > includes a changeset comment as described here: > https://openjdk.java.net/guide/producingChangeset.html > > If you have any questions, let me know. > > Cheers, > > Julia > >> --- >> old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >> 2020-07-25 23:46:21.233726447 +0530 >> +++ >> new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >> 2020-07-25 23:46:20.721720857 +0530 >> @@ -96,8 +96,6 @@ >> ?????? * @param p the prime modulus >> ?????? * @param g the base generator >> ?????? * @param l the private-value length >> -???? * >> -???? * @exception InvalidKeyException if the key cannot be encoded This should actually remain, but it should be ProviderException which is a RuntimeException. See the other DHPrivateKey ctor as that specifies it correctly. --Sean From jonathan.gibbons at oracle.com Thu Aug 13 17:21:49 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 13 Aug 2020 10:21:49 -0700 Subject: Fix for Javadoc errors in java.base In-Reply-To: <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> Message-ID: On 8/13/20 10:13 AM, Sean Mullan wrote: > On 8/13/20 11:05 AM, Julia Boes wrote: >> Hi Vipin, >> >> Thanks for providing this fix, I'm happy to sponsor your change. To >> complete the review, we still need someone to green light the >> remaining changes below. I'm looping in net-dev and security-dev to >> have a look. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8251542 >> >> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/ >> >> Once the review is completed, please provide me with a patch that >> includes a changeset comment as described here: >> https://openjdk.java.net/guide/producingChangeset.html >> >> If you have any questions, let me know. >> >> Cheers, >> >> Julia >> >>> --- >>> old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>> 2020-07-25 23:46:21.233726447 +0530 >>> +++ >>> new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>> 2020-07-25 23:46:20.721720857 +0530 >>> @@ -96,8 +96,6 @@ >>> ?????? * @param p the prime modulus >>> ?????? * @param g the base generator >>> ?????? * @param l the private-value length >>> -???? * >>> -???? * @exception InvalidKeyException if the key cannot be encoded > > This should actually remain, but it should be ProviderException which > is a RuntimeException. See the other DHPrivateKey ctor as that > specifies it correctly. > > --Sean I note the use of `@exception`, as compared to `@throws`, which is more common. Stats: `@exception` 7322 occurrences `@throws` 21173 occurrences That's probably too many `@exception` to clean up. :-( -- Jon From sean.mullan at oracle.com Thu Aug 13 17:25:57 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Aug 2020 13:25:57 -0400 Subject: Fix for Javadoc errors in java.base In-Reply-To: References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> Message-ID: <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> On 8/13/20 1:21 PM, Jonathan Gibbons wrote: >>>> --- >>>> old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>>> >>>> 2020-07-25 23:46:21.233726447 +0530 >>>> +++ >>>> new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>>> >>>> 2020-07-25 23:46:20.721720857 +0530 >>>> @@ -96,8 +96,6 @@ >>>> ?????? * @param p the prime modulus >>>> ?????? * @param g the base generator >>>> ?????? * @param l the private-value length >>>> -???? * >>>> -???? * @exception InvalidKeyException if the key cannot be encoded >> >> This should actually remain, but it should be ProviderException which >> is a RuntimeException. See the other DHPrivateKey ctor as that >> specifies it correctly. >> >> --Sean > > > I note the use of `@exception`, as compared to `@throws`, which is more > common. > > Stats: > `@exception` 7322 occurrences > `@throws` 21173 occurrences > > That's probably too many `@exception` to clean up. :-( Right, that's probably a separate cleanup activity. However, if you want to change the 3 instances of @exception to @throws in DHPrivateKey, I'm fine with that. --Sean From patrick.concannon at oracle.com Thu Aug 13 18:54:12 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Thu, 13 Aug 2020 19:54:12 +0100 Subject: RFR[7164518]: 'No PortUnreachableException when connecting to a non-existing DatagramSocket (mac)' Message-ID: <2F0987BF-DAAB-4DEE-8733-CC4E61FCD906@oracle.com> Hi, Could someone please review my fix for JDK-7164518 ? 'No PortUnreachableException when connecting to a non-existing DatagramSocket (Mac)? ? This test failed with a `SocketTimeoutException` instead of the expected `PortUnreachableException`. However, the issue causing this has been resolved in JDK 15 with the new implementation of DatagramSocket, and can now be taken off the ProblemList. This fix adds the option `-Djdk.net.usePlainDatagramSocketImpl=false` to the test to ensure that it only uses the new implementation and therefore no longer fails. issue: https://bugs.openjdk.java.net/browse/JDK-7164518 webrev: http://cr.openjdk.java.net/~pconcannon/7164518/webrevs/webrev.00/ Kind regards, Patrick From daniel.fuchs at oracle.com Thu Aug 13 18:56:35 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Aug 2020 19:56:35 +0100 Subject: RFR[7164518]: 'No PortUnreachableException when connecting to a non-existing DatagramSocket (mac)' In-Reply-To: <2F0987BF-DAAB-4DEE-8733-CC4E61FCD906@oracle.com> References: <2F0987BF-DAAB-4DEE-8733-CC4E61FCD906@oracle.com> Message-ID: Hi Patrick, LGTM! best regards, -- daniel On 13/08/2020 19:54, Patrick Concannon wrote: > Hi, > > Could someone please review my fix for JDK-7164518 ? 'No PortUnreachableException when connecting to a non-existing DatagramSocket (Mac)? ? > > This test failed with a `SocketTimeoutException` instead of the expected `PortUnreachableException`. However, the issue causing this has been resolved in JDK 15 with the new implementation of DatagramSocket, and can now be taken off the ProblemList. > > This fix adds the option `-Djdk.net.usePlainDatagramSocketImpl=false` to the test to ensure that it only uses the new implementation and therefore no longer fails. > > issue: https://bugs.openjdk.java.net/browse/JDK-7164518 > webrev: http://cr.openjdk.java.net/~pconcannon/7164518/webrevs/webrev.00/ > > > Kind regards, > Patrick > From nick.gasson at arm.com Fri Aug 14 03:42:56 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 14 Aug 2020 11:42:56 +0800 Subject: RFR(S): 8251517: [TESTBUG] com/sun/net/httpserver/bugs/B6393710.java does not scale socket timeout Message-ID: <85ft8priyn.fsf@nicgas01-pc.shanghai.arm.com> Hi, Bug: http://cr.openjdk.java.net/~ngasson/8251517/webrev.0/ Webrev: https://bugs.openjdk.java.net/browse/JDK-8251517 This case fails in our testing when run with -Xcomp on a fastdebug build. The 5s socket read timeout is too short for this configuration. Fix by scaling by the jtreg timeout factor. -- Thanks, Nick From daniel.fuchs at oracle.com Fri Aug 14 09:27:20 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Aug 2020 10:27:20 +0100 Subject: RFR(S): 8251517: [TESTBUG] com/sun/net/httpserver/bugs/B6393710.java does not scale socket timeout In-Reply-To: <85ft8priyn.fsf@nicgas01-pc.shanghai.arm.com> References: <85ft8priyn.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <5fda1255-b9a5-611c-c39c-15ce074ece59@oracle.com> Hi Nick, Looks good to me. But while you're at it, could you make the `ok` and `requests` fields volatile? best regards, -- daniel On 14/08/2020 04:42, Nick Gasson wrote: > Hi, > > Bug: http://cr.openjdk.java.net/~ngasson/8251517/webrev.0/ > Webrev: https://bugs.openjdk.java.net/browse/JDK-8251517 > > This case fails in our testing when run with -Xcomp on a fastdebug > build. The 5s socket read timeout is too short for this configuration. > Fix by scaling by the jtreg timeout factor. > > -- > Thanks, > Nick > From nick.gasson at arm.com Fri Aug 14 10:44:24 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 14 Aug 2020 18:44:24 +0800 Subject: RFR(S): 8251517: [TESTBUG] com/sun/net/httpserver/bugs/B6393710.java does not scale socket timeout In-Reply-To: <5fda1255-b9a5-611c-c39c-15ce074ece59@oracle.com> References: <85ft8priyn.fsf@nicgas01-pc.shanghai.arm.com> <5fda1255-b9a5-611c-c39c-15ce074ece59@oracle.com> Message-ID: <85d03tqzg7.fsf@nicgas01-pc.shanghai.arm.com> Hi Daniel, On 08/14/20 17:27 pm, Daniel Fuchs wrote: > > Looks good to me. But while you're at it, could you make > the `ok` and `requests` fields volatile? > Sure, this one ok to push? https://cr.openjdk.java.net/~ngasson/8251517/webrev.1/ -- Thanks, Nick From daniel.fuchs at oracle.com Fri Aug 14 11:42:34 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Aug 2020 12:42:34 +0100 Subject: RFR(S): 8251517: [TESTBUG] com/sun/net/httpserver/bugs/B6393710.java does not scale socket timeout In-Reply-To: <85d03tqzg7.fsf@nicgas01-pc.shanghai.arm.com> References: <85ft8priyn.fsf@nicgas01-pc.shanghai.arm.com> <5fda1255-b9a5-611c-c39c-15ce074ece59@oracle.com> <85d03tqzg7.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <72960f1c-bdb4-d813-a49c-c9fe6959c9f1@oracle.com> On 14/08/2020 11:44, Nick Gasson wrote: > Hi Daniel, > > On 08/14/20 17:27 pm, Daniel Fuchs wrote: >> >> Looks good to me. But while you're at it, could you make >> the `ok` and `requests` fields volatile? >> > > Sure, this one ok to push? > > https://cr.openjdk.java.net/~ngasson/8251517/webrev.1/ Looks fine! best regards, -- daniel > > -- > Thanks, > Nick > From evan.whelan at oracle.com Fri Aug 14 12:10:23 2020 From: evan.whelan at oracle.com (Evan Whelan) Date: Fri, 14 Aug 2020 12:10:23 +0000 (UTC) Subject: RFR 8133686: REOPEN JDK-8080659 : HttpURLConnection?s getHeaderFields method returns field values in reverse order Message-ID: <6899832b-45f9-4b13-be8c-eb12d8028914@default> Hi all, I'm Evan and I've just recently joined the Java Platform Group here in Oracle so this is my first time getting to interact with the OpenJDK Community. This is a request to review my fix for https://bugs.openjdk.java.net/browse/JDK-8133686 The webrev for this fix can be found at: http://cr.openjdk.java.net/~kravikumar/8133686/webrev.00/webrev/ The fix for this bug is straightforward and I don't believe that this change needs a CSR, as this change makes the source code conform to the RFC2616 spec, and does not introduce any behavioural changes. That being said, I welcome any differing thoughts! I look forward to your responses. Thanks, Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: From conor.cleary at oracle.com Fri Aug 14 14:37:36 2020 From: conor.cleary at oracle.com (Conor Cleary) Date: Fri, 14 Aug 2020 15:37:36 +0100 Subject: RFR[8246047]: 'Replace LinkedList impl in net.http.websocket.BuilderImpl' Message-ID: Hi all, Requesting some reviewers for a patch concerning JDK-8246047 'Replace LinkedList impl in net.http.websocket.BuilderImpl'. This patch replaces LinkedList data structures used in the net.http.websocket BuilderImpl class with ArrayLists. In particular, the 'headers' and 'subprotocols' Collections in the class are now assigned ArrayLists in the BuilderImpl constructors. Some justifications for this change are as follows: * Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same neighbourhood) * Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists * While insertion operations can be expensive (O(N) in the worst case), the 'headers' and 'subprotocols' lists are not modified after creation and so this is of minor concern Additional justifications or challenges to them are welcome! The general idea is that ArrayLists out-perform LinkedLists in this particular scenario. * webrev: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246047/webrevs/webrev.02/ * bug: https://bugs.openjdk.java.net/browse/JDK-8246047 Conor -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Aug 14 14:49:15 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Aug 2020 15:49:15 +0100 Subject: RFR[8246047]: 'Replace LinkedList impl in net.http.websocket.BuilderImpl' In-Reply-To: References: Message-ID: Hi Conor, Thanks for addressing this technical debt. I don't think this is correct. You transformed the immutable copy at line 137 into a shallow clone, since now both copies share the same mutable list. I suggest to revert the changes at lines: 66,67,144 and 145. (and that will be much simpler in the bargain :-) ) best regards, -- daniel On 14/08/2020 15:37, Conor Cleary wrote: > Hi all, > > Requesting some reviewers for a patch concerning JDK-8246047 'Replace > LinkedList impl in net.http.websocket.BuilderImpl'. This patch replaces > LinkedList data structures used in the net.http.websocket BuilderImpl > class with ArrayLists. In particular, the 'headers' and 'subprotocols' > Collections in the class are now assigned ArrayLists in the BuilderImpl > constructors. > > Some justifications for this change are as follows: > > * Sequential Access Times for ArrayLists are improved due to locality > of reference (i.e ArrayList elements stored in same neighbourhood) > * Get(index) operations are O(1) time complexity for ArrayLists as > opposed to worst-case O(N-1) for LinkedLists > * While insertion operations can be expensive (O(N) in the worst > case), the 'headers' and 'subprotocols' lists are not modified after > creation and so this is of minor concern > > Additional justifications or challenges to them are welcome! The general > idea is that ArrayLists out-perform LinkedLists in this particular scenario. > > * webrev: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246047/webrevs/webrev.02/ > * bug: https://bugs.openjdk.java.net/browse/JDK-8246047 > > > Conor > From daniel.fuchs at oracle.com Fri Aug 14 15:43:16 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Aug 2020 16:43:16 +0100 Subject: 8245462: HttpClient send throws InterruptedException when interrupted but does not cancel request In-Reply-To: <1c609b47-d23b-b063-0a64-4a6561b1ad39@oracle.com> References: <14613d53-0105-cc57-b082-7c2691a8be6e@oracle.com> <4a7b1202-f8d1-eb3f-fd45-6d9523d28bf3@oracle.com> <6dd0519f-242f-3c10-d87b-ede941bf6bfa@oracle.com> <7ec6590b-638e-bc0b-2ea3-52c94e2cfdd7@oracle.com> <58b7a5f8-00bf-34e0-e156-72a603c15961@oracle.com> <1c609b47-d23b-b063-0a64-4a6561b1ad39@oracle.com> Message-ID: <9b68ddff-68f4-b998-6a8d-81c1826b71cf@oracle.com> Hi, After discussion with Chris & Alan I have slightly reworded the API documentation, and ensured the MultiExchange is only weakly referenced from the MinimalFuture to avoid the risk of pinning the exchange in memory after it is no longer needed. Also I added a trivial test for the case where the thread is interrupted just before calling HttpClient::send. The new webrev is at: http://cr.openjdk.java.net/~dfuchs/webrev_8245462/webrev.03/ The generated API documentation for the HttpClient class can be seen at: http://cr.openjdk.java.net/~dfuchs/webrev_8245462/docs.03/java.net.http/java/net/http/HttpClient.html The CSR has been updated with the latest changes: https://bugs.openjdk.java.net/browse/JDK-8251312 best regards, -- daniel On 07/08/2020 19:19, Daniel Fuchs wrote: > Hi, > > Here is the new webrev that goes on top of the changes from > 8229822 (which are already pushed). > > http://cr.openjdk.java.net/~dfuchs/webrev_8245462/webrev.02/ > > I have also written the CSR: > https://bugs.openjdk.java.net/browse/JDK-8251312 > > feedback - and reviewers - welcome :-) > > best regards, > > -- daniel From conor.cleary at oracle.com Fri Aug 14 15:48:16 2020 From: conor.cleary at oracle.com (Conor Cleary) Date: Fri, 14 Aug 2020 16:48:16 +0100 Subject: RFR[8246047]: 'Replace LinkedList impl in net.http.websocket.BuilderImpl' In-Reply-To: References: Message-ID: <1a97e995-dfed-065b-f3e5-b9f73d335796@oracle.com> Thanks for the suggestion Daniel, looks much nicer without the casting in the immutableCopy function as well! I made a new patch with those reverted changes and it looks much nicer and still behaves as expected. webrev: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246047/webrevs/webrev.03/ Thanks! Conor On 14/08/2020 15:49, Daniel Fuchs wrote: > Hi Conor, > > Thanks for addressing this technical debt. > > I don't think this is correct. You transformed the immutable > copy at line 137 into a shallow clone, since now both copies > share the same mutable list. > > I suggest to revert the changes at lines: > > 66,67,144 and 145. > > (and that will be much simpler in the bargain :-) ) > > best regards, > > -- daniel > > > On 14/08/2020 15:37, Conor Cleary wrote: >> Hi all, >> >> Requesting some reviewers for a patch concerning JDK-8246047 'Replace >> LinkedList impl in net.http.websocket.BuilderImpl'. This patch >> replaces LinkedList data structures used in the net.http.websocket >> BuilderImpl class with ArrayLists. In particular, the 'headers' and >> 'subprotocols' Collections in the class are now assigned ArrayLists >> in the BuilderImpl constructors. >> >> Some justifications for this change are as follows: >> >> ? * Sequential Access Times for ArrayLists are improved due to locality >> ??? of reference (i.e ArrayList elements stored in same neighbourhood) >> ? * Get(index) operations are O(1) time complexity for ArrayLists as >> ??? opposed to worst-case O(N-1) for LinkedLists >> ? * While insertion operations can be expensive (O(N) in the worst >> ??? case), the 'headers' and 'subprotocols' lists are not modified after >> ??? creation and so this is of minor concern >> >> Additional justifications or challenges to them are welcome! The >> general idea is that ArrayLists out-perform LinkedLists in this >> particular scenario. >> >> ? * webrev: >> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246047/webrevs/webrev.02/ >> ? * bug: https://bugs.openjdk.java.net/browse/JDK-8246047 >> >> >> Conor >> > From chris.hegarty at oracle.com Fri Aug 14 15:53:39 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 14 Aug 2020 16:53:39 +0100 Subject: RFR[8246047]: 'Replace LinkedList impl in net.http.websocket.BuilderImpl' In-Reply-To: <1a97e995-dfed-065b-f3e5-b9f73d335796@oracle.com> References: <1a97e995-dfed-065b-f3e5-b9f73d335796@oracle.com> Message-ID: <182AA133-0B7E-4638-8CF0-0F2E1B9C1831@oracle.com> > On 14 Aug 2020, at 16:48, Conor Cleary wrote: > > Thanks for the suggestion Daniel, looks much nicer without the casting in the immutableCopy function as well! > > I made a new patch with those reverted changes and it looks much nicer and still behaves as expected. > > webrev: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246047/webrevs/webrev.03/ > LGTM. -Chris From Alan.Bateman at oracle.com Fri Aug 14 17:01:10 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Aug 2020 18:01:10 +0100 Subject: 8245462: HttpClient send throws InterruptedException when interrupted but does not cancel request In-Reply-To: <9b68ddff-68f4-b998-6a8d-81c1826b71cf@oracle.com> References: <14613d53-0105-cc57-b082-7c2691a8be6e@oracle.com> <4a7b1202-f8d1-eb3f-fd45-6d9523d28bf3@oracle.com> <6dd0519f-242f-3c10-d87b-ede941bf6bfa@oracle.com> <7ec6590b-638e-bc0b-2ea3-52c94e2cfdd7@oracle.com> <58b7a5f8-00bf-34e0-e156-72a603c15961@oracle.com> <1c609b47-d23b-b063-0a64-4a6561b1ad39@oracle.com> <9b68ddff-68f4-b998-6a8d-81c1826b71cf@oracle.com> Message-ID: <9e3d8bfe-03bb-33f2-dba2-a7c869797883@oracle.com> On 14/08/2020 16:43, Daniel Fuchs wrote: > Hi, > > After discussion with Chris & Alan I have slightly reworded > the API documentation, and ensured the MultiExchange is only > weakly referenced from the MinimalFuture to avoid the risk of > pinning the exchange in memory after it is no longer needed. > > Also I added a trivial test for the case where the thread is > interrupted just before calling HttpClient::send. > > The new webrev is at: > http://cr.openjdk.java.net/~dfuchs/webrev_8245462/webrev.03/ > > The generated API documentation for the HttpClient class can > be seen at: > http://cr.openjdk.java.net/~dfuchs/webrev_8245462/docs.03/java.net.http/java/net/http/HttpClient.html > > > The CSR has been updated with the latest changes: > https://bugs.openjdk.java.net/browse/JDK-8251312 I'm happy with the update to the API docs and have added myself as Reviewer on the CSR. -Alan From daniel.fuchs at oracle.com Fri Aug 14 17:59:48 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Aug 2020 18:59:48 +0100 Subject: RFR[8246047]: 'Replace LinkedList impl in net.http.websocket.BuilderImpl' In-Reply-To: <1a97e995-dfed-065b-f3e5-b9f73d335796@oracle.com> References: <1a97e995-dfed-065b-f3e5-b9f73d335796@oracle.com> Message-ID: <08a46650-994f-b9d8-9341-1f1b0d9461e5@oracle.com> On 14/08/2020 16:48, Conor Cleary wrote: > Thanks for the suggestion Daniel, looks much nicer without the casting > in the immutableCopy function as well! > > I made a new patch with those reverted changes and it looks much nicer > and still behaves as expected. > > webrev: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246047/webrevs/webrev.03/ LGTM! best regards, -- daniel From patrick.concannon at oracle.com Mon Aug 17 16:49:58 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Mon, 17 Aug 2020 17:49:58 +0100 Subject: =?utf-8?Q?Re=3A_RFR=5B8189744=5D=3A_=27Deprecate_the_JDK-specific?= =?utf-8?Q?_API_for_setting_socket_options=2C_jdk=2Enet=2ESockets=E2=80=99?= In-Reply-To: <6FBB3567-5C4A-451F-86FA-8DDEFA442901@oracle.com> References: <51947503-05BF-4684-A8A5-B96FF283FD29@oracle.com> <02B96BD3-F707-440D-A2CD-D911F31295B2@oracle.com> <6FBB3567-5C4A-451F-86FA-8DDEFA442901@oracle.com> Message-ID: <8B003A94-82AC-41EA-B4D4-6DAF7747AAC6@oracle.com> Hi, On JBS, Alan suggested terminally deprecating `Sockets.supportedOptions(Class)` due to its flaws and under specification so I?ve re-opened the CSR and marked this method for removal. As there is a possibility that `jdk.net.Sockets` may come back into service in a future release I?ve left the other changes as they are. You can view this update in the new webrev below. webrev: http://cr.openjdk.java.net/~pconcannon/8189744/webrevs/webrev.01/ CSR: https://bugs.openjdk.java.net/browse/JDK-8251532 Kind regards, Patrick > On 13 Aug 2020, at 14:44, Chris Hegarty wrote: > > > >> On 13 Aug 2020, at 14:08, Patrick Concannon wrote: >> >> Hi Daniel, >> >> Thanks for taking a look. >> >> Here is a link to the CSR: https://bugs.openjdk.java.net/browse/JDK-8251532 > > LGTM. > > -Chris. From daniel.fuchs at oracle.com Mon Aug 17 17:21:48 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 17 Aug 2020 18:21:48 +0100 Subject: =?UTF-8?Q?Re=3a_RFR=5b8189744=5d=3a_=27Deprecate_the_JDK-specific_A?= =?UTF-8?Q?PI_for_setting_socket_options=2c_jdk=2enet=2eSockets=e2=80=99?= In-Reply-To: <8B003A94-82AC-41EA-B4D4-6DAF7747AAC6@oracle.com> References: <51947503-05BF-4684-A8A5-B96FF283FD29@oracle.com> <02B96BD3-F707-440D-A2CD-D911F31295B2@oracle.com> <6FBB3567-5C4A-451F-86FA-8DDEFA442901@oracle.com> <8B003A94-82AC-41EA-B4D4-6DAF7747AAC6@oracle.com> Message-ID: <57cbfca2-7d78-914d-5182-0584b06cd42a@oracle.com> Looks good to me Patrick! best regards, -- daniel On 17/08/2020 17:49, Patrick Concannon wrote: > Hi, > > On JBS, Alan suggested terminally deprecating `Sockets.supportedOptions(Class)` due to its flaws and under specification so I?ve re-opened the CSR and marked this method for removal. As there is a possibility that `jdk.net.Sockets` may come back into service in a future release I?ve left the other changes as they are. > > You can view this update in the new webrev below. > > webrev:http://cr.openjdk.java.net/~pconcannon/8189744/webrevs/webrev.01/ > CSR:https://bugs.openjdk.java.net/browse/JDK-8251532 > > > Kind regards, > Patrick > From rahul.r.yadav at oracle.com Tue Aug 18 09:21:07 2020 From: rahul.r.yadav at oracle.com (Rahul Yadav) Date: Tue, 18 Aug 2020 10:21:07 +0100 Subject: RFR 8251715 : Throw UncheckedIOException in place of InternalError when HttpClient fails due to unavailability of underlying resources required by SSLContext. In-Reply-To: <62bfbb56-4127-eeb6-29a8-a094919a389b@oracle.com> References: <62bfbb56-4127-eeb6-29a8-a094919a389b@oracle.com> Message-ID: <6683ffe5-bb21-6adb-b0ac-29b8374c12ab@oracle.com> Hello, Request to have my fix reviewed for issue: JDK-8251715:? Throw UncheckedIOException in place of InternalError when HttpClient fails due to unavailability of underlying resources required by SSLContext. This fix updates jdk.internal.net.http.HttpClientImpl to throw an UncheckedIOException instead of InternalError, in this case, when `SSLContext.getDefault()` fails due to unavailability of underlying resources. Issue:? https://bugs.openjdk.java.net/browse/JDK-8251715 webrev: http://cr.openjdk.java.net/~ryadav/webrev_8251715/index.html - rahul From daniel.fuchs at oracle.com Tue Aug 18 09:39:59 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 18 Aug 2020 10:39:59 +0100 Subject: RFR 8251715 : Throw UncheckedIOException in place of InternalError when HttpClient fails due to unavailability of underlying resources required by SSLContext. In-Reply-To: <6683ffe5-bb21-6adb-b0ac-29b8374c12ab@oracle.com> References: <62bfbb56-4127-eeb6-29a8-a094919a389b@oracle.com> <6683ffe5-bb21-6adb-b0ac-29b8374c12ab@oracle.com> Message-ID: <1cb77f7c-01e0-3781-a794-da2709b4616e@oracle.com> Hi Rahul, Looks fine to me - but just one detail in the test: maybe you should use `expectThrows` rather than `assertThrows` and then double check that the exception you get is the one you expect. best regards, -- daniel On 18/08/2020 10:21, Rahul Yadav wrote: > Hello, > > Request to have my fix reviewed for issue: > > JDK-8251715:? Throw UncheckedIOException in place of InternalError when > HttpClient fails due to unavailability of underlying resources required > by SSLContext. > > This fix updates jdk.internal.net.http.HttpClientImpl to throw an > UncheckedIOException instead of InternalError, > in this case, when `SSLContext.getDefault()` fails due to unavailability > of underlying resources. > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8251715 > webrev: http://cr.openjdk.java.net/~ryadav/webrev_8251715/index.html > > > - rahul From rahul.r.yadav at oracle.com Tue Aug 18 11:35:56 2020 From: rahul.r.yadav at oracle.com (Rahul Yadav) Date: Tue, 18 Aug 2020 12:35:56 +0100 Subject: RFR 8251715 : Throw UncheckedIOException in place of InternalError when HttpClient fails due to unavailability of underlying resources required by SSLContext. In-Reply-To: <1cb77f7c-01e0-3781-a794-da2709b4616e@oracle.com> References: <62bfbb56-4127-eeb6-29a8-a094919a389b@oracle.com> <6683ffe5-bb21-6adb-b0ac-29b8374c12ab@oracle.com> <1cb77f7c-01e0-3781-a794-da2709b4616e@oracle.com> Message-ID: <27a5fc02-b291-699a-b5eb-a93d44f40cf4@oracle.com> Good point Daniel, i have included the feedback , updated webrev. - rahul On 18/08/2020 10:39, Daniel Fuchs wrote: > Hi Rahul, > > Looks fine to me - but just one detail in the test: maybe you should > use `expectThrows` rather than `assertThrows` and then double check > that the exception you get is the one you expect. > > best regards, > > -- daniel > > On 18/08/2020 10:21, Rahul Yadav wrote: >> Hello, >> >> Request to have my fix reviewed for issue: >> >> JDK-8251715:? Throw UncheckedIOException in place of InternalError >> when HttpClient fails due to unavailability of underlying resources >> required by SSLContext. >> >> This fix updates jdk.internal.net.http.HttpClientImpl to throw an >> UncheckedIOException instead of InternalError, >> in this case, when `SSLContext.getDefault()` fails due to >> unavailability of underlying resources. >> >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8251715 >> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8251715/index.html >> >> >> - rahul > From chris.hegarty at oracle.com Tue Aug 18 13:28:36 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 18 Aug 2020 14:28:36 +0100 Subject: RFR 8251715 : Throw UncheckedIOException in place of InternalError when HttpClient fails due to unavailability of underlying resources required by SSLContext. In-Reply-To: <6683ffe5-bb21-6adb-b0ac-29b8374c12ab@oracle.com> References: <62bfbb56-4127-eeb6-29a8-a094919a389b@oracle.com> <6683ffe5-bb21-6adb-b0ac-29b8374c12ab@oracle.com> Message-ID: <6E30751F-D106-4D2B-83BA-7EDD6528655E@oracle.com> Rahul, > On 18 Aug 2020, at 10:21, Rahul Yadav wrote: > > ... > > Issue: https://bugs.openjdk.java.net/browse/JDK-8251715 > webrev: http://cr.openjdk.java.net/~ryadav/webrev_8251715/index.html > This looks good. In the test, i see that you have used expectThrows. expectThrows returns the exception ( after the type check has occurred ), it is possible to do further checking on it, like say for example examining its cause, or exception message. Unless you do further checking or diagnostic output, then there is not much difference between assertThrows and expectThrows. Maybe you mean to check the cause for NoSuchAlgorithmException? -Chris. From daniel.fuchs at oracle.com Tue Aug 18 14:15:44 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 18 Aug 2020 15:15:44 +0100 Subject: RFR 8251715 : Throw UncheckedIOException in place of InternalError when HttpClient fails due to unavailability of underlying resources required by SSLContext. In-Reply-To: <27a5fc02-b291-699a-b5eb-a93d44f40cf4@oracle.com> References: <62bfbb56-4127-eeb6-29a8-a094919a389b@oracle.com> <6683ffe5-bb21-6adb-b0ac-29b8374c12ab@oracle.com> <1cb77f7c-01e0-3781-a794-da2709b4616e@oracle.com> <27a5fc02-b291-699a-b5eb-a93d44f40cf4@oracle.com> Message-ID: OK - only checking that it's an UncheckedIOException is probably sufficient there (though you could have done that with asserThrows. Reviewed. -- daniel On 18/08/2020 12:35, Rahul Yadav wrote: > Good point Daniel, i have included the feedback , updated webrev. > > - rahul > > O From rahul.r.yadav at oracle.com Tue Aug 18 15:06:47 2020 From: rahul.r.yadav at oracle.com (Rahul Yadav) Date: Tue, 18 Aug 2020 16:06:47 +0100 Subject: RFR 8251715 : Throw UncheckedIOException in place of InternalError when HttpClient fails due to unavailability of underlying resources required by SSLContext. In-Reply-To: <6E30751F-D106-4D2B-83BA-7EDD6528655E@oracle.com> References: <62bfbb56-4127-eeb6-29a8-a094919a389b@oracle.com> <6683ffe5-bb21-6adb-b0ac-29b8374c12ab@oracle.com> <6E30751F-D106-4D2B-83BA-7EDD6528655E@oracle.com> Message-ID: <7824de39-8105-67b4-47a7-70bab201ca7b@oracle.com> Hi Chris, Thanks for the feedback, this improves the test, i have included your feedback and updated webrev. - rahul On 18/08/2020 14:28, Chris Hegarty wrote: > Rahul, > >> On 18 Aug 2020, at 10:21, Rahul Yadav wrote: >> >> ... >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8251715 >> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8251715/index.html >> > This looks good. > > In the test, i see that you have used expectThrows. expectThrows returns the exception ( after the type check has occurred ), it is possible to do further checking on it, like say for example examining its cause, or exception message. Unless you do further checking or diagnostic output, then there is not much difference between assertThrows and expectThrows. Maybe you mean to check the cause for NoSuchAlgorithmException? > > -Chris. > From chris.hegarty at oracle.com Tue Aug 18 15:15:37 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 18 Aug 2020 08:15:37 -0700 (PDT) Subject: RFR 8251715 : Throw UncheckedIOException in place of InternalError when HttpClient fails due to unavailability of underlying resources required by SSLContext. In-Reply-To: <7824de39-8105-67b4-47a7-70bab201ca7b@oracle.com> References: <62bfbb56-4127-eeb6-29a8-a094919a389b@oracle.com> <6683ffe5-bb21-6adb-b0ac-29b8374c12ab@oracle.com> <6E30751F-D106-4D2B-83BA-7EDD6528655E@oracle.com> <7824de39-8105-67b4-47a7-70bab201ca7b@oracle.com> Message-ID: <5C1C6F13-029E-42B4-A1AF-AFB733679ACC@oracle.com> > On 18 Aug 2020, at 16:06, Rahul Yadav wrote: > > Hi Chris, > > Thanks for the feedback, this improves the test, i have included your feedback and updated webrev. Looks better. Before pushing, please check the indentation ( as it appears a little off in the webrev ), and print the exception cause in the error message (if not the excepted type). No need for further reviews from me. -Chris. > - rahul > > On 18/08/2020 14:28, Chris Hegarty wrote: >> Rahul, >> >>> On 18 Aug 2020, at 10:21, Rahul Yadav wrote: >>> >>> ... >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8251715 >>> webrev: http://cr.openjdk.java.net/~ryadav/webrev_8251715/index.html >>> >> This looks good. >> >> In the test, i see that you have used expectThrows. expectThrows returns the exception ( after the type check has occurred ), it is possible to do further checking on it, like say for example examining its cause, or exception message. Unless you do further checking or diagnostic output, then there is not much difference between assertThrows and expectThrows. Maybe you mean to check the cause for NoSuchAlgorithmException? >> >> -Chris. >> > From julia.boes at oracle.com Tue Aug 18 17:02:37 2020 From: julia.boes at oracle.com (Julia Boes) Date: Tue, 18 Aug 2020 18:02:37 +0100 Subject: Fix for Javadoc errors in java.base In-Reply-To: References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> Message-ID: <6b31a7d4-3bcd-2c8d-2f3c-4158047c3e31@oracle.com> Hi, The two changes below still need to be reviewed. Any takers? Cheers, Julia > --- > old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 > 23:55:41.953638446 +0530 > +++ > new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 > 23:55:41.445619497 +0530 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -208,7 +208,7 @@ > ? ? ? * > ? ? ? * @return a CallSite, which, when invoked, will return an > instance of the > ? ? ? * functional interface > - ? ? * @throws ReflectiveOperationException > + ? ? * @throws LambdaConversionException > ? ? ? */ > ? ? ?abstract CallSite buildCallSite() > ? ? ? ? ? ? ?throws LambdaConversionException; > --- > old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 > 23:55:42.977677096 +0530 > +++ > new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 > 23:55:42.473658062 +0530 > @@ -200,7 +200,6 @@ > ? ? ? * > ? ? ? * @return a CallSite, which, when invoked, will return an > instance of the > ? ? ? * functional interface > - ? ? * @throws ReflectiveOperationException > ? ? ? * @throws LambdaConversionException If properly formed > functional interface > ? ? ? * is not found > ? ? ? */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Aug 18 17:05:12 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 18 Aug 2020 10:05:12 -0700 Subject: Fix for Javadoc errors in java.base In-Reply-To: <6b31a7d4-3bcd-2c8d-2f3c-4158047c3e31@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> <6b31a7d4-3bcd-2c8d-2f3c-4158047c3e31@oracle.com> Message-ID: <4ffac099-db84-c782-2e14-75bde259e86d@oracle.com> Looks fine. Thanks Mandy On 8/18/20 10:02 AM, Julia Boes wrote: > > Hi, > > The two changes below still need to be reviewed. Any takers? > > Cheers, > > Julia > >> --- >> old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 >> 23:55:41.953638446 +0530 >> +++ >> new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 >> 23:55:41.445619497 +0530 >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All >> rights reserved. >> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ? * >> ? * This code is free software; you can redistribute it and/or modify it >> @@ -208,7 +208,7 @@ >> ? ? ? * >> ? ? ? * @return a CallSite, which, when invoked, will return an >> instance of the >> ? ? ? * functional interface >> - ? ? * @throws ReflectiveOperationException >> + ? ? * @throws LambdaConversionException >> ? ? ? */ >> ? ? ?abstract CallSite buildCallSite() >> ? ? ? ? ? ? ?throws LambdaConversionException; >> --- >> old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 >> 23:55:42.977677096 +0530 >> +++ >> new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 >> 23:55:42.473658062 +0530 >> @@ -200,7 +200,6 @@ >> ? ? ? * >> ? ? ? * @return a CallSite, which, when invoked, will return an >> instance of the >> ? ? ? * functional interface >> - ? ? * @throws ReflectiveOperationException >> ? ? ? * @throws LambdaConversionException If properly formed >> functional interface >> ? ? ? * is not found >> ? ? ? */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.whelan at oracle.com Wed Aug 19 08:39:57 2020 From: evan.whelan at oracle.com (Evan Whelan) Date: Wed, 19 Aug 2020 01:39:57 -0700 (PDT) Subject: =?utf-8?B?UkZSIDgyNTA3NDg6IERvYyBvZiBVUg==?= =?utf-8?B?TOKAiyhTdHJpbmcsIFN0cmluZywgaW50?= =?utf-8?B?LCBTdHJpbmcsIFVSTFN0cmVhbUhhbmRsZXIpIGRvZXMgbm90IHVzZSBsaW5r?= Message-ID: <517090c1-4d03-4e98-bc69-36a1b328ae67@default> Hi all, ? I have another small fix for net-dev reviewers. This is a small fix to the java/net/URL.java documentation to add a link to one of the constructors. ? --- old/open/src/java.base/share/classes/java/net/URL.java?? 2020-08-18 14:53:33.886033182 +0000 +++ new/open/src/java.base/share/classes/java/net/URL.java?? 2020-08-18 14:53:33.770030806 +0000 @@ -397,8 +397,8 @@ ????? * a {@code handler} of {@code null} indicates that the URL ????? * should use a default stream handler for the protocol, as outlined ????? * for: -???? *???? java.net.URL#URL(java.lang.String, java.lang.String, int, -???? *????????????????????? java.lang.String) +???? *???? {@link java.net.URL#URL(java.lang.String, java.lang.String, int, +???? *????????????????????? java.lang.String)} ????? * ????? *

If the handler is not null and there is a security manager, ????? * the security manager's {@code checkPermission} ? ? JBS Link: https://bugs.openjdk.java.net/browse/JDK-8250748 ? Thank you in advance everyone. Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Aug 19 08:51:26 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 19 Aug 2020 09:51:26 +0100 Subject: =?UTF-8?Q?Re=3a_RFR_8250748=3a_Doc_of_URL=e2=80=8b=28String=2c_Stri?= =?UTF-8?Q?ng=2c_int=2c_String=2c_URLStreamHandler=29_does_not_use_link?= In-Reply-To: <517090c1-4d03-4e98-bc69-36a1b328ae67@default> References: <517090c1-4d03-4e98-bc69-36a1b328ae67@default> Message-ID: <0f6053d6-1e3f-d467-6f73-1a3cd0215422@oracle.com> Hi Evan, Looks good to me! best regards, -- daniel On 19/08/2020 09:39, Evan Whelan wrote: > Hi all, > > I have another small fix for net-dev reviewers. > > This is a small fix to the java/net/URL.java documentation to add a link > to one of the constructors. > > --- old/open/src/java.base/share/classes/java/net/URL.java?? 2020-08-18 > 14:53:33.886033182 +0000 > > +++ new/open/src/java.base/share/classes/java/net/URL.java?? 2020-08-18 > 14:53:33.770030806 +0000 > > @@ -397,8 +397,8 @@ > > ????? * a {@code handler} of {@code null} indicates that the URL > > ????? * should use a default stream handler for the protocol, as outlined > > ????? * for: > > -???? *???? java.net.URL#URL(java.lang.String, java.lang.String, int, > > -???? *????????????????????? java.lang.String) > > +???? *???? {@link java.net.URL#URL(java.lang.String, java.lang.String, int, > > +???? *????????????????????? java.lang.String)} > > ????? * > > ????? *

If the handler is not null and there is a security manager, > > ????? * the security manager's {@code checkPermission} > > JBS Link: https://bugs.openjdk.java.net/browse/JDK-8250748 > > Thank you in advance everyone. > > Evan > From daniel.fuchs at oracle.com Wed Aug 19 09:10:27 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 19 Aug 2020 10:10:27 +0100 Subject: RFR 8133686: REOPEN JDK-8080659 : HttpURLConnection?s getHeaderFields method returns field values in reverse order In-Reply-To: <6899832b-45f9-4b13-be8c-eb12d8028914@default> References: <6899832b-45f9-4b13-be8c-eb12d8028914@default> Message-ID: <9c5bc79b-be8a-0480-28de-25e37aceed56@oracle.com> Hi Evan, On 14/08/2020 13:10, Evan Whelan wrote: > Hi all, > > I?m Evan and I?ve just recently joined the Java Platform Group here in > Oracle so this is my first time getting to interact with the OpenJDK > Community. > > This is a request to review my fix for > https://bugs.openjdk.java.net/browse/JDK-8133686 > > The webrev for this fix can be found at: > http://cr.openjdk.java.net/~kravikumar/8133686/webrev.00/webrev/ The fix looks good to me. > The fix for this bug is straightforward and I don?t believe that this > change needs a CSR, as this change makes the source code conform to the > RFC2616 spec, and does not introduce any behavioural changes. Well - there is obviously a behavioral change or there would be no need for a fix ;-) I see that you have written a release note. I don't think a CSR is needed either, but I would welcome a second opinion too ! best regards, -- daniel > > That being said, I welcome any differing thoughts! > > I look forward to your responses. > > Thanks, > > Evan > From Roger.Riggs at oracle.com Wed Aug 19 15:40:44 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 19 Aug 2020 11:40:44 -0400 Subject: Fix for Javadoc errors in java.base In-Reply-To: <6b31a7d4-3bcd-2c8d-2f3c-4158047c3e31@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> <6b31a7d4-3bcd-2c8d-2f3c-4158047c3e31@oracle.com> Message-ID: <00ffb7f0-5301-1f34-93e7-8e3249845434@oracle.com> Looks fine Julia On 8/18/20 1:02 PM, Julia Boes wrote: > > Hi, > > The two changes below still need to be reviewed. Any takers? > > Cheers, > > Julia > >> --- >> old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 >> 23:55:41.953638446 +0530 >> +++ >> new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 >> 23:55:41.445619497 +0530 >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All >> rights reserved. >> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ? * >> ? * This code is free software; you can redistribute it and/or modify it >> @@ -208,7 +208,7 @@ >> ? ? ? * >> ? ? ? * @return a CallSite, which, when invoked, will return an >> instance of the >> ? ? ? * functional interface >> - ? ? * @throws ReflectiveOperationException >> + ? ? * @throws LambdaConversionException >> ? ? ? */ >> ? ? ?abstract CallSite buildCallSite() >> ? ? ? ? ? ? ?throws LambdaConversionException; >> --- >> old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 >> 23:55:42.977677096 +0530 >> +++ >> new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 >> 23:55:42.473658062 +0530 >> @@ -200,7 +200,6 @@ >> ? ? ? * >> ? ? ? * @return a CallSite, which, when invoked, will return an >> instance of the >> ? ? ? * functional interface >> - ? ? * @throws ReflectiveOperationException >> ? ? ? * @throws LambdaConversionException If properly formed >> functional interface >> ? ? ? * is not found >> ? ? ? */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.whelan at oracle.com Thu Aug 20 16:06:47 2020 From: evan.whelan at oracle.com (Evan Whelan) Date: Thu, 20 Aug 2020 09:06:47 -0700 (PDT) Subject: RFR 8133686: REOPEN JDK-8080659 : HttpURLConnection?s getHeaderFields method returns field values in reverse order In-Reply-To: <6899832b-45f9-4b13-be8c-eb12d8028914@default> References: <6899832b-45f9-4b13-be8c-eb12d8028914@default> Message-ID: <6eca045c-4582-46e2-9db6-ac4d8bb865eb@default> Hi all, A revised webrev for this change can be found at http://cr.openjdk.java.net/~coffeys/evwhelan/8133686/webrev/ This revision fixes a test that failed as a result of the source change. If anyone has any further thoughts on whether this change needs a CSR, I would love to hear them. Thanks in advance, Evan From: Evan Whelan Sent: Friday 14 August 2020 13:10 To: net-dev at openjdk.java.net Subject: RFR 8133686: REOPEN JDK-8080659 : HttpURLConnection?s getHeaderFields method returns field values in reverse order Hi all, I'm Evan and I've just recently joined the Java Platform Group here in Oracle so this is my first time getting to interact with the OpenJDK Community. This is a request to review my fix for https://bugs.openjdk.java.net/browse/JDK-8133686 The webrev for this fix can be found at: http://cr.openjdk.java.net/~kravikumar/8133686/webrev.00/webrev/ The fix for this bug is straightforward and I don't believe that this change needs a CSR, as this change makes the source code conform to the RFC2616 spec, and does not introduce any behavioural changes. That being said, I welcome any differing thoughts! I look forward to your responses. Thanks, Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Aug 26 14:45:55 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 26 Aug 2020 15:45:55 +0100 Subject: 8252374: Add a new factory method to concatenate a sequence of BodyPublisher instances into a single publisher. Message-ID: <3b012721-2635-4db0-560f-6a93f8d02a0e@oracle.com> Hi, Please find below a fix for: 8252374: Add a new factory method to concatenate a sequence of BodyPublisher instances into a single publisher. https://bugs.openjdk.java.net/browse/JDK-8252374 Draft CSR: https://bugs.openjdk.java.net/browse/JDK-8252382 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8252374/webrev.00/ best regards, -- daniel From rahul.r.yadav at oracle.com Thu Aug 27 13:11:16 2020 From: rahul.r.yadav at oracle.com (Rahul Yadav) Date: Thu, 27 Aug 2020 14:11:16 +0100 Subject: RFR 8245308 : Replace ThreadLocalCoders decoder/encoder cache in java.net.URI In-Reply-To: References: Message-ID: <19a94ba7-eb51-dcec-3af0-2c5edf696efe@oracle.com> Hello, Request to have my fix reviewed for issue: JDK-8245308:? Replace ThreadLocalCoders decoder/encoder cache in java.net.URI. This fix updates java.net.URI, replaces the ThreadLocalCoders optimization. The benchmark results indicate no impact, optimization can be replaced.The results of benchmark are provided below and benchmark included in webrev. Before Benchmark????????????????????? (iterations)? Mode? Cnt?? Score Error? Units ThreadLocalURI.uriDecoderTest?????????? 100? avgt?? 25?? 0.258 ? 0.014? us/op ThreadLocalURI.uriEncoderTest?????????? 100? avgt?? 25? 35.540 ? 1.082? us/op After Benchmark????????????????????? (iterations)? Mode? Cnt?? Score Error? Units ThreadLocalURI.uriDecoderTest?????????? 100? avgt?? 25?? 0.247 ? 0.005? us/op ThreadLocalURI.uriEncoderTest?????????? 100? avgt?? 25? 37.231 ? 0.669? us/op Issue:? https://bugs.openjdk.java.net/browse/JDK-8245308 webrev: https://cr.openjdk.java.net/~ryadav/webrev_8245308/index.html - rahul From Alan.Bateman at oracle.com Thu Aug 27 14:11:24 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Aug 2020 15:11:24 +0100 Subject: RFR 8245308 : Replace ThreadLocalCoders decoder/encoder cache in java.net.URI In-Reply-To: <19a94ba7-eb51-dcec-3af0-2c5edf696efe@oracle.com> References: <19a94ba7-eb51-dcec-3af0-2c5edf696efe@oracle.com> Message-ID: <7c47f4ef-2ba8-fb84-11c8-986ca16a171a@oracle.com> On 27/08/2020 14:11, Rahul Yadav wrote: > Hello, > > Request to have my fix reviewed for issue: > > JDK-8245308:? Replace ThreadLocalCoders decoder/encoder cache in > java.net.URI. > > This fix updates java.net.URI, replaces the ThreadLocalCoders > optimization. > The benchmark results indicate no impact, optimization can be > replaced.The results of > benchmark are provided below and benchmark included in webrev. > > Before > > Benchmark????????????????????? (iterations)? Mode? Cnt?? Score Error? > Units > ThreadLocalURI.uriDecoderTest?????????? 100? avgt?? 25?? 0.258 ? > 0.014? us/op > ThreadLocalURI.uriEncoderTest?????????? 100? avgt?? 25? 35.540 ? > 1.082? us/op > > After > > Benchmark????????????????????? (iterations)? Mode? Cnt?? Score Error? > Units > ThreadLocalURI.uriDecoderTest?????????? 100? avgt?? 25?? 0.247 ? > 0.005? us/op > ThreadLocalURI.uriEncoderTest?????????? 100? avgt?? 25? 37.231 ? > 0.669? us/op > > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8245308 > webrev: https://cr.openjdk.java.net/~ryadav/webrev_8245308/index.html The quote method is creating the UTF-8 encoder eagerly, I guess I would expect it to only create this encoder when the input has non-ASCII chars, meaning it can be created lazily. Otherwise the change to URI looks okay to me. For the micro, I'm curious if iterations is needed. -Alan From claes.redestad at oracle.com Thu Aug 27 14:54:43 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 27 Aug 2020 16:54:43 +0200 Subject: RFR 8245308 : Replace ThreadLocalCoders decoder/encoder cache in java.net.URI In-Reply-To: <7c47f4ef-2ba8-fb84-11c8-986ca16a171a@oracle.com> References: <19a94ba7-eb51-dcec-3af0-2c5edf696efe@oracle.com> <7c47f4ef-2ba8-fb84-11c8-986ca16a171a@oracle.com> Message-ID: <50f40994-657c-ebd8-fe3c-e9c27e2b1f25@oracle.com> On 2020-08-27 16:11, Alan Bateman wrote: > > For the micro, I'm curious if iterations is needed. I'd say the canonical JMH way of doing these might be something as simple as this: @Benchmark public URI encodeURI() throws URISyntaxException { return new URI("http", "\u00A0", "\u00A0"); } @Benchmark public String decodeURI() throws URISyntaxException { return decoderUri.getPath(); } Sometimes for very simple micros like this this means the workload gets inlined so aggressively that you no longer measure what is likely to happen in the real world, and it's then not uncommon to force the benchmark method to not be inlined up into the JMH framework by annotating them with this: @CompilerControl(CompilerControl.Mode.DONT_INLINE) See for example org/openjdk/bench/java/util/ImmutableColls.java If you run with these suggestions you'll only one have encode/decode per iteration, so you might want to change output to nanoseconds, i.e.: @OutputTimeUnit(TimeUnit.NANOSECONDS) Thanks! /Claes From daniel.fuchs at oracle.com Thu Aug 27 14:58:54 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 27 Aug 2020 15:58:54 +0100 Subject: RFR 8245308 : Replace ThreadLocalCoders decoder/encoder cache in java.net.URI In-Reply-To: <19a94ba7-eb51-dcec-3af0-2c5edf696efe@oracle.com> References: <19a94ba7-eb51-dcec-3af0-2c5edf696efe@oracle.com> Message-ID: Hi Rahul, The code changes look good to me but the uriDecoderTest needs some working. The reason is that the decoded path is cached in the URI, so only the first call to getPath() will decode it. The following calls will just return the cached value. I also believe you should remove the inner loop - it probably serves no purpose, and possibly find a way to pass a fresh URI to each invocation of the uriDecoderTest method. I am not 100% sure on how to achieve that with JMH though, but hopefully there's some way to do that. best regards, -- daniel On 27/08/2020 14:11, Rahul Yadav wrote: > Hello, > > Request to have my fix reviewed for issue: > > JDK-8245308:? Replace ThreadLocalCoders decoder/encoder cache in > java.net.URI. > > This fix updates java.net.URI, replaces the ThreadLocalCoders optimization. > The benchmark results indicate no impact, optimization can be > replaced.The results of > benchmark are provided below and benchmark included in webrev. > > Before > > Benchmark????????????????????? (iterations)? Mode? Cnt?? Score Error? Units > ThreadLocalURI.uriDecoderTest?????????? 100? avgt?? 25?? 0.258 ? 0.014 > us/op > ThreadLocalURI.uriEncoderTest?????????? 100? avgt?? 25? 35.540 ? 1.082 > us/op > > After > > Benchmark????????????????????? (iterations)? Mode? Cnt?? Score Error? Units > ThreadLocalURI.uriDecoderTest?????????? 100? avgt?? 25?? 0.247 ? 0.005 > us/op > ThreadLocalURI.uriEncoderTest?????????? 100? avgt?? 25? 37.231 ? 0.669 > us/op > > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8245308 > webrev: https://cr.openjdk.java.net/~ryadav/webrev_8245308/index.html > > - rahul From chris.hegarty at oracle.com Thu Aug 27 16:01:39 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 27 Aug 2020 17:01:39 +0100 Subject: 8245462: HttpClient send throws InterruptedException when interrupted but does not cancel request In-Reply-To: <9b68ddff-68f4-b998-6a8d-81c1826b71cf@oracle.com> References: <14613d53-0105-cc57-b082-7c2691a8be6e@oracle.com> <4a7b1202-f8d1-eb3f-fd45-6d9523d28bf3@oracle.com> <6dd0519f-242f-3c10-d87b-ede941bf6bfa@oracle.com> <7ec6590b-638e-bc0b-2ea3-52c94e2cfdd7@oracle.com> <58b7a5f8-00bf-34e0-e156-72a603c15961@oracle.com> <1c609b47-d23b-b063-0a64-4a6561b1ad39@oracle.com> <9b68ddff-68f4-b998-6a8d-81c1826b71cf@oracle.com> Message-ID: <9A561FE3-4EED-4F68-8E24-E2B00A5F9C42@oracle.com> Daniel, > On 14 Aug 2020, at 16:43, Daniel Fuchs wrote: > > Hi, > > After discussion with Chris & Alan I have slightly reworded > the API documentation, and ensured the MultiExchange is only > weakly referenced from the MinimalFuture to avoid the risk of > pinning the exchange in memory after it is no longer needed. > > Also I added a trivial test for the case where the thread is > interrupted just before calling HttpClient::send. > > The new webrev is at: > http://cr.openjdk.java.net/~dfuchs/webrev_8245462/webrev.03/ I provided some comments to you on a previous iteration, they seem to be addressed in this latest version. Looks good to me. -Chris. From rahul.r.yadav at oracle.com Thu Aug 27 18:14:04 2020 From: rahul.r.yadav at oracle.com (Rahul Yadav) Date: Thu, 27 Aug 2020 19:14:04 +0100 Subject: RFR 8245308 : Replace ThreadLocalCoders decoder/encoder cache in java.net.URI In-Reply-To: References: <19a94ba7-eb51-dcec-3af0-2c5edf696efe@oracle.com> Message-ID: <2e482f50-aaa1-ca7b-e0d1-5bc46b2fca81@oracle.com> Thank you all for the feedback. I have included feedback and updated webrev. Before : Benchmark????????????????????????? Mode? Cnt??? Score??? Error Units ThreadLocalURI.uriDecoderBaseline? avgt?? 25? 556.315 ? 23.389 ns/op ThreadLocalURI.uriDecoderTest????? avgt?? 25? 728.413 ? 19.833 ns/op ThreadLocalURI.uriEncoderTest????? avgt?? 25? 337.042 ?? 8.304 ns/op After : Benchmark????????????????????????? Mode? Cnt??? Score??? Error Units ThreadLocalURI.uriDecoderBaseline? avgt?? 25? 578.108 ?? 9.829 ns/op ThreadLocalURI.uriDecoderTest????? avgt?? 25? 688.298 ? 10.654 ns/op ThreadLocalURI.uriEncoderTest????? avgt?? 25? 336.660 ?? 2.997 ns/op webrev: https://cr.openjdk.java.net/~ryadav/webrev_8245308/webrev.01/index.html - rahul On 27/08/2020 15:58, Daniel Fuchs wrote: > Hi Rahul, > > The code changes look good to me but the uriDecoderTest needs > some working. The reason is that the decoded path is cached > in the URI, so only the first call to getPath() will decode it. > The following calls will just return the cached value. > > I also believe you should remove the inner loop - it probably serves > no purpose, and possibly find a way to pass a fresh URI to each > invocation of the uriDecoderTest method. I am not 100% sure on > how to achieve that with JMH though, but hopefully there's some > way to do that. > > best regards, > > -- daniel > > On 27/08/2020 14:11, Rahul Yadav wrote: >> Hello, >> >> Request to have my fix reviewed for issue: >> >> JDK-8245308:? Replace ThreadLocalCoders decoder/encoder cache in >> java.net.URI. >> >> This fix updates java.net.URI, replaces the ThreadLocalCoders >> optimization. >> The benchmark results indicate no impact, optimization can be >> replaced.The results of >> benchmark are provided below and benchmark included in webrev. >> >> Before >> >> Benchmark????????????????????? (iterations)? Mode? Cnt?? Score Error? >> Units >> ThreadLocalURI.uriDecoderTest?????????? 100? avgt?? 25?? 0.258 ? >> 0.014 us/op >> ThreadLocalURI.uriEncoderTest?????????? 100? avgt?? 25? 35.540 ? >> 1.082 us/op >> >> After >> >> Benchmark????????????????????? (iterations)? Mode? Cnt?? Score Error? >> Units >> ThreadLocalURI.uriDecoderTest?????????? 100? avgt?? 25?? 0.247 ? >> 0.005 us/op >> ThreadLocalURI.uriEncoderTest?????????? 100? avgt?? 25? 37.231 ? >> 0.669 us/op >> >> >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8245308 >> webrev: https://cr.openjdk.java.net/~ryadav/webrev_8245308/index.html >> >> - rahul > From Alan.Bateman at oracle.com Thu Aug 27 18:32:33 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Aug 2020 19:32:33 +0100 Subject: RFR 8245308 : Replace ThreadLocalCoders decoder/encoder cache in java.net.URI In-Reply-To: <2e482f50-aaa1-ca7b-e0d1-5bc46b2fca81@oracle.com> References: <19a94ba7-eb51-dcec-3af0-2c5edf696efe@oracle.com> <2e482f50-aaa1-ca7b-e0d1-5bc46b2fca81@oracle.com> Message-ID: On 27/08/2020 19:14, Rahul Yadav wrote: > Thank you all for the feedback. I have included feedback and updated > webrev. > > Before : > > Benchmark????????????????????????? Mode? Cnt??? Score??? Error Units > ThreadLocalURI.uriDecoderBaseline? avgt?? 25? 556.315 ? 23.389 ns/op > ThreadLocalURI.uriDecoderTest????? avgt?? 25? 728.413 ? 19.833 ns/op > ThreadLocalURI.uriEncoderTest????? avgt?? 25? 337.042 ?? 8.304 ns/op > > After : > > Benchmark????????????????????????? Mode? Cnt??? Score??? Error Units > ThreadLocalURI.uriDecoderBaseline? avgt?? 25? 578.108 ?? 9.829 ns/op > ThreadLocalURI.uriDecoderTest????? avgt?? 25? 688.298 ? 10.654 ns/op > ThreadLocalURI.uriEncoderTest????? avgt?? 25? 336.660 ?? 2.997 ns/op > > webrev: > https://cr.openjdk.java.net/~ryadav/webrev_8245308/webrev.01/index.html This version looks good to me. -Alan From daniel.fuchs at oracle.com Thu Aug 27 19:00:39 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 27 Aug 2020 20:00:39 +0100 Subject: RFR 8133686: REOPEN JDK-8080659 : HttpURLConnection?s getHeaderFields method returns field values in reverse order In-Reply-To: <6eca045c-4582-46e2-9db6-ac4d8bb865eb@default> References: <6899832b-45f9-4b13-be8c-eb12d8028914@default> <6eca045c-4582-46e2-9db6-ac4d8bb865eb@default> Message-ID: <1ed9d2b3-cad7-2a47-7d15-a9f4355f07af@oracle.com> Hi Evan, Actually - I believe you are still missing a test that verifies the actual issue - that is: If a multi valued field is sent over the wire as a repeated list of headers - that is - if it is transmitted as: foo: foo1 foo: foo2 foo: foo3 then you need to verify that HttpURLConnection.getHeaderFields().get("foo") will now return [foo1, foo2, foo3] and not [foo3, foo2, foo1]. Also I notice that your change also fixes URLConnection::getRequestProperties(), directly implemented in URLConnection, which is both good and bad. Good because the previous behavior was IMO a bug. Bad because it slightly increases the chances of regression (from minimal to low). So I now believe that writing a CSR is indeed required, to raise the awareness on this behavior change. best regards, -- daniel On 20/08/2020 17:06, Evan Whelan wrote: > Hi all, > > A revised webrev for this change can be found at > http://cr.openjdk.java.net/~coffeys/evwhelan/8133686/webrev/ > > This revision fixes a test that failed as a result of the source change. > > If anyone has any further thoughts on whether this change needs a CSR, I > would love to hear them. > > Thanks in advance, > > Evan From daniel.fuchs at oracle.com Thu Aug 27 19:08:41 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 27 Aug 2020 20:08:41 +0100 Subject: RFR 8245308 : Replace ThreadLocalCoders decoder/encoder cache in java.net.URI In-Reply-To: <2e482f50-aaa1-ca7b-e0d1-5bc46b2fca81@oracle.com> References: <19a94ba7-eb51-dcec-3af0-2c5edf696efe@oracle.com> <2e482f50-aaa1-ca7b-e0d1-5bc46b2fca81@oracle.com> Message-ID: Looks good to me Rahul! best regards, -- daniel On 27/08/2020 19:14, Rahul Yadav wrote: > Thank you all for the feedback. I have included feedback and updated > webrev. > > Before : > > Benchmark????????????????????????? Mode? Cnt??? Score??? Error Units > ThreadLocalURI.uriDecoderBaseline? avgt?? 25? 556.315 ? 23.389 ns/op > ThreadLocalURI.uriDecoderTest????? avgt?? 25? 728.413 ? 19.833 ns/op > ThreadLocalURI.uriEncoderTest????? avgt?? 25? 337.042 ?? 8.304 ns/op > > After : > > Benchmark????????????????????????? Mode? Cnt??? Score??? Error Units > ThreadLocalURI.uriDecoderBaseline? avgt?? 25? 578.108 ?? 9.829 ns/op > ThreadLocalURI.uriDecoderTest????? avgt?? 25? 688.298 ? 10.654 ns/op > ThreadLocalURI.uriEncoderTest????? avgt?? 25? 336.660 ?? 2.997 ns/op > > webrev: > https://cr.openjdk.java.net/~ryadav/webrev_8245308/webrev.01/index.html > From michael.x.mcmahon at oracle.com Fri Aug 28 08:46:03 2020 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 28 Aug 2020 09:46:03 +0100 Subject: 8245462: HttpClient send throws InterruptedException when interrupted but does not cancel request In-Reply-To: References: <14613d53-0105-cc57-b082-7c2691a8be6e@oracle.com> <4a7b1202-f8d1-eb3f-fd45-6d9523d28bf3@oracle.com> <6dd0519f-242f-3c10-d87b-ede941bf6bfa@oracle.com> <7ec6590b-638e-bc0b-2ea3-52c94e2cfdd7@oracle.com> <58b7a5f8-00bf-34e0-e156-72a603c15961@oracle.com> Message-ID: <024bf028-3ff2-7709-318d-b75aa5791980@oracle.com> Daniel, I wonder if the new Cancelable interface could be simplified to remove the "mayInterruptIfRunning" parameter? It seems like the cancellation operation has no effect if the parameter is false.. Otherwise, I am happy with the change. Thanks Michael On 31/07/2020 13:00, Michael McMahon wrote: > Hi Daniel, > > Good to see that produced useful results. I think it would be a good idea > to separate the two additional fixes if possible. That would certainly > make back-porting a lot easier. > > Thanks, > Michael. > > On 31/07/2020 10:46, Daniel Fuchs wrote: >> Thanks for suggesting this course of action Michael! >> >> This flushed out two additional bugs in our stack, which I believe >> are probably at the root of some of the rare intermittent failures >> we have been observing in the Throwing* tests: >> >> ? - SocketTube: I found an issue where the scheduler might not >> ?????? be restarted if resuming/pausing event from within >> ?????? the scheduler loop (that runs in the selector manager >> ?????? thread) failed due to the socket being asynchronously >> ?????? closed by another thread. >> ?????? That could cause some tests to fail in timeout. >> >> ?? - Http2Connection/Stream: there was an issue where DataFrames >> ?????? could be sent after a ResetFrame was sent. That caused the >> ?????? server to close down the connection. The next test would >> ?????? start opening a new stream on the same connection while >> ?????? the server was concurrently closing it, and the test >> ?????? would eventually fail - sometimes with a message saying >> ?????? "EOF reached while reading". >> >> The following webrev includes these two additional fixes, and I have >> now very stable test runs. I wonder if I should try to extract those >> two fixes though - as it might be worthwile to backport >> them independently: >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8245462/webrev.01/index.html >> >> best regards, >> >> -- daniel >> >> On 28/07/2020 15:19, Daniel Fuchs wrote: >>> On 28/07/2020 15:04, Michael McMahon wrote: >>>> The code is technically racy on the GET test, but it's often the >>>> case when you want >>>> something to be racy then it turns out not to be in practice, 99 >>>> times out of a 100 anyway >>>> (figures made up). I was thinking you could put a random sleep on >>>> the client side before calling >>>> cancel (say between 1ms and the SERVER_LATENCY constant). Print out >>>> the random value too >>>> in case it finds a problem. >>> >>> Oh - that's a good point. Let me try that. >>> >>> best regards, >>> >>> -- daniel >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Aug 28 08:54:02 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 28 Aug 2020 09:54:02 +0100 Subject: 8245462: HttpClient send throws InterruptedException when interrupted but does not cancel request In-Reply-To: <024bf028-3ff2-7709-318d-b75aa5791980@oracle.com> References: <14613d53-0105-cc57-b082-7c2691a8be6e@oracle.com> <4a7b1202-f8d1-eb3f-fd45-6d9523d28bf3@oracle.com> <6dd0519f-242f-3c10-d87b-ede941bf6bfa@oracle.com> <7ec6590b-638e-bc0b-2ea3-52c94e2cfdd7@oracle.com> <58b7a5f8-00bf-34e0-e156-72a603c15961@oracle.com> <024bf028-3ff2-7709-318d-b75aa5791980@oracle.com> Message-ID: Hi Michael, On 28/08/2020 09:46, Michael McMahon wrote: > Daniel, > > I wonder if the new Cancelable interface could be simplified to remove > the "mayInterruptIfRunning" parameter? It seems like the cancellation > operation has no effect if the parameter is false.. The interface mimics the Future::cancel and CompletableFuture::cancel API. IMO it's easier to delegate the handling of the boolean parameter at the implementation site (MultiExchange) rather than at the calling site (CompletableFuture). At one point in the history of the fix I also had MinimalFuture implement Cancellable. I stepped back from that after reflection but it could still become handy. > Otherwise, I am happy with the change. Thanks Michael! best regards, -- daniel > > Thanks > > Michael > > On 31/07/2020 13:00, Michael McMahon wrote: >> Hi Daniel, >> >> Good to see that produced useful results. I think it would be a good idea >> to separate the two additional fixes if possible. That would certainly >> make back-porting a lot easier. >> >> Thanks, >> Michael. >> >> On 31/07/2020 10:46, Daniel Fuchs wrote: >>> Thanks for suggesting this course of action Michael! >>> >>> This flushed out two additional bugs in our stack, which I believe >>> are probably at the root of some of the rare intermittent failures >>> we have been observing in the Throwing* tests: >>> >>> ? - SocketTube: I found an issue where the scheduler might not >>> ?????? be restarted if resuming/pausing event from within >>> ?????? the scheduler loop (that runs in the selector manager >>> ?????? thread) failed due to the socket being asynchronously >>> ?????? closed by another thread. >>> ?????? That could cause some tests to fail in timeout. >>> >>> ?? - Http2Connection/Stream: there was an issue where DataFrames >>> ?????? could be sent after a ResetFrame was sent. That caused the >>> ?????? server to close down the connection. The next test would >>> ?????? start opening a new stream on the same connection while >>> ?????? the server was concurrently closing it, and the test >>> ?????? would eventually fail - sometimes with a message saying >>> ?????? "EOF reached while reading". >>> >>> The following webrev includes these two additional fixes, and I have >>> now very stable test runs. I wonder if I should try to extract those >>> two fixes though - as it might be worthwile to backport >>> them independently: >>> >>> http://cr.openjdk.java.net/~dfuchs/webrev_8245462/webrev.01/index.html >>> >>> best regards, >>> >>> -- daniel >>> >>> On 28/07/2020 15:19, Daniel Fuchs wrote: >>>> On 28/07/2020 15:04, Michael McMahon wrote: >>>>> The code is technically racy on the GET test, but it's often the >>>>> case when you want >>>>> something to be racy then it turns out not to be in practice, 99 >>>>> times out of a 100 anyway >>>>> (figures made up). I was thinking you could put a random sleep on >>>>> the client side before calling >>>>> cancel (say between 1ms and the SERVER_LATENCY constant). Print out >>>>> the random value too >>>>> in case it finds a problem. >>>> >>>> Oh - that's a good point. Let me try that. >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>> From michael.x.mcmahon at oracle.com Fri Aug 28 08:57:55 2020 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 28 Aug 2020 09:57:55 +0100 Subject: 8245462: HttpClient send throws InterruptedException when interrupted but does not cancel request In-Reply-To: References: <14613d53-0105-cc57-b082-7c2691a8be6e@oracle.com> <4a7b1202-f8d1-eb3f-fd45-6d9523d28bf3@oracle.com> <6dd0519f-242f-3c10-d87b-ede941bf6bfa@oracle.com> <7ec6590b-638e-bc0b-2ea3-52c94e2cfdd7@oracle.com> <58b7a5f8-00bf-34e0-e156-72a603c15961@oracle.com> <024bf028-3ff2-7709-318d-b75aa5791980@oracle.com> Message-ID: <091dc624-0f72-2cac-502c-cb8d0024b887@oracle.com> On 28/08/2020 09:54, Daniel Fuchs wrote: > Hi Michael, > > On 28/08/2020 09:46, Michael McMahon wrote: >> Daniel, >> >> I wonder if the new Cancelable interface could be simplified to >> remove the "mayInterruptIfRunning" parameter? It seems like the >> cancellation operation has no effect if the parameter is false.. > > The interface mimics the Future::cancel and CompletableFuture::cancel > API. IMO it's easier to delegate the handling of the boolean parameter > at the implementation site (MultiExchange) rather than at the calling > site (CompletableFuture). At one point in the history of the fix I also > had MinimalFuture implement Cancellable. I stepped back from that after > reflection but it could still become handy. > Okay, that's fine. It was just an observation really Thanks Michael. >> Otherwise, I am happy with the change. > > Thanks Michael! > > best regards, > > -- daniel > >> >> Thanks >> >> Michael >> >> On 31/07/2020 13:00, Michael McMahon wrote: >>> Hi Daniel, >>> >>> Good to see that produced useful results. I think it would be a good >>> idea >>> to separate the two additional fixes if possible. That would certainly >>> make back-porting a lot easier. >>> >>> Thanks, >>> Michael. >>> >>> On 31/07/2020 10:46, Daniel Fuchs wrote: >>>> Thanks for suggesting this course of action Michael! >>>> >>>> This flushed out two additional bugs in our stack, which I believe >>>> are probably at the root of some of the rare intermittent failures >>>> we have been observing in the Throwing* tests: >>>> >>>> ? - SocketTube: I found an issue where the scheduler might not >>>> ?????? be restarted if resuming/pausing event from within >>>> ?????? the scheduler loop (that runs in the selector manager >>>> ?????? thread) failed due to the socket being asynchronously >>>> ?????? closed by another thread. >>>> ?????? That could cause some tests to fail in timeout. >>>> >>>> ?? - Http2Connection/Stream: there was an issue where DataFrames >>>> ?????? could be sent after a ResetFrame was sent. That caused the >>>> ?????? server to close down the connection. The next test would >>>> ?????? start opening a new stream on the same connection while >>>> ?????? the server was concurrently closing it, and the test >>>> ?????? would eventually fail - sometimes with a message saying >>>> ?????? "EOF reached while reading". >>>> >>>> The following webrev includes these two additional fixes, and I have >>>> now very stable test runs. I wonder if I should try to extract those >>>> two fixes though - as it might be worthwile to backport >>>> them independently: >>>> >>>> http://cr.openjdk.java.net/~dfuchs/webrev_8245462/webrev.01/index.html >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 28/07/2020 15:19, Daniel Fuchs wrote: >>>>> On 28/07/2020 15:04, Michael McMahon wrote: >>>>>> The code is technically racy on the GET test, but it's often the >>>>>> case when you want >>>>>> something to be racy then it turns out not to be in practice, 99 >>>>>> times out of a 100 anyway >>>>>> (figures made up). I was thinking you could put a random sleep on >>>>>> the client side before calling >>>>>> cancel (say between 1ms and the SERVER_LATENCY constant). Print >>>>>> out the random value too >>>>>> in case it finds a problem. >>>>> >>>>> Oh - that's a good point. Let me try that. >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>> > From alexander.scherbatiy at bell-sw.com Fri Aug 28 11:25:25 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Fri, 28 Aug 2020 14:25:25 +0300 Subject: RFR 8252248: __SIGRTMAX is not declared in musl libc In-Reply-To: References: <1c4ad320-a22a-484a-d370-852f9ecd90f8@bell-sw.com> Message-ID: <7c1ef537-3c36-c28a-c083-5bd8e5de8edf@bell-sw.com> Hello, Could you review the updated fix: ? http://cr.openjdk.java.net/~alexsch/8252248/webrev.01/ ?- moving shared code to net_util_md.h is avoided ?- INTERRUPT_SIGNAL is defined as SIGRTMAX - 2 instead of __SIGRTMAX - 2 for Linux in NativeThread.c ?- "#include " is moved out from "#ifdef" in NativeThread.c ?- sigWakeup is changed to "#define WAKEUP_SIGNAL (SIGRTMAX - 2)" in linux_close.c At least test/jdk/java/net/Socket/asyncClose/AsyncClose.java touches all four methods where the signal changes are used: NativeThread.c - Java_sun_nio_ch_NativeThread_init(JNIEnv *env, jclass cl) - Java_sun_nio_ch_NativeThread_signal(JNIEnv *env, jclass cl, jlong thread) linux_close.c -? __attribute((constructor)) init() - closefd(int fd1, int fd2) I run test/jdk/java/net tests on Ubuntu 18.04.4 and Alpine Linux 3.11.6 with musl libc 1.1.24. There are 10 failed tests but they fail without the fix as well. I believe that it is because of some network settings of? my machine. ? java/net/MulticastSocket/IPMulticastIF.java ? java/net/MulticastSocket/NoSetNetworkInterface.java ? java/net/MulticastSocket/Promiscuous.java ? java/net/MulticastSocket/PromiscuousIPv6.java ? java/net/MulticastSocket/SetGetNetworkInterfaceTest.java ? java/net/MulticastSocket/SetLoopbackMode.java ? java/net/MulticastSocket/SetOutgoingIf.java ? java/net/MulticastSocket/Test.java ? java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java ? java/net/ipv6tests/UdpTest.java Thanks, Alexander. On 26.08.2020 13:42, Alan Bateman wrote: > On 25/08/2020 18:00, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could your review the fix for the issue: >> ? Bug: https://bugs.openjdk.java.net/browse/JDK-8252248 >> ? Fix: http://cr.openjdk.java.net/~alexsch/8252248/webrev.00/ >> >> : >> >> The fix has been discussed on the portola-dev alias [2] where it was >> pointed out that the fix can be reviewed in the mainline and it was >> suggested to rename the INTERRUPT_SIGNAL and move its definition to >> net_util_md.h. >> > The xxx_close.c sources are for the old SocketImpl and > DatagramSocketImpl implementations; they are aren't used by default > and will eventually go away. Maybe an option for the musl port is to > just not compile in the old socket implementations? It might be best > to start a discussion on nio-dev and net-dev about this as we > shouldn't be changing NativeThread.c (which is used for signalling in > the FileChannel implementation) to include net_util.h. > > -Alan From Alan.Bateman at oracle.com Fri Aug 28 12:55:59 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Aug 2020 13:55:59 +0100 Subject: RFR 8252248: __SIGRTMAX is not declared in musl libc In-Reply-To: <7c1ef537-3c36-c28a-c083-5bd8e5de8edf@bell-sw.com> References: <1c4ad320-a22a-484a-d370-852f9ecd90f8@bell-sw.com> <7c1ef537-3c36-c28a-c083-5bd8e5de8edf@bell-sw.com> Message-ID: On 28/08/2020 12:25, Alexander Scherbatiy wrote: > Hello, > > Could you review the updated fix: > ? http://cr.openjdk.java.net/~alexsch/8252248/webrev.01/ > > ?- moving shared code to net_util_md.h is avoided > ?- INTERRUPT_SIGNAL is defined as SIGRTMAX - 2 instead of __SIGRTMAX - > 2 for Linux in NativeThread.c > ?- "#include " is moved out from "#ifdef" in NativeThread.c > ?- sigWakeup is changed to "#define WAKEUP_SIGNAL (SIGRTMAX - 2)" in > linux_close.c > > At least test/jdk/java/net/Socket/asyncClose/AsyncClose.java touches > all four methods where the signal changes are used: > NativeThread.c > - Java_sun_nio_ch_NativeThread_init(JNIEnv *env, jclass cl) > - Java_sun_nio_ch_NativeThread_signal(JNIEnv *env, jclass cl, jlong > thread) > linux_close.c > -? __attribute((constructor)) init() > - closefd(int fd1, int fd2) NativeThread current/signal will be exercised by the tests in java/nio/channels. The code in linux_close.c is only used with the old (and not used by default) SocketImpl and DatagramSocketImpl implementation. Some of the tests jdk_net test group will re-run the tests with the old implementation so you should be okay. > > I run test/jdk/java/net tests on Ubuntu 18.04.4 and Alpine Linux > 3.11.6 with musl libc 1.1.24. > There are 10 failed tests but they fail without the fix as well. I > believe that it is because of some network settings of? my machine. Sometimes there is will firewall or iptables configuration need to allow multicast datagrams to be received. -Alan From alexander.scherbatiy at bell-sw.com Fri Aug 28 14:32:37 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Fri, 28 Aug 2020 17:32:37 +0300 Subject: RFR 8252248: __SIGRTMAX is not declared in musl libc In-Reply-To: References: <1c4ad320-a22a-484a-d370-852f9ecd90f8@bell-sw.com> <7c1ef537-3c36-c28a-c083-5bd8e5de8edf@bell-sw.com> Message-ID: <66d7be82-12ab-7d64-ee24-988c2b050dd5@bell-sw.com> On 28.08.2020 15:55, Alan Bateman wrote: > On 28/08/2020 12:25, Alexander Scherbatiy wrote: >> Hello, >> >> Could you review the updated fix: >> ? http://cr.openjdk.java.net/~alexsch/8252248/webrev.01/ >> >> ?- moving shared code to net_util_md.h is avoided >> ?- INTERRUPT_SIGNAL is defined as SIGRTMAX - 2 instead of __SIGRTMAX >> - 2 for Linux in NativeThread.c >> ?- "#include " is moved out from "#ifdef" in NativeThread.c >> ?- sigWakeup is changed to "#define WAKEUP_SIGNAL (SIGRTMAX - 2)" in >> linux_close.c >> >> At least test/jdk/java/net/Socket/asyncClose/AsyncClose.java touches >> all four methods where the signal changes are used: >> NativeThread.c >> - Java_sun_nio_ch_NativeThread_init(JNIEnv *env, jclass cl) >> - Java_sun_nio_ch_NativeThread_signal(JNIEnv *env, jclass cl, jlong >> thread) >> linux_close.c >> -? __attribute((constructor)) init() >> - closefd(int fd1, int fd2) > NativeThread current/signal will be exercised by the tests in > java/nio/channels. ? I run the java/nio/channels tests with the fix. There are five failed tests that fail with and without the fix: ??? java/nio/channels/DatagramChannel/AdaptorMulticasting.java ??? java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java ??? java/nio/channels/DatagramChannel/PromiscuousIPv6.java ??? java/nio/channels/DatagramChannel/Loopback.java ??? java/nio/channels/FileChannel/FileExtensionAndMap.java The FileExtensionAndMap.java has clear fail message: "Error. Test ignored: This test has huge disk space requirements". Thanks, Alexander. > The code in linux_close.c is only used with the old (and not used by > default) SocketImpl and DatagramSocketImpl implementation. Some of the > tests jdk_net test group will re-run the tests with the old > implementation so you should be okay. > >> >> I run test/jdk/java/net tests on Ubuntu 18.04.4 and Alpine Linux >> 3.11.6 with musl libc 1.1.24. >> There are 10 failed tests but they fail without the fix as well. I >> believe that it is because of some network settings of? my machine. > Sometimes there is will firewall or iptables configuration need to > allow multicast datagrams to be received. > > -Alan From Alan.Bateman at oracle.com Fri Aug 28 14:40:38 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Aug 2020 15:40:38 +0100 Subject: RFR 8252248: __SIGRTMAX is not declared in musl libc In-Reply-To: <66d7be82-12ab-7d64-ee24-988c2b050dd5@bell-sw.com> References: <1c4ad320-a22a-484a-d370-852f9ecd90f8@bell-sw.com> <7c1ef537-3c36-c28a-c083-5bd8e5de8edf@bell-sw.com> <66d7be82-12ab-7d64-ee24-988c2b050dd5@bell-sw.com> Message-ID: On 28/08/2020 15:32, Alexander Scherbatiy wrote: > > ? I run the java/nio/channels tests with the fix. There are five > failed tests that fail with and without the fix: > ??? java/nio/channels/DatagramChannel/AdaptorMulticasting.java > java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java > ??? java/nio/channels/DatagramChannel/PromiscuousIPv6.java > ??? java/nio/channels/DatagramChannel/Loopback.java > ??? java/nio/channels/FileChannel/FileExtensionAndMap.java > > The FileExtensionAndMap.java has clear fail message: "Error. Test > ignored: This test has huge disk space requirements". The DatagramChannel failures are probably because of firewall or iptables issues too.? The FileExtensionAndMap test has @ignore so it will be skipped, maybe you are running jtreg directly and aren't use -ignore:quiet? In any case, I think the changes look okay. -Alan From alexander.scherbatiy at bell-sw.com Fri Aug 28 14:54:19 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Fri, 28 Aug 2020 17:54:19 +0300 Subject: RFR 8252248: __SIGRTMAX is not declared in musl libc In-Reply-To: References: <1c4ad320-a22a-484a-d370-852f9ecd90f8@bell-sw.com> <7c1ef537-3c36-c28a-c083-5bd8e5de8edf@bell-sw.com> <66d7be82-12ab-7d64-ee24-988c2b050dd5@bell-sw.com> Message-ID: On 28.08.2020 17:40, Alan Bateman wrote: > On 28/08/2020 15:32, Alexander Scherbatiy wrote: >> >> ? I run the java/nio/channels tests with the fix. There are five >> failed tests that fail with and without the fix: >> ??? java/nio/channels/DatagramChannel/AdaptorMulticasting.java >> java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java >> ??? java/nio/channels/DatagramChannel/PromiscuousIPv6.java >> ??? java/nio/channels/DatagramChannel/Loopback.java >> ??? java/nio/channels/FileChannel/FileExtensionAndMap.java >> >> The FileExtensionAndMap.java has clear fail message: "Error. Test >> ignored: This test has huge disk space requirements". > The DatagramChannel failures are probably because of firewall or > iptables issues too.? The FileExtensionAndMap test has @ignore so it > will be skipped, maybe you are running jtreg directly and aren't use > -ignore:quiet? ? Yes, I run the jtreg tests directly without the -ignore:quiet option. ? Thanks, ? Alexander. > > In any case, I think the changes look okay. > > -Alan From vyommani at gmail.com Fri Aug 28 15:40:24 2020 From: vyommani at gmail.com (Vyom Tiwari) Date: Fri, 28 Aug 2020 21:10:24 +0530 Subject: RFR 8252248: __SIGRTMAX is not declared in musl libc In-Reply-To: References: <1c4ad320-a22a-484a-d370-852f9ecd90f8@bell-sw.com> <7c1ef537-3c36-c28a-c083-5bd8e5de8edf@bell-sw.com> <66d7be82-12ab-7d64-ee24-988c2b050dd5@bell-sw.com> Message-ID: +1 Vyom On Fri, Aug 28, 2020 at 8:24 PM Alexander Scherbatiy < alexander.scherbatiy at bell-sw.com> wrote: > On 28.08.2020 17:40, Alan Bateman wrote: > > > On 28/08/2020 15:32, Alexander Scherbatiy wrote: > >> > >> I run the java/nio/channels tests with the fix. There are five > >> failed tests that fail with and without the fix: > >> java/nio/channels/DatagramChannel/AdaptorMulticasting.java > >> java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java > >> java/nio/channels/DatagramChannel/PromiscuousIPv6.java > >> java/nio/channels/DatagramChannel/Loopback.java > >> java/nio/channels/FileChannel/FileExtensionAndMap.java > >> > >> The FileExtensionAndMap.java has clear fail message: "Error. Test > >> ignored: This test has huge disk space requirements". > > The DatagramChannel failures are probably because of firewall or > > iptables issues too. The FileExtensionAndMap test has @ignore so it > > will be skipped, maybe you are running jtreg directly and aren't use > > -ignore:quiet? > Yes, I run the jtreg tests directly without the -ignore:quiet option. > > Thanks, > Alexander. > > > > In any case, I think the changes look okay. > > > > -Alan > -- Thanks, Vyom -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri Aug 28 16:24:13 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 28 Aug 2020 18:24:13 +0200 Subject: RFR 8252248: __SIGRTMAX is not declared in musl libc In-Reply-To: <7c1ef537-3c36-c28a-c083-5bd8e5de8edf@bell-sw.com> References: <1c4ad320-a22a-484a-d370-852f9ecd90f8@bell-sw.com> <7c1ef537-3c36-c28a-c083-5bd8e5de8edf@bell-sw.com> Message-ID: Looks good to me. Thanks for checking. Cheers, Thomas On Fri, Aug 28, 2020 at 1:25 PM Alexander Scherbatiy < alexander.scherbatiy at bell-sw.com> wrote: > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8252248/webrev.01/ > > - moving shared code to net_util_md.h is avoided > - INTERRUPT_SIGNAL is defined as SIGRTMAX - 2 instead of __SIGRTMAX - > 2 for Linux in NativeThread.c > - "#include " is moved out from "#ifdef" in NativeThread.c > - sigWakeup is changed to "#define WAKEUP_SIGNAL (SIGRTMAX - 2)" in > linux_close.c > > At least test/jdk/java/net/Socket/asyncClose/AsyncClose.java touches all > four methods where the signal changes are used: > NativeThread.c > - Java_sun_nio_ch_NativeThread_init(JNIEnv *env, jclass cl) > - Java_sun_nio_ch_NativeThread_signal(JNIEnv *env, jclass cl, jlong thread) > linux_close.c > - __attribute((constructor)) init() > - closefd(int fd1, int fd2) > > I run test/jdk/java/net tests on Ubuntu 18.04.4 and Alpine Linux 3.11.6 > with musl libc 1.1.24. > There are 10 failed tests but they fail without the fix as well. I > believe that it is because of some network settings of my machine. > > java/net/MulticastSocket/IPMulticastIF.java > java/net/MulticastSocket/NoSetNetworkInterface.java > java/net/MulticastSocket/Promiscuous.java > java/net/MulticastSocket/PromiscuousIPv6.java > java/net/MulticastSocket/SetGetNetworkInterfaceTest.java > java/net/MulticastSocket/SetLoopbackMode.java > java/net/MulticastSocket/SetOutgoingIf.java > java/net/MulticastSocket/Test.java > java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java > java/net/ipv6tests/UdpTest.java > > Thanks, > Alexander. > > On 26.08.2020 13:42, Alan Bateman wrote: > > On 25/08/2020 18:00, Alexander Scherbatiy wrote: > >> > >> Hello, > >> > >> Could your review the fix for the issue: > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8252248 > >> Fix: http://cr.openjdk.java.net/~alexsch/8252248/webrev.00/ > >> > >> : > >> > >> The fix has been discussed on the portola-dev alias [2] where it was > >> pointed out that the fix can be reviewed in the mainline and it was > >> suggested to rename the INTERRUPT_SIGNAL and move its definition to > >> net_util_md.h. > >> > > The xxx_close.c sources are for the old SocketImpl and > > DatagramSocketImpl implementations; they are aren't used by default > > and will eventually go away. Maybe an option for the musl port is to > > just not compile in the old socket implementations? It might be best > > to start a discussion on nio-dev and net-dev about this as we > > shouldn't be changing NativeThread.c (which is used for signalling in > > the FileChannel implementation) to include net_util.h. > > > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.concannon at oracle.com Mon Aug 31 16:12:01 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Mon, 31 Aug 2020 17:12:01 +0100 Subject: =?utf-8?Q?RFR=5B8251496=5D=3A_=E2=80=98Fix_doclint_warnings_in_jd?= =?utf-8?Q?k=2Enet=2Ehttpserver=E2=80=99?= Message-ID: <4FBAFF2C-A061-43C0-BEAF-0FC6EE633270@oracle.com> Hi, Could someone please review my doc-only fix for JDK-8251496 - ?Fix doclint warnings in jdk.net.httpserver? ? This fix addresses the warnings generated by `javadoc -Xdoclint` due to missing/incomplete API documentation for several classes within `jdk.net.httpserver`. issue: https://bugs.openjdk.java.net/browse/JDK-8251496 webrev: http://cr.openjdk.java.net/~pconcannon/8251496/webrevs/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8252585 Kind regards, Patrick From vipinsharma85 at gmail.com Fri Aug 14 18:47:00 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Fri, 14 Aug 2020 18:47:00 -0000 Subject: Fix for Javadoc errors in java.base In-Reply-To: <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> Message-ID: Hi Sean, All 3 instances of @exception in DHPrivateKey are now replaced with @throws, added ProviderException similar to other constructor of DHPrivateKey. Updated patch: --- old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java 2020-08-14 23:55:40.921599987 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java 2020-08-14 23:55:40.417581423 +0530 @@ -80,7 +80,7 @@ * @param p the prime modulus * @param g the base generator * - * @exception ProviderException if the key cannot be encoded + * @throws ProviderException if the key cannot be encoded */ DHPrivateKey(BigInteger x, BigInteger p, BigInteger g) throws InvalidKeyException { @@ -97,7 +97,7 @@ * @param g the base generator * @param l the private-value length * - * @exception InvalidKeyException if the key cannot be encoded + * @throws ProviderException if the key cannot be encoded */ DHPrivateKey(BigInteger x, BigInteger p, BigInteger g, int l) { this.x = x; @@ -118,7 +118,7 @@ * * @param encodedKey the encoded key * - * @exception InvalidKeyException if the encoded key does not represent + * @throws InvalidKeyException if the encoded key does not represent * a Diffie-Hellman private key */ DHPrivateKey(byte[] encodedKey) throws InvalidKeyException { --- old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java 2020-08-14 23:55:41.953638446 +0530 +++ new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java 2020-08-14 23:55:41.445619497 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -208,7 +208,7 @@ * * @return a CallSite, which, when invoked, will return an instance of the * functional interface - * @throws ReflectiveOperationException + * @throws LambdaConversionException */ abstract CallSite buildCallSite() throws LambdaConversionException; --- old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java 2020-08-14 23:55:42.977677096 +0530 +++ new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java 2020-08-14 23:55:42.473658062 +0530 @@ -200,7 +200,6 @@ * * @return a CallSite, which, when invoked, will return an instance of the * functional interface - * @throws ReflectiveOperationException * @throws LambdaConversionException If properly formed functional interface * is not found */ --- old/src/java.base/share/classes/java/math/BigDecimal.java 2020-08-14 23:55:44.409731999 +0530 +++ new/src/java.base/share/classes/java/math/BigDecimal.java 2020-08-14 23:55:43.889711942 +0530 @@ -5403,7 +5403,7 @@ * * @param n the numerator; must be negative * @param d the denominator; must not be unity - * @return a two-element {@long} array with the remainder and quotient in + * @return a two-element {@code long} array with the remainder and quotient in * the initial and final elements, respectively */ private static long[] divRemNegativeLong(long n, long d) { --- old/src/java.base/share/classes/java/math/MutableBigInteger.java 2020-08-14 23:55:45.905790246 +0530 +++ new/src/java.base/share/classes/java/math/MutableBigInteger.java 2020-08-14 23:55:45.397770378 +0530 @@ -145,7 +145,6 @@ * Makes this number an {@code n}-int number all of whose bits are ones. * Used by Burnikel-Ziegler division. * @param n number of ints in the {@code value} array - * @return a number equal to {@code ((1<<(32*n)))-1} */ private void ones(int n) { if (n > value.length) --- old/src/java.base/share/classes/java/net/ServerSocket.java 2020-08-14 23:55:46.961831962 +0530 +++ new/src/java.base/share/classes/java/net/ServerSocket.java 2020-08-14 23:55:46.449811716 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -315,7 +315,7 @@ /** * Creates the socket implementation. * - * @throws IOException if creation fails + * @throws SocketException if creation fails * @since 1.4 */ void createImpl() throws SocketException { --- old/src/java.base/share/classes/java/net/Socket.java 2020-08-14 23:55:48.001873514 +0530 +++ new/src/java.base/share/classes/java/net/Socket.java 2020-08-14 23:55:47.493853209 +0530 @@ -533,7 +533,7 @@ * * @param stream a {@code boolean} value : {@code true} for a TCP socket, * {@code false} for UDP. - * @throws IOException if creation fails + * @throws SocketException if creation fails * @since 1.4 */ void createImpl(boolean stream) throws SocketException { --- old/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java 2020-08-14 23:55:49.061916354 +0530 +++ new/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java 2020-08-14 23:55:48.549895649 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -773,7 +773,7 @@ * an "annotation structure" OR two bytes into an annotation * structure (i.e., after the type index). * - * @parameter complete true if the byte buffer points to the beginning + * @param complete true if the byte buffer points to the beginning * of an annotation structure (rather than two bytes in). */ private static void skipAnnotation(ByteBuffer buf, boolean complete) { Regards, Vipin > On Aug 13, 2020, at 10:55 PM, Sean Mullan wrote: > > On 8/13/20 1:21 PM, Jonathan Gibbons wrote: >>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>>>> 2020-07-25 23:46:21.233726447 +0530 >>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>>>> 2020-07-25 23:46:20.721720857 +0530 >>>>> @@ -96,8 +96,6 @@ >>>>> * @param p the prime modulus >>>>> * @param g the base generator >>>>> * @param l the private-value length >>>>> - * >>>>> - * @exception InvalidKeyException if the key cannot be encoded >>> >>> This should actually remain, but it should be ProviderException which is a RuntimeException. See the other DHPrivateKey ctor as that specifies it correctly. >>> >>> --Sean >> I note the use of `@exception`, as compared to `@throws`, which is more common. >> Stats: >> `@exception` 7322 occurrences >> `@throws` 21173 occurrences >> That's probably too many `@exception` to clean up. :-( > > Right, that's probably a separate cleanup activity. However, if you want to change the 3 instances of @exception to @throws in DHPrivateKey, I'm fine with that. > > --Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: