From dfuchs at openjdk.org  Wed May  3 10:39:26 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 3 May 2023 10:39:26 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking [v3]
In-Reply-To: <9nvO7MHtyoB0Svr_CKsuiofe3hsNI2K9FAuIQBiRDc0=.0f95ab64-70b1-4879-a081-c58066c1f448@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
 <9nvO7MHtyoB0Svr_CKsuiofe3hsNI2K9FAuIQBiRDc0=.0f95ab64-70b1-4879-a081-c58066c1f448@github.com>
Message-ID: <efGwLvLGfDMp6D2qHIPyUztDw32lOtMewpJsIUIFZ0w=.d899cf50-1a42-4a0d-aa53-4a148b5399e9@github.com>

On Thu, 27 Apr 2023 12:08:53 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Currently it is possible for `HttpURLConnection` with the `Expect: 100-Continue` header to timeout awaiting for a server response. According to [RFC-7231](https://www.rfc-editor.org/rfc/rfc7231#section-5.1.1) a client `SHOULD NOT wait for an indefinite period before sending the message body`.
>> 
>> This PR changes the existing `expect100Continue` method to wait for a maximum of 5 seconds for a server response, this will be shorter if a timeout is set. If no response is received, the message is sent regardless.
>> 
>> Tests have been added to account for different scenarios that currently timeout, and the changes have been tested against tiers 1,2 and 3.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made the individual variables in Control volatile instead of the class declaration itself

Since control can be accessed from different threads it's better to make it volatile too - and then stuck it in a local variable before reading its fields.

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 61:

> 59: 
> 60:     private Thread serverThread = null;
> 61:     private Control control = null;

Suggestion:

    private volatile Control control;

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 72:

> 70:     @BeforeAll
> 71:     public void startServerSocket() throws Exception {
> 72:         control = new Control();

Suggestion:

        Control control = this.control = new Control();

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 177:

> 175:         control.stop = true;
> 176:         control.serverSocket.close();
> 177:         serverThread.join();

Suggestion:

        Control control = this.control;
        control.stop = true;
        control.serverSocket.close();
        serverThread.join();

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 182:

> 180:     @Test
> 181:     public void testNonChunkedRequestAndNoExpect100ContinueResponse() throws Exception {
> 182:         String body = "testNonChunkedRequestAndNoExpect100ContinueResponse";

Suggestion:

        String body = "testNonChunkedRequestAndNoExpect100ContinueResponse";
        Control control = this.control;

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 207:

> 205:     @Test
> 206:     public void testNonChunkedRequestWithExpect100ContinueResponse() throws Exception {
> 207:         String body = "testNonChunkedRequestWithExpect100ContinueResponse";

Suggestion:

        String body = "testNonChunkedRequestWithExpect100ContinueResponse";
        Control control = this.control;

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 232:

> 230:     @Test
> 231:     public void testNonChunkedRequestWithDoubleExpect100ContinueResponse() throws Exception {
> 232:         String body = "testNonChunkedRequestWithDoubleExpect100ContinueResponse";

Suggestion:

        String body = "testNonChunkedRequestWithDoubleExpect100ContinueResponse";
        Control control = this.control;

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 257:

> 255:     @Test
> 256:     public void testChunkedRequestAndNoExpect100ContinueResponse() throws Exception {
> 257:         String body = "testChunkedRequestAndNoExpect100ContinueResponse";

Suggestion:

        String body = "testChunkedRequestAndNoExpect100ContinueResponse";
        Control control = this.control;

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 283:

> 281:     @Test
> 282:     public void testChunkedRequestWithExpect100ContinueResponse() throws Exception {
> 283:         String body = "testChunkedRequestWithExpect100ContinueResponse";

Suggestion:

        String body = "testChunkedRequestWithExpect100ContinueResponse";
        Control control = this.control;

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 309:

> 307:     @Test
> 308:     public void testChunkedRequestWithDoubleExpect100ContinueResponse() throws Exception {
> 309:         String body = "testChunkedRequestWithDoubleExpect100ContinueResponse";

Suggestion:

        String body = "testChunkedRequestWithDoubleExpect100ContinueResponse";
        Control control = this.control;

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 335:

> 333:     @Test
> 334:     public void testFixedLengthRequestAndNoExpect100ContinueResponse() throws Exception {
> 335:         String body = "testFixedLengthRequestAndNoExpect100ContinueResponse";

Suggestion:

        String body = "testFixedLengthRequestAndNoExpect100ContinueResponse";
        Control control = this.control;

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 361:

> 359:     @Test
> 360:     public void testFixedLengthRequestWithExpect100ContinueResponse() throws Exception {
> 361:         String body = "testFixedLengthRequestWithExpect100ContinueResponse";

Suggestion:

        String body = "testFixedLengthRequestWithExpect100ContinueResponse";
        Control control = this.control;

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 387:

> 385:     @Test
> 386:     public void testFixedLengthRequestWithDoubleExpect100ContinueResponse() throws Exception {
> 387:         String body = "testFixedLengthRequestWithDoubleExpect100ContinueResponse";

Suggestion:

        String body = "testFixedLengthRequestWithDoubleExpect100ContinueResponse";
        Control control = this.control;

-------------

PR Review: https://git.openjdk.org/jdk/pull/13330#pullrequestreview-1410611920
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183508706
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183509329
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183510690
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183511557
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183512339
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183512846
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183513668
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183514365
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183514649
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183514895
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183515111
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1183515310

From duke at openjdk.org  Wed May  3 11:47:13 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 3 May 2023 11:47:13 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking [v4]
In-Reply-To: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
Message-ID: <wXcO_sl2lfs5UulU_XILgPZ6JSbtjHcoFTlCTIxuUwQ=.7136dbdd-a92e-4e36-8a02-27a78de44b7f@github.com>

> Currently it is possible for `HttpURLConnection` with the `Expect: 100-Continue` header to timeout awaiting for a server response. According to [RFC-7231](https://www.rfc-editor.org/rfc/rfc7231#section-5.1.1) a client `SHOULD NOT wait for an indefinite period before sending the message body`.
> 
> This PR changes the existing `expect100Continue` method to wait for a maximum of 5 seconds for a server response, this will be shorter if a timeout is set. If no response is received, the message is sent regardless.
> 
> Tests have been added to account for different scenarios that currently timeout, and the changes have been tested against tiers 1,2 and 3.

Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13330/files
  - new: https://git.openjdk.org/jdk/pull/13330/files/9483e957..874e3497

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13330&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13330&range=02-03

  Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13330.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13330/head:pull/13330

PR: https://git.openjdk.org/jdk/pull/13330

From dfuchs at openjdk.org  Wed May  3 12:46:18 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 3 May 2023 12:46:18 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking [v4]
In-Reply-To: <wXcO_sl2lfs5UulU_XILgPZ6JSbtjHcoFTlCTIxuUwQ=.7136dbdd-a92e-4e36-8a02-27a78de44b7f@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
 <wXcO_sl2lfs5UulU_XILgPZ6JSbtjHcoFTlCTIxuUwQ=.7136dbdd-a92e-4e36-8a02-27a78de44b7f@github.com>
Message-ID: <k9aAK3Cjdlfk3p21fqgyLUab4eJ1O4_MlJqUrZQ21Jo=.52aa5e8e-cfc7-494a-9fea-58ff3be38f82@github.com>

On Wed, 3 May 2023 11:47:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Currently it is possible for `HttpURLConnection` with the `Expect: 100-Continue` header to timeout awaiting for a server response. According to [RFC-7231](https://www.rfc-editor.org/rfc/rfc7231#section-5.1.1) a client `SHOULD NOT wait for an indefinite period before sending the message body`.
>> 
>> This PR changes the existing `expect100Continue` method to wait for a maximum of 5 seconds for a server response, this will be shorter if a timeout is set. If no response is received, the message is sent regardless.
>> 
>> Tests have been added to account for different scenarios that currently timeout, and the changes have been tested against tiers 1,2 and 3.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13330#pullrequestreview-1410812161

From michaelm at openjdk.org  Wed May  3 14:00:19 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 3 May 2023 14:00:19 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v6]
In-Reply-To: <HD0R3rRJ78heAbPdJHzORwwg8VcSNorZn2rtcvydA6c=.f8e0143a-d799-453e-a122-ca82960cdfa1@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <cn5Hv_83UMHaoxbUDMBAVNlc3CEPISehmRq90Ap188U=.117f5424-4721-4c30-9112-33aca722b5c1@github.com>
 <sNzwfN13nWHfKJfivmmq7WsS_-F7i8IzlLirE9llduc=.086b7f9d-648a-4e2b-913e-d1679e273350@github.com>
 <HD0R3rRJ78heAbPdJHzORwwg8VcSNorZn2rtcvydA6c=.f8e0143a-d799-453e-a122-ca82960cdfa1@github.com>
Message-ID: <Tz_DUFSfFSsTOJXrIHKicTOvJ3zwHmrobZRG3dvivj8=.af8a9cef-38b7-4702-b912-42b2b1af8378@github.com>

On Fri, 28 Apr 2023 15:13:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/InetAddressCachePolicy.java line 130:
>> 
>>> 128:                 staleCachePolicy = (int) Math.max(tmp, max);
>>> 129:             }
>>> 130:         }
>> 
>> Maybe there was discussion of this which I missed, but this seems to be saying if the cache policy is less than seven days, then the stale policy is set no less than seven days. What is the reason for that? I think it would need to be documented if we stick with it.
>
> It is come from the recommendation in the "RFC 8767" see the notion about "cap of 7 days":
> https://www.rfc-editor.org/rfc/rfc8767
> Depending on the final implementation I can document this, or delete it in the code.

>From what I can see RFC8767 recommends a cap of 7 days for the TTL itself - that is a maximum value for `cachePolicy` rather than `staleCachePolicy`. It seems to say the the stale timer should be configurable with the text: "The suggested value is between 1 and 3 days".  Personally, I would drop this part of the change. Such suggestions can be adopted (or not) by end users in my opinion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1183726891

From serb at openjdk.org  Wed May  3 18:05:16 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 3 May 2023 18:05:16 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v6]
In-Reply-To: <Tz_DUFSfFSsTOJXrIHKicTOvJ3zwHmrobZRG3dvivj8=.af8a9cef-38b7-4702-b912-42b2b1af8378@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <cn5Hv_83UMHaoxbUDMBAVNlc3CEPISehmRq90Ap188U=.117f5424-4721-4c30-9112-33aca722b5c1@github.com>
 <sNzwfN13nWHfKJfivmmq7WsS_-F7i8IzlLirE9llduc=.086b7f9d-648a-4e2b-913e-d1679e273350@github.com>
 <HD0R3rRJ78heAbPdJHzORwwg8VcSNorZn2rtcvydA6c=.f8e0143a-d799-453e-a122-ca82960cdfa1@github.com>
 <Tz_DUFSfFSsTOJXrIHKicTOvJ3zwHmrobZRG3dvivj8=.af8a9cef-38b7-4702-b912-42b2b1af8378@github.com>
Message-ID: <N-SMmCkSE-bOry9s0jLPh7tisaOskOFdPoPKNQv_w80=.e556e81f-0735-43f4-a73d-121e648b60b4@github.com>

On Wed, 3 May 2023 13:57:25 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> It is come from the recommendation in the "RFC 8767" see the notion about "cap of 7 days":
>> https://www.rfc-editor.org/rfc/rfc8767
>> Depending on the final implementation I can document this, or delete it in the code.
>
> From what I can see RFC8767 recommends a cap of 7 days for the TTL itself - that is a maximum value for `cachePolicy` rather than `staleCachePolicy`. It seems to say the the stale timer should be configurable with the text: "The suggested value is between 1 and 3 days".  Personally, I would drop this part of the change. Such suggestions can be adopted (or not) by end users in my opinion.

Sounds good, I'll update the patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1184077964

From serb at openjdk.org  Thu May  4 06:05:20 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 4 May 2023 06:05:20 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v7]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <IZ2tvUTjaeMVFxt-yA3AlJCx55ZSrPJ4TGbZmLFMs9g=.d8d9fd03-b99c-4aee-82b4-cbf35ad4b09f@github.com>

> I would like to get preliminary feedback about the provided patch.
> 
> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
> 
> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
> 
> At the moment this cache can be configured by the application using the following two properties:
>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
> 
> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
> 
> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
> 
> Possible solutions:
>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
> 
> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
> 
> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
> 
> 
> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
> https://www.rfc-editor.org/rfc/rfc8767
> 
> Comments about current and other possible implementations:
>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>  * The refresh timeout includes the time spent on the server lookup. So if we have to refresh every 2 seconds, but in lookup, we spend 3 seconds then we will request the server on each lookup. Another implementation may spend 3 seconds on lookup and then additional use the cached value for two seconds.
>  * The extended timeout is a kind of "maximum stale timer" from the RFC above, but it starts counting not from the moment the record expired, but from the moment we added it to the cache. Another possible implementation may start counting from the moment the TTL expired, so the overall usage of the value will be sum ttl+extended.
>  * The extended timeout has a hard deadline which is never changed during execution, for example, if it sets for 1 day, then at the end of the day we should make a successful lookup to recache the value otherwise we will start to use the "negative" cache. Other implementations may shift the expiration time on every successful sync.
> 
> Any thoughts about other possibilities?

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  delete 7 days cap

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13285/files
  - new: https://git.openjdk.org/jdk/pull/13285/files/22a0bd01..bd45f00c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=05-06

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

PR: https://git.openjdk.org/jdk/pull/13285

From ccleary at openjdk.org  Thu May  4 15:07:12 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 4 May 2023 15:07:12 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v6]
In-Reply-To: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
Message-ID: <d8q6BIBCCTp21Gu-u_uaUNBv3sgr0HXaJxBrcxmYoy0=.f7421d22-e266-4da8-8f39-d6c4b107b4b1@github.com>

> ### Description
> Submitter reported when sending data of a length greater than 64kb using the `HttpClient` with HTTP/2, the HttpClient would hang indefinitely. Through reproducing the issue and analysing logs it was also seen that the HttpClient would not accept any incoming frames in this state. Note that 64kb is the default window size of a HTTP/2 Stream with the `HttpClient`.
> 
> The particular server used by the submitter did not emit window update frames to increase the size of the client's send window. As it stands now, when the client detects that sending more data will overflow the send window, it will await a window update from the remote receiver before attempting to transmit more data. If no window update comes from the server however, the client will not process any incoming frames from the server including RST_STREAM frames. It is important that if a remote indicates to the client that it can no longer process data with a RST_STREAM with the NO_ERROR flag set that it close the relevant connection instead of hanging indefinitely. See [section 8.1 of RFC 7540](https://www.rfc-editor.org/rfc/rfc7540#section-8.1) for description of this scenario.
> 
> ### Summary of Changes & Justification
> The hanging of the client observed when a RST_STREAM is received is caused by the client not creating a responseSubscriber due to the response being seen as incomplete. The reason this happens is because in this case where the client cannot send more data due to the window being full, the request body is only partially finished sending. A responseSubscriber for reading the response from the server (i.e. any incoming frames) is only initialised when the request body has completed sending. However, this will not occur as the client is waiting for window updates.
> 
> If a RST_STREAM with NO_ERROR is observed, the request body will be completed without sending all of its data. This will initialise the responseSubcriber for the request and enable the client to process all incoming data from the client before subsequently processing the afforemntioned RST_STREAM frame.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk pull/12694/head:pull/12694` \
> `$ git checkout pull/12694`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/12694` \
> `$ git pull https://git.openjdk.org/jdk pull/12694/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 12694`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 12694`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/12694.diff">https://git.openjdk.org/jdk/pull/12694.diff</a>
> 
> </details>

Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:

  8293786: Reset only on unconsumed IS in sendResponseHeaders

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12694/files
  - new: https://git.openjdk.org/jdk/pull/12694/files/b97806f8..2aa936d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12694&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12694&range=04-05

  Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12694/head:pull/12694

PR: https://git.openjdk.org/jdk/pull/12694

From ccleary at openjdk.org  Thu May  4 15:16:21 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 4 May 2023 15:16:21 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v5]
In-Reply-To: <5dctVoAItfiCl9MXbdvkdqVMvrqIXzph-lrep-wWhCk=.f5ddbaf4-b8a2-4a01-b550-463a77430f96@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <AnTvwcQqF01yaqL3VS6-1oNtlRBeKncfjiarNm0qDDI=.1d1b7b9c-cfaf-4ef6-b6f7-afad712a576b@github.com>
 <5dctVoAItfiCl9MXbdvkdqVMvrqIXzph-lrep-wWhCk=.f5ddbaf4-b8a2-4a01-b550-463a77430f96@github.com>
Message-ID: <5ZOGS6kDwfEVTXGSoyjaNyR_4_B9rrZwGrF_gQcBumg=.bf772b4e-7f36-4065-ab46-d922f5665c7b@github.com>

On Wed, 26 Apr 2023 16:40:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293786: Handle neg con length and closing bos in handler
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestExchangeImpl.java line 154:
> 
>> 152:             response.setFlag(HeadersFrame.END_STREAM);
>> 153:             conn.outputQ.put(response);
>> 154:             conn.outputQ.put(new ResetFrame(streamid, ResetFrame.NO_ERROR));
> 
> This doesn't seem right as reset should not be sent in the general case. Reset should only be sent if there remain data to read and we are unwilling to read it. In other words - this should be handled by closing the exchange (when the exchange is closed).

After offline discussions and testing, I added in an additonal check for an unconsumed input stream before sending the Reset Frame. This is similar to how the sending of the Reset Frame in BodyOutputStream.close() is handled.

In particular, the addition of this conditional check for an unconsumed input stream is used when a test sever handler calls`sendResponseHeaders(2xx, -1)`. This has the effect of marking the output stream as closed before `BodyOutputStream.close()` is called, which is why this seemilngly duplicated conditional sending of a reset is needed here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12694#discussion_r1185174592

From dfuchs at openjdk.org  Thu May  4 15:27:19 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 4 May 2023 15:27:19 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v6]
In-Reply-To: <d8q6BIBCCTp21Gu-u_uaUNBv3sgr0HXaJxBrcxmYoy0=.f7421d22-e266-4da8-8f39-d6c4b107b4b1@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <d8q6BIBCCTp21Gu-u_uaUNBv3sgr0HXaJxBrcxmYoy0=.f7421d22-e266-4da8-8f39-d6c4b107b4b1@github.com>
Message-ID: <_CRXBAQc0nFB8BVKCpRZa_XMfR7yFakeQ-XKzeZTI6M=.26553ff2-4aa0-4915-857c-263b600e272d@github.com>

On Thu, 4 May 2023 15:07:12 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> Submitter reported when sending data of a length greater than 64kb using the `HttpClient` with HTTP/2, the HttpClient would hang indefinitely. Through reproducing the issue and analysing logs it was also seen that the HttpClient would not accept any incoming frames in this state. Note that 64kb is the default window size of a HTTP/2 Stream with the `HttpClient`.
>> 
>> The particular server used by the submitter did not emit window update frames to increase the size of the client's send window. As it stands now, when the client detects that sending more data will overflow the send window, it will await a window update from the remote receiver before attempting to transmit more data. If no window update comes from the server however, the client will not process any incoming frames from the server including RST_STREAM frames. It is important that if a remote indicates to the client that it can no longer process data with a RST_STREAM with the NO_ERROR flag set that it close the relevant connection instead of hanging indefinitely. See [section 8.1 of RFC 7540](https://www.rfc-editor.org/rfc/rfc7540#section-8.1) for description of this scenario.
>> 
>> ### Summary of Changes & Justification
>> The hanging of the client observed when a RST_STREAM is received is caused by the client not creating a responseSubscriber due to the response being seen as incomplete. The reason this happens is because in this case where the client cannot send more data due to the window being full, the request body is only partially finished sending. A responseSubscriber for reading the response from the server (i.e. any incoming frames) is only initialised when the request body has completed sending. However, this will not occur as the client is waiting for window updates.
>> 
>> If a RST_STREAM with NO_ERROR is observed, the request body will be completed without sending all of its data. This will initialise the responseSubcriber for the request and enable the client to process all incoming data from the client before subsequently processing the afforemntioned RST_STREAM frame.
>> 
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> 
>> 
>> ### Reviewing
>> <details><summary>Using <code>git</code></summary>
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk pull/12694/head:pull/12694` \
>> `$ git checkout pull/12694`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/12694` \
>> `$ git pull https://git.openjdk.org/jdk pull/12694/head`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 12694`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 12694`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/12694.diff">https://git.openjdk.org/jdk/pull/12694.diff</a>
>> 
>> </details>
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293786: Reset only on unconsumed IS in sendResponseHeaders

The proposed updates look reasonable. I wonder if we could somehow move this code to a method that could be called from both places.

For instance something like:


boolean sendResetIfUnconsumed(BodyInputStream bis) {
    if ((!bis.isEof() || bis.q.size() > 0)) {
        conn.outputQ.put(new ResetFrame(streamid, ResetFrame.NO_ERROR));
    }
}

-------------

PR Review: https://git.openjdk.org/jdk/pull/12694#pullrequestreview-1413382959

From ccleary at openjdk.org  Thu May  4 15:46:18 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 4 May 2023 15:46:18 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v6]
In-Reply-To: <_CRXBAQc0nFB8BVKCpRZa_XMfR7yFakeQ-XKzeZTI6M=.26553ff2-4aa0-4915-857c-263b600e272d@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <d8q6BIBCCTp21Gu-u_uaUNBv3sgr0HXaJxBrcxmYoy0=.f7421d22-e266-4da8-8f39-d6c4b107b4b1@github.com>
 <_CRXBAQc0nFB8BVKCpRZa_XMfR7yFakeQ-XKzeZTI6M=.26553ff2-4aa0-4915-857c-263b600e272d@github.com>
Message-ID: <DMTmVw5YcP-_uNcC1gXONwZhJ7kSIUWK8r6GNnJ9FJw=.2f79ef00-b9b4-4870-a2fa-c746d9dd3cf2@github.com>

On Thu, 4 May 2023 15:24:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The proposed updates look reasonable. I wonder if we could somehow move this code to a method that could be called from both places.
> 
> For instance something like:
> 
> ```
> boolean sendResetIfUnconsumed(BodyInputStream bis) {
>     if ((!bis.isEof() || bis.q.size() > 0)) {
>         conn.outputQ.put(new ResetFrame(streamid, ResetFrame.NO_ERROR));
>     }
> } 
> ```

Maybe that kind of method you described could be placed in BodyInputStream, then it could be called from the Exchange and BodyOutputStream easily.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12694#issuecomment-1535006537

From ccleary at openjdk.org  Thu May  4 16:18:17 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Thu, 4 May 2023 16:18:17 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v6]
In-Reply-To: <d8q6BIBCCTp21Gu-u_uaUNBv3sgr0HXaJxBrcxmYoy0=.f7421d22-e266-4da8-8f39-d6c4b107b4b1@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <d8q6BIBCCTp21Gu-u_uaUNBv3sgr0HXaJxBrcxmYoy0=.f7421d22-e266-4da8-8f39-d6c4b107b4b1@github.com>
Message-ID: <RKHfVr8jh-lEoD0EgmUe9CX2rcaIbRV76r9Ii01JH0s=.80e89c97-4036-4101-ab0a-d1a168bd8edc@github.com>

On Thu, 4 May 2023 15:07:12 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> Submitter reported when sending data of a length greater than 64kb using the `HttpClient` with HTTP/2, the HttpClient would hang indefinitely. Through reproducing the issue and analysing logs it was also seen that the HttpClient would not accept any incoming frames in this state. Note that 64kb is the default window size of a HTTP/2 Stream with the `HttpClient`.
>> 
>> The particular server used by the submitter did not emit window update frames to increase the size of the client's send window. As it stands now, when the client detects that sending more data will overflow the send window, it will await a window update from the remote receiver before attempting to transmit more data. If no window update comes from the server however, the client will not process any incoming frames from the server including RST_STREAM frames. It is important that if a remote indicates to the client that it can no longer process data with a RST_STREAM with the NO_ERROR flag set that it close the relevant connection instead of hanging indefinitely. See [section 8.1 of RFC 7540](https://www.rfc-editor.org/rfc/rfc7540#section-8.1) for description of this scenario.
>> 
>> ### Summary of Changes & Justification
>> The hanging of the client observed when a RST_STREAM is received is caused by the client not creating a responseSubscriber due to the response being seen as incomplete. The reason this happens is because in this case where the client cannot send more data due to the window being full, the request body is only partially finished sending. A responseSubscriber for reading the response from the server (i.e. any incoming frames) is only initialised when the request body has completed sending. However, this will not occur as the client is waiting for window updates.
>> 
>> If a RST_STREAM with NO_ERROR is observed, the request body will be completed without sending all of its data. This will initialise the responseSubcriber for the request and enable the client to process all incoming data from the client before subsequently processing the afforemntioned RST_STREAM frame.
>> 
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> 
>> 
>> ### Reviewing
>> <details><summary>Using <code>git</code></summary>
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk pull/12694/head:pull/12694` \
>> `$ git checkout pull/12694`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/12694` \
>> `$ git pull https://git.openjdk.org/jdk pull/12694/head`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 12694`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 12694`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/12694.diff">https://git.openjdk.org/jdk/pull/12694.diff</a>
>> 
>> </details>
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293786: Reset only on unconsumed IS in sendResponseHeaders

if (bis.unconsumedStream()) {
                // Send a reset if there is still unconsumed data in the input stream
                sendReset(EMPTY_BARRAY, 0, 0, ResetFrame.NO_ERROR);
            }

           ...

           if (is instanceof BodyInputStream bis && bis.unconsumedStream()) {
                conn.outputQ.put(new ResetFrame(streamid, ResetFrame.NO_ERROR));
            }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12694#issuecomment-1535024859

From duke at openjdk.org  Thu May  4 20:31:32 2023
From: duke at openjdk.org (Dhamoder Nalla)
Date: Thu, 4 May 2023 20:31:32 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance [v2]
In-Reply-To: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
Message-ID: <UvKB0YQgyBfdj_yUzclD3q916l37O-U4icvfwP7j9Mc=.e8262f3e-9b26-4940-9ed4-7ea4fc4762d3@github.com>

> Issue 8305763 : Using underscores in the name for a URI triggers a silent exception in the java standard library, which consumes 5% of the CPU.
> 
> Exception:
> java.net.URISyntaxException: Illegal character in hostname at index N: xyz1_abcd.com
>     at java.base/java.net.URI$Parser.fail(URI.java:2943)
>     at java.base/java.net.URI$Parser.parseHostname(URI.java:3487)
>     at java.base/java.net.URI$Parser.parseServer(URI.java:3329)
>     
>     This exception is silent and does not produce any messages, except for ODP profiler, there is no other evidence that it?s happening (the stack trace above was printed after changes to Java library). The reason for this is because of how the URI creation is implemented in the java.net.URI class. There are two paths for creating a valid URI, and one of them goes through an exception.
> 
> We can see that if parseServer fails, there is still a way the authority gets assigned and we don?t throw an exception from the method. This means, not being able to parse the server is ok and the exception is silenced. In our case, the server parsing fails because we find an illegal character, as only alphanumeric and dash characters are allowed.

Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:

  Addressing CR comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13430/files
  - new: https://git.openjdk.org/jdk/pull/13430/files/3353228b..00fa09ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13430&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13430&range=00-01

  Stats: 38 lines in 1 file changed: 16 ins; 11 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13430/head:pull/13430

PR: https://git.openjdk.org/jdk/pull/13430

From ccleary at openjdk.org  Fri May  5 08:54:26 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Fri, 5 May 2023 08:54:26 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v7]
In-Reply-To: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
Message-ID: <N5StOp3hQz2paJc_996lUtDdI5LlGyy0WJy3mps9td8=.5f6a627a-2c18-4e06-9a50-d1d91ccc73e6@github.com>

> ### Description
> Submitter reported when sending data of a length greater than 64kb using the `HttpClient` with HTTP/2, the HttpClient would hang indefinitely. Through reproducing the issue and analysing logs it was also seen that the HttpClient would not accept any incoming frames in this state. Note that 64kb is the default window size of a HTTP/2 Stream with the `HttpClient`.
> 
> The particular server used by the submitter did not emit window update frames to increase the size of the client's send window. As it stands now, when the client detects that sending more data will overflow the send window, it will await a window update from the remote receiver before attempting to transmit more data. If no window update comes from the server however, the client will not process any incoming frames from the server including RST_STREAM frames. It is important that if a remote indicates to the client that it can no longer process data with a RST_STREAM with the NO_ERROR flag set that it close the relevant connection instead of hanging indefinitely. See [section 8.1 of RFC 7540](https://www.rfc-editor.org/rfc/rfc7540#section-8.1) for description of this scenario.
> 
> ### Summary of Changes & Justification
> The hanging of the client observed when a RST_STREAM is received is caused by the client not creating a responseSubscriber due to the response being seen as incomplete. The reason this happens is because in this case where the client cannot send more data due to the window being full, the request body is only partially finished sending. A responseSubscriber for reading the response from the server (i.e. any incoming frames) is only initialised when the request body has completed sending. However, this will not occur as the client is waiting for window updates.
> 
> If a RST_STREAM with NO_ERROR is observed, the request body will be completed without sending all of its data. This will initialise the responseSubcriber for the request and enable the client to process all incoming data from the client before subsequently processing the afforemntioned RST_STREAM frame.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk pull/12694/head:pull/12694` \
> `$ git checkout pull/12694`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/12694` \
> `$ git pull https://git.openjdk.org/jdk pull/12694/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 12694`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 12694`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/12694.diff">https://git.openjdk.org/jdk/pull/12694.diff</a>
> 
> </details>

Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:

  8293786: Added unconsumed method to BodyInputStream

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12694/files
  - new: https://git.openjdk.org/jdk/pull/12694/files/2aa936d4..e594917a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12694&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12694&range=05-06

  Stats: 10 lines in 3 files changed: 4 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12694/head:pull/12694

PR: https://git.openjdk.org/jdk/pull/12694

From djelinski at openjdk.org  Fri May  5 10:53:17 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 5 May 2023 10:53:17 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking [v4]
In-Reply-To: <wXcO_sl2lfs5UulU_XILgPZ6JSbtjHcoFTlCTIxuUwQ=.7136dbdd-a92e-4e36-8a02-27a78de44b7f@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
 <wXcO_sl2lfs5UulU_XILgPZ6JSbtjHcoFTlCTIxuUwQ=.7136dbdd-a92e-4e36-8a02-27a78de44b7f@github.com>
Message-ID: <w-EKR8wOmNrxQYN3uQlHKQuSXTKqGEArwXIW0Tottf0=.6154d174-9ded-4d62-8282-aad9c7ffc34e@github.com>

On Wed, 3 May 2023 11:47:13 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Currently it is possible for `HttpURLConnection` with the `Expect: 100-Continue` header to timeout awaiting for a server response. According to [RFC-7231](https://www.rfc-editor.org/rfc/rfc7231#section-5.1.1) a client `SHOULD NOT wait for an indefinite period before sending the message body`.
>> 
>> This PR changes the existing `expect100Continue` method to wait for a maximum of 5 seconds for a server response, this will be shorter if a timeout is set. If no response is received, the message is sent regardless.
>> 
>> Tests have been added to account for different scenarios that currently timeout, and the changes have been tested against tiers 1,2 and 3.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13330#pullrequestreview-1414567330

From weijun at openjdk.org  Fri May  5 14:31:17 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 May 2023 14:31:17 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
Message-ID: <5jPCrDCpjkHcnEsquRdHiG1MpPcNnr3gduXawzaIXiA=.c8c0ee74-34ae-4767-ab52-a09b10683dee@github.com>

On Wed, 5 Apr 2023 16:45:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248)
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedback

We have quite some `standard-names.html#anchorName` links (Ex: https://github.com/openjdk/jdk/blob/f804f2ce8ef7a859aae021b20cbdcd9e34f9fb94/src/java.base/share/classes/java/security/Signature.java#L111). I don't see any of them here. Is this style allowed in a `@spec` tag?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1536346418

From dfuchs at openjdk.org  Fri May  5 15:48:29 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 5 May 2023 15:48:29 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v7]
In-Reply-To: <N5StOp3hQz2paJc_996lUtDdI5LlGyy0WJy3mps9td8=.5f6a627a-2c18-4e06-9a50-d1d91ccc73e6@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <N5StOp3hQz2paJc_996lUtDdI5LlGyy0WJy3mps9td8=.5f6a627a-2c18-4e06-9a50-d1d91ccc73e6@github.com>
Message-ID: <0BE_3eRPJprA00K8ZGn_k_uUgrUHDE-EZKH-3PFmf2Y=.763c2cc5-d06c-4639-86ae-de4ce7fcb668@github.com>

On Fri, 5 May 2023 08:54:26 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> Submitter reported when sending data of a length greater than 64kb using the `HttpClient` with HTTP/2, the HttpClient would hang indefinitely. Through reproducing the issue and analysing logs it was also seen that the HttpClient would not accept any incoming frames in this state. Note that 64kb is the default window size of a HTTP/2 Stream with the `HttpClient`.
>> 
>> The particular server used by the submitter did not emit window update frames to increase the size of the client's send window. As it stands now, when the client detects that sending more data will overflow the send window, it will await a window update from the remote receiver before attempting to transmit more data. If no window update comes from the server however, the client will not process any incoming frames from the server including RST_STREAM frames. It is important that if a remote indicates to the client that it can no longer process data with a RST_STREAM with the NO_ERROR flag set that it close the relevant connection instead of hanging indefinitely. See [section 8.1 of RFC 7540](https://www.rfc-editor.org/rfc/rfc7540#section-8.1) for description of this scenario.
>> 
>> ### Summary of Changes & Justification
>> The hanging of the client observed when a RST_STREAM is received is caused by the client not creating a responseSubscriber due to the response being seen as incomplete. The reason this happens is because in this case where the client cannot send more data due to the window being full, the request body is only partially finished sending. A responseSubscriber for reading the response from the server (i.e. any incoming frames) is only initialised when the request body has completed sending. However, this will not occur as the client is waiting for window updates.
>> 
>> If a RST_STREAM with NO_ERROR is observed, the request body will be completed without sending all of its data. This will initialise the responseSubcriber for the request and enable the client to process all incoming data from the client before subsequently processing the afforemntioned RST_STREAM frame.
>> 
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> 
>> 
>> ### Reviewing
>> <details><summary>Using <code>git</code></summary>
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk pull/12694/head:pull/12694` \
>> `$ git checkout pull/12694`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/12694` \
>> `$ git pull https://git.openjdk.org/jdk pull/12694/head`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 12694`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 12694`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/12694.diff">https://git.openjdk.org/jdk/pull/12694.diff</a>
>> 
>> </details>
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293786: Added unconsumed method to BodyInputStream

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12694#pullrequestreview-1415037735

From jjg at openjdk.org  Fri May  5 20:55:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 5 May 2023 20:55:17 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <5jPCrDCpjkHcnEsquRdHiG1MpPcNnr3gduXawzaIXiA=.c8c0ee74-34ae-4767-ab52-a09b10683dee@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
 <5jPCrDCpjkHcnEsquRdHiG1MpPcNnr3gduXawzaIXiA=.c8c0ee74-34ae-4767-ab52-a09b10683dee@github.com>
Message-ID: <_4-xwqG0X3oF_UgPT1B5FlfCqsdtQZ21PpdXXkgSS6o=.e3747de4-d20f-4bb7-8d96-da63b668fd65@github.com>

On Fri, 5 May 2023 14:28:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> We have quite some `standard-names.html#anchorName` links (Ex:
> 
> https://github.com/openjdk/jdk/blob/f804f2ce8ef7a859aae021b20cbdcd9e34f9fb94/src/java.base/share/classes/java/security/Signature.java#L111
> 
> ). I don't see any of them here. Is this style allowed in a `@spec` tag?
> I also see no `#anchorName` for RFC links.
> 
> And in this case, shall I also spell out the section name in the text?

1. You can use a relative URL, relative to the `specs` directory, so something like:<br>
   `@spec security/standard-names.html Standard Names`

2. The intent of the `@spec` tag is to identify the overall/root URL for each specification, not to identify all the interesting places within that specification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1536766590

From ccleary at openjdk.org  Mon May  8 10:26:27 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 8 May 2023 10:26:27 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v7]
In-Reply-To: <N5StOp3hQz2paJc_996lUtDdI5LlGyy0WJy3mps9td8=.5f6a627a-2c18-4e06-9a50-d1d91ccc73e6@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <N5StOp3hQz2paJc_996lUtDdI5LlGyy0WJy3mps9td8=.5f6a627a-2c18-4e06-9a50-d1d91ccc73e6@github.com>
Message-ID: <y-wEbIKpLeemTVUDkjjMxdRmSXP4m347vT8CGmOaw-U=.9ba05a3c-a295-458d-a179-ba16ba435378@github.com>

On Fri, 5 May 2023 08:54:26 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> Submitter reported when sending data of a length greater than 64kb using the `HttpClient` with HTTP/2, the HttpClient would hang indefinitely. Through reproducing the issue and analysing logs it was also seen that the HttpClient would not accept any incoming frames in this state. Note that 64kb is the default window size of a HTTP/2 Stream with the `HttpClient`.
>> 
>> The particular server used by the submitter did not emit window update frames to increase the size of the client's send window. As it stands now, when the client detects that sending more data will overflow the send window, it will await a window update from the remote receiver before attempting to transmit more data. If no window update comes from the server however, the client will not process any incoming frames from the server including RST_STREAM frames. It is important that if a remote indicates to the client that it can no longer process data with a RST_STREAM with the NO_ERROR flag set that it close the relevant connection instead of hanging indefinitely. See [section 8.1 of RFC 7540](https://www.rfc-editor.org/rfc/rfc7540#section-8.1) for description of this scenario.
>> 
>> ### Summary of Changes & Justification
>> The hanging of the client observed when a RST_STREAM is received is caused by the client not creating a responseSubscriber due to the response being seen as incomplete. The reason this happens is because in this case where the client cannot send more data due to the window being full, the request body is only partially finished sending. A responseSubscriber for reading the response from the server (i.e. any incoming frames) is only initialised when the request body has completed sending. However, this will not occur as the client is waiting for window updates.
>> 
>> If a RST_STREAM with NO_ERROR is observed, the request body will be completed without sending all of its data. This will initialise the responseSubcriber for the request and enable the client to process all incoming data from the client before subsequently processing the afforemntioned RST_STREAM frame.
>> 
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> 
>> 
>> ### Reviewing
>> <details><summary>Using <code>git</code></summary>
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk pull/12694/head:pull/12694` \
>> `$ git checkout pull/12694`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/12694` \
>> `$ git pull https://git.openjdk.org/jdk pull/12694/head`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 12694`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 12694`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/12694.diff">https://git.openjdk.org/jdk/pull/12694.diff</a>
>> 
>> </details>
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293786: Added unconsumed method to BodyInputStream

@djelinski this PR has been updated a lot in the past couple of weeks, if theres anything else to add reviews are really appreciated if you have the time. Otherwise I think this PR is finally in good shape. Thanks for the reviews so far!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12694#issuecomment-1538135160

From djelinski at openjdk.org  Mon May  8 14:18:26 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 8 May 2023 14:18:26 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v7]
In-Reply-To: <N5StOp3hQz2paJc_996lUtDdI5LlGyy0WJy3mps9td8=.5f6a627a-2c18-4e06-9a50-d1d91ccc73e6@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <N5StOp3hQz2paJc_996lUtDdI5LlGyy0WJy3mps9td8=.5f6a627a-2c18-4e06-9a50-d1d91ccc73e6@github.com>
Message-ID: <nBMVKuWkdVtdJ3uKvaIFmIx8yku_E9Dsxa96Qw3k7Ec=.d8c742dc-651d-4dac-a062-79caae251993@github.com>

On Fri, 5 May 2023 08:54:26 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> ### Description
>> Submitter reported when sending data of a length greater than 64kb using the `HttpClient` with HTTP/2, the HttpClient would hang indefinitely. Through reproducing the issue and analysing logs it was also seen that the HttpClient would not accept any incoming frames in this state. Note that 64kb is the default window size of a HTTP/2 Stream with the `HttpClient`.
>> 
>> The particular server used by the submitter did not emit window update frames to increase the size of the client's send window. As it stands now, when the client detects that sending more data will overflow the send window, it will await a window update from the remote receiver before attempting to transmit more data. If no window update comes from the server however, the client will not process any incoming frames from the server including RST_STREAM frames. It is important that if a remote indicates to the client that it can no longer process data with a RST_STREAM with the NO_ERROR flag set that it close the relevant connection instead of hanging indefinitely. See [section 8.1 of RFC 7540](https://www.rfc-editor.org/rfc/rfc7540#section-8.1) for description of this scenario.
>> 
>> ### Summary of Changes & Justification
>> The hanging of the client observed when a RST_STREAM is received is caused by the client not creating a responseSubscriber due to the response being seen as incomplete. The reason this happens is because in this case where the client cannot send more data due to the window being full, the request body is only partially finished sending. A responseSubscriber for reading the response from the server (i.e. any incoming frames) is only initialised when the request body has completed sending. However, this will not occur as the client is waiting for window updates.
>> 
>> If a RST_STREAM with NO_ERROR is observed, the request body will be completed without sending all of its data. This will initialise the responseSubcriber for the request and enable the client to process all incoming data from the client before subsequently processing the afforemntioned RST_STREAM frame.
>> 
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> 
>> 
>> 
>> ### Reviewing
>> <details><summary>Using <code>git</code></summary>
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk pull/12694/head:pull/12694` \
>> `$ git checkout pull/12694`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/12694` \
>> `$ git pull https://git.openjdk.org/jdk pull/12694/head`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 12694`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 12694`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/12694.diff">https://git.openjdk.org/jdk/pull/12694.diff</a>
>> 
>> </details>
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293786: Added unconsumed method to BodyInputStream

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12694#pullrequestreview-1416893932

From duke at openjdk.org  Mon May  8 14:37:40 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 8 May 2023 14:37:40 GMT
Subject: Integrated: 8054022: HttpURLConnection timeouts with Expect:
 100-Continue and no chunking
In-Reply-To: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
Message-ID: <RkXAGSzqOkiDSjVB0lnGoTmCQINB-KrK3ZBJo2HKENA=.8fd74be8-4364-4839-8395-0129821e069e@github.com>

On Tue, 4 Apr 2023 17:02:08 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Currently it is possible for `HttpURLConnection` with the `Expect: 100-Continue` header to timeout awaiting for a server response. According to [RFC-7231](https://www.rfc-editor.org/rfc/rfc7231#section-5.1.1) a client `SHOULD NOT wait for an indefinite period before sending the message body`.
> 
> This PR changes the existing `expect100Continue` method to wait for a maximum of 5 seconds for a server response, this will be shorter if a timeout is set. If no response is received, the message is sent regardless.
> 
> Tests have been added to account for different scenarios that currently timeout, and the changes have been tested against tiers 1,2 and 3.

This pull request has now been integrated.

Changeset: 4b02956d
Author:    Darragh Clarke <darraghclarke98 at gmail.com>
Committer: Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b02956d42c29ce32894f15411d3abe12b07dccd
Stats:     504 lines in 2 files changed: 465 ins; 6 del; 33 mod

8054022: HttpURLConnection timeouts with Expect: 100-Continue and no chunking

Reviewed-by: djelinski, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/13330

From ccleary at openjdk.org  Mon May  8 14:53:46 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 8 May 2023 14:53:46 GMT
Subject: Integrated: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2
In-Reply-To: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
Message-ID: <fDpY5oghWwcCRIQ1EhKPSlsufCDAWehaCCghHkiaUoA=.2b9d6ea9-aa57-42cd-a0e8-4c60398cc055@github.com>

On Tue, 21 Feb 2023 17:31:29 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> ### Description
> Submitter reported when sending data of a length greater than 64kb using the `HttpClient` with HTTP/2, the HttpClient would hang indefinitely. Through reproducing the issue and analysing logs it was also seen that the HttpClient would not accept any incoming frames in this state. Note that 64kb is the default window size of a HTTP/2 Stream with the `HttpClient`.
> 
> The particular server used by the submitter did not emit window update frames to increase the size of the client's send window. As it stands now, when the client detects that sending more data will overflow the send window, it will await a window update from the remote receiver before attempting to transmit more data. If no window update comes from the server however, the client will not process any incoming frames from the server including RST_STREAM frames. It is important that if a remote indicates to the client that it can no longer process data with a RST_STREAM with the NO_ERROR flag set that it close the relevant connection instead of hanging indefinitely. See [section 8.1 of RFC 7540](https://www.rfc-editor.org/rfc/rfc7540#section-8.1) for description of this scenario.
> 
> ### Summary of Changes & Justification
> The hanging of the client observed when a RST_STREAM is received is caused by the client not creating a responseSubscriber due to the response being seen as incomplete. The reason this happens is because in this case where the client cannot send more data due to the window being full, the request body is only partially finished sending. A responseSubscriber for reading the response from the server (i.e. any incoming frames) is only initialised when the request body has completed sending. However, this will not occur as the client is waiting for window updates.
> 
> If a RST_STREAM with NO_ERROR is observed, the request body will be completed without sending all of its data. This will initialise the responseSubcriber for the request and enable the client to process all incoming data from the client before subsequently processing the afforemntioned RST_STREAM frame.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk pull/12694/head:pull/12694` \
> `$ git checkout pull/12694`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/12694` \
> `$ git pull https://git.openjdk.org/jdk pull/12694/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 12694`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 12694`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/12694.diff">https://git.openjdk.org/jdk/pull/12694.diff</a>
> 
> </details>

This pull request has now been integrated.

Changeset: ad90fb6d
Author:    Conor Cleary <ccleary at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad90fb6da38da066dfc7a5439196887bbcda766f
Stats:     237 lines in 6 files changed: 220 ins; 4 del; 13 mod

8293786: HttpClient will not send more than 64 kb of data from the 2nd request in http2

Reviewed-by: dfuchs, djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/12694

From jbechberger at openjdk.org  Tue May  9 10:47:33 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 9 May 2023 10:47:33 GMT
Subject: RFR: 8307732: build-test-lib is broken
Message-ID: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>

Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor).

-------------

Commit messages:
 - Fix make build-test-lib

Changes: https://git.openjdk.org/jdk/pull/13885/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13885&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307732
  Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13885.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13885/head:pull/13885

PR: https://git.openjdk.org/jdk/pull/13885

From djelinski at openjdk.org  Tue May  9 11:48:22 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 9 May 2023 11:48:22 GMT
Subject: RFR: 8307732: build-test-lib is broken
In-Reply-To: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
References: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
Message-ID: <mouu2_QFzU3f4HfSIOwFl7dAHzvV-Ow-iDhYZrp_Vd8=.2cce5a51-0f61-4627-8392-5087cb661df7@github.com>

On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor).

That's interesting. How did you find this? Is the result of this target used anywhere?
As far as I could tell, the `build-test-lib` target itself is not used anywhere. The classes that fail to compile here are used by tests without any problems - each test specifies the necessary imports individually. Should we remove this make target instead?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13885#issuecomment-1540007948

From jbechberger at openjdk.org  Tue May  9 11:55:22 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 9 May 2023 11:55:22 GMT
Subject: RFR: 8307732: build-test-lib is broken
In-Reply-To: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
References: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
Message-ID: <WLK5T_ZlXpnPs-WjxDf8b7SrRmvSUJwGg8X41Y0TkPY=.32cc60e2-0fde-4c55-994d-4f92409167f9@github.com>

On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor).

Well, I wanted to use the WhiteBox testing API for my ASGST related tests (see https://github.com/parttimenerd/trace_tester) and found in the wiki https://wiki.openjdk.org/display/HotSpot/The+WhiteBox+testing+API, but the build instructions didn't work for me, so I fixed them.

I need the WhiteBox API methods to ensure that a specific method is compiled, inlined, ..., when testing whether my API implementation gets it correct.

The tests will later be partially included in the JTREG tests, but the external project makes prototyping easier.

> Should we remove this make target instead?

No, this would make writing extensive tests harder.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13885#issuecomment-1540010987

From erikj at openjdk.org  Tue May  9 12:44:30 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 9 May 2023 12:44:30 GMT
Subject: RFR: 8307732: build-test-lib is broken
In-Reply-To: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
References: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
Message-ID: <SFlVG9TC79a4pvb7M05HzlYvFK5cnAXBCCpQB9dJ46w=.ca10f70d-304c-426d-b044-00a105cf2418@github.com>

On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor).

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13885#pullrequestreview-1418536278

From djelinski at openjdk.org  Tue May  9 13:29:24 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 9 May 2023 13:29:24 GMT
Subject: RFR: 8307732: build-test-lib is broken
In-Reply-To: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
References: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
Message-ID: <96PPtoUC3C26Ox6ABVtF9S64fZYi0HFRcHI8o_L4iAs=.950cfee3-ddb5-41ef-b2ca-6802c731a8a5@github.com>

On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor).

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13885#pullrequestreview-1418633035

From michaelm at openjdk.org  Tue May  9 13:55:27 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 9 May 2023 13:55:27 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v7]
In-Reply-To: <IZ2tvUTjaeMVFxt-yA3AlJCx55ZSrPJ4TGbZmLFMs9g=.d8d9fd03-b99c-4aee-82b4-cbf35ad4b09f@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <IZ2tvUTjaeMVFxt-yA3AlJCx55ZSrPJ4TGbZmLFMs9g=.d8d9fd03-b99c-4aee-82b4-cbf35ad4b09f@github.com>
Message-ID: <FJCnT7u83JcMIYKBoCVX42xDL3Jr7dBMMR9DWWlhI_M=.196899a9-1593-4658-8bde-015eba0e9f9a@github.com>

On Thu, 4 May 2023 06:05:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I would like to get preliminary feedback about the provided patch.
>> 
>> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
>> 
>> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
>> 
>> At the moment this cache can be configured by the application using the following two properties:
>>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
>> 
>> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
>> 
>> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
>> 
>> Possible solutions:
>>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
>> 
>> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
>> 
>> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
>> 
>> 
>> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
>> https://www.rfc-editor.org/rfc/rfc8767
>> 
>> Comments about current and other possible implementations:
>>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>>  * The refresh timeout includes the time spent on the server lookup. So if we have to refresh every 2 seconds, but in lookup, we spend 3 seconds then we will request the server on each lookup. Another implementation may spend 3 seconds on lookup and then additional use the cached value for two seconds.
>>  * The extended timeout is a kind of "maximum stale timer" from the RFC above, but it starts counting not from the moment the record expired, but from the moment we added it to the cache. Another possible implementation may start counting from the moment the TTL expired, so the overall usage of the value will be sum ttl+extended.
>>  * The extended timeout has a hard deadline which is never changed during execution, for example, if it sets for 1 day, then at the end of the day we should make a successful lookup to recache the value otherwise we will start to use the "negative" cache. Other implementations may shift the expiration time on every successful sync.
>> 
>> Any thoughts about other possibilities?
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete 7 days cap

Changes requested by michaelm (Reviewer).

src/java.base/share/classes/java/net/InetAddress.java line 217:

> 215:  * setting is to cache for an implementation specific period of time.
> 216:  * <p>
> 217:  * If the value of this property is large than "networkaddress.cache.ttl" then

Suggestion:

 * If the value of this property is larger than "networkaddress.cache.ttl" then

src/java.base/share/classes/java/net/InetAddress.java line 224:

> 222:  * 30 seconds.
> 223:  * <p>
> 224:  * A value of 0 (zero) do not use stale names.

Suggestion:

 * A value of 0 (zero) means do not use stale names.

src/java.base/share/classes/java/net/InetAddress.java line 1079:

> 1077:         /**
> 1078:          * Overrides the parent method to skip deleting the record from the
> 1079:          * cache if the staled data can still be used. Note to update the

Suggestion:

         * cache if the stale data can still be used. Note to update the

-------------

PR Review: https://git.openjdk.org/jdk/pull/13285#pullrequestreview-1418264763
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1188386107
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1188386731
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1188403718

From michaelm at openjdk.org  Tue May  9 13:59:32 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 9 May 2023 13:59:32 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v7]
In-Reply-To: <IZ2tvUTjaeMVFxt-yA3AlJCx55ZSrPJ4TGbZmLFMs9g=.d8d9fd03-b99c-4aee-82b4-cbf35ad4b09f@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <IZ2tvUTjaeMVFxt-yA3AlJCx55ZSrPJ4TGbZmLFMs9g=.d8d9fd03-b99c-4aee-82b4-cbf35ad4b09f@github.com>
Message-ID: <sI_6kzWem0EhxU3CQDlH8jmyELM7KkeZ52hLfIIshFU=.487045e6-02ea-4275-b67d-69b598366f9d@github.com>

On Thu, 4 May 2023 06:05:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I would like to get preliminary feedback about the provided patch.
>> 
>> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
>> 
>> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
>> 
>> At the moment this cache can be configured by the application using the following two properties:
>>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
>> 
>> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
>> 
>> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
>> 
>> Possible solutions:
>>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
>> 
>> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
>> 
>> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
>> 
>> 
>> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
>> https://www.rfc-editor.org/rfc/rfc8767
>> 
>> Comments about current and other possible implementations:
>>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>>  * The refresh timeout includes the time spent on the server lookup. So if we have to refresh every 2 seconds, but in lookup, we spend 3 seconds then we will request the server on each lookup. Another implementation may spend 3 seconds on lookup and then additional use the cached value for two seconds.
>>  * The extended timeout is a kind of "maximum stale timer" from the RFC above, but it starts counting not from the moment the record expired, but from the moment we added it to the cache. Another possible implementation may start counting from the moment the TTL expired, so the overall usage of the value will be sum ttl+extended.
>>  * The extended timeout has a hard deadline which is never changed during execution, for example, if it sets for 1 day, then at the end of the day we should make a successful lookup to recache the value otherwise we will start to use the "negative" cache. Other implementations may shift the expiration time on every successful sync.
>> 
>> Any thoughts about other possibilities?
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete 7 days cap

Changes requested by michaelm (Reviewer).

src/java.base/share/classes/java/net/doc-files/net-properties.html line 276:

> 274: 	preferable to use a stale name rather than result of unsuccessful name lookup.
> 275: 	A value of 0 (zero) means do not use stale names.
> 276: 	The default value is implementation-specific.</P>

Suggestion:

	A value of 0 (zero) or if the property is not set means do not use stale names.
	By default, the property is not set.</P>

-------------

PR Review: https://git.openjdk.org/jdk/pull/13285#pullrequestreview-1418695990
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1188639013

From michaelm at openjdk.org  Tue May  9 13:59:33 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 9 May 2023 13:59:33 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v7]
In-Reply-To: <sI_6kzWem0EhxU3CQDlH8jmyELM7KkeZ52hLfIIshFU=.487045e6-02ea-4275-b67d-69b598366f9d@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <IZ2tvUTjaeMVFxt-yA3AlJCx55ZSrPJ4TGbZmLFMs9g=.d8d9fd03-b99c-4aee-82b4-cbf35ad4b09f@github.com>
 <sI_6kzWem0EhxU3CQDlH8jmyELM7KkeZ52hLfIIshFU=.487045e6-02ea-4275-b67d-69b598366f9d@github.com>
Message-ID: <7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>

On Tue, 9 May 2023 13:53:53 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete 7 days cap
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 276:
> 
>> 274: 	preferable to use a stale name rather than result of unsuccessful name lookup.
>> 275: 	A value of 0 (zero) means do not use stale names.
>> 276: 	The default value is implementation-specific.</P>
> 
> Suggestion:
> 
> 	A value of 0 (zero) or if the property is not set means do not use stale names.
> 	By default, the property is not set.</P>

We probably should specify what happens if the stale property is negative. Looks like it might be ignored, which I guess is okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1188643136

From jbechberger at openjdk.org  Wed May 10 11:05:29 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 10 May 2023 11:05:29 GMT
Subject: RFR: 8307732: build-test-lib is broken
In-Reply-To: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
References: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
Message-ID: <VJCB-uutIEw6qfZ8Xs0YUt9hYl-xP2Alto-srMY64hY=.c00ca954-46b6-41ba-8a15-15c0c3d59aaa@github.com>

On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor).

What is preventing this PR from being merged? The CI errors have nothing todo with my change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13885#issuecomment-1541950649

From djelinski at openjdk.org  Wed May 10 12:16:35 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 10 May 2023 12:16:35 GMT
Subject: RFR: 8307732: build-test-lib is broken
In-Reply-To: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
References: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
Message-ID: <TfoTuMoS2tFUCd0_6bBAIb-NUJRqDw54EDvnX_oERXo=.b99b7499-0cb1-4f25-802f-8f7c53765787@github.com>

On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor).

Just making sure everyone had a chance to take a look. I'll sponsor this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13885#issuecomment-1542098317

From jbechberger at openjdk.org  Wed May 10 12:16:36 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 10 May 2023 12:16:36 GMT
Subject: Integrated: 8307732: build-test-lib is broken
In-Reply-To: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
References: <Jy_HuTsRXLU0mhdu2WeIPMmbwRFdvEi7OnKPS7GzRrA=.2c5d33fd-1806-4d51-b88c-731d93a1294f@github.com>
Message-ID: <-ks9idC-Yt78xRIjwDfEfe2TEo6WCG96_HP16peuqwM=.638f9539-d827-4851-beb3-f2dfd013300e@github.com>

On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fixes the issue by adding `--add-exports` for the required modules and making the `HttpHeaderParser` final (fixing an issue with calling overridable methods in a constructor).

This pull request has now been integrated.

Changeset: 0da48f19
Author:    Johannes Bechberger <jbechberger at openjdk.org>
Committer: Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0da48f19cbebe0730d689cb966b886f6f73fb3f1
Stats:     9 lines in 2 files changed: 6 ins; 0 del; 3 mod

8307732: build-test-lib is broken

Reviewed-by: erikj, djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/13885

From dfuchs at openjdk.org  Wed May 10 16:29:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 May 2023 16:29:51 GMT
Subject: RFR: 8307626: java/net/httpclient/FlowAdapter* tests should close the
 HttpClient instances
Message-ID: <Q3DjVj7srUAWZF8PJ5-FS8voeS9vRvVZA8N-bBkQ5tw=.a8ededc6-2249-4371-a068-7e76c632c80f@github.com>

java/net/httpclient/FlowAdapterPublisherTest.java and java/net/httpclient/FlowAdapterSubscriberTest.java create one HttpClient instance per test method. The test should use try-with-resources to close the client instances.

-------------

Commit messages:
 - 8307626

Changes: https://git.openjdk.org/jdk/pull/13909/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13909&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307626
  Stats: 481 lines in 2 files changed: 88 ins; 59 del; 334 mod
  Patch: https://git.openjdk.org/jdk/pull/13909.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13909/head:pull/13909

PR: https://git.openjdk.org/jdk/pull/13909

From aefimov at openjdk.org  Wed May 10 17:28:22 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 10 May 2023 17:28:22 GMT
Subject: RFR: 8307626: java/net/httpclient/FlowAdapter* tests should close
 the HttpClient instances
In-Reply-To: <Q3DjVj7srUAWZF8PJ5-FS8voeS9vRvVZA8N-bBkQ5tw=.a8ededc6-2249-4371-a068-7e76c632c80f@github.com>
References: <Q3DjVj7srUAWZF8PJ5-FS8voeS9vRvVZA8N-bBkQ5tw=.a8ededc6-2249-4371-a068-7e76c632c80f@github.com>
Message-ID: <aHq5cVBLFdmo53wDjk3153-dS1QNni5Dqid_b_PZYSM=.2455aac0-845d-4171-95df-3620b25ffab0@github.com>

On Wed, 10 May 2023 16:19:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> java/net/httpclient/FlowAdapterPublisherTest.java and java/net/httpclient/FlowAdapterSubscriberTest.java create one HttpClient instance per test method. The test should use try-with-resources to close the client instances.

The changes looks good to me

-------------

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13909#pullrequestreview-1421096145

From serb at openjdk.org  Wed May 10 21:58:52 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 May 2023 21:58:52 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v8]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <RmpQ0UW0ax5JETdJuXpHCg-eqQX0oTZRRzbOZmrE3bE=.b416d435-569d-4bbd-a244-dbef98ebe013@github.com>

> I would like to get preliminary feedback about the provided patch.
> 
> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
> 
> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
> 
> At the moment this cache can be configured by the application using the following two properties:
>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
> 
> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
> 
> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
> 
> Possible solutions:
>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
> 
> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
> 
> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
> 
> 
> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
> https://www.rfc-editor.org/rfc/rfc8767
> 
> Comments about current and other possible implementations:
>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>  * The refresh timeout includes the time s...

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13285/files
  - new: https://git.openjdk.org/jdk/pull/13285/files/bd45f00c..aad899b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

PR: https://git.openjdk.org/jdk/pull/13285

From serb at openjdk.org  Wed May 10 22:10:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 May 2023 22:10:43 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v7]
In-Reply-To: <7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <IZ2tvUTjaeMVFxt-yA3AlJCx55ZSrPJ4TGbZmLFMs9g=.d8d9fd03-b99c-4aee-82b4-cbf35ad4b09f@github.com>
 <sI_6kzWem0EhxU3CQDlH8jmyELM7KkeZ52hLfIIshFU=.487045e6-02ea-4275-b67d-69b598366f9d@github.com>
 <7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>
Message-ID: <Wf_vBr0V8XL7JOZ2PG_jkSjzIr6EN0JYCyGmCf3yV4Y=.8e50ad01-de11-4887-b7fe-d3dcf3f434a9@github.com>

On Tue, 9 May 2023 13:56:34 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/doc-files/net-properties.html line 276:
>> 
>>> 274: 	preferable to use a stale name rather than result of unsuccessful name lookup.
>>> 275: 	A value of 0 (zero) means do not use stale names.
>>> 276: 	The default value is implementation-specific.</P>
>> 
>> Suggestion:
>> 
>> 	A value of 0 (zero) or if the property is not set means do not use stale names.
>> 	By default, the property is not set.</P>
>
> We probably should specify what happens if the stale property is negative. Looks like it might be ignored, which I guess is okay.

I have update the text about "property is not set" case, but leave the text about "default value" as implementation-specific, similarly to what we have in the text about "networkaddress.cache.ttl" property, and this allow to change this value in some situations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1190434251

From serb at openjdk.org  Wed May 10 22:10:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 May 2023 22:10:43 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v7]
In-Reply-To: <Wf_vBr0V8XL7JOZ2PG_jkSjzIr6EN0JYCyGmCf3yV4Y=.8e50ad01-de11-4887-b7fe-d3dcf3f434a9@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <IZ2tvUTjaeMVFxt-yA3AlJCx55ZSrPJ4TGbZmLFMs9g=.d8d9fd03-b99c-4aee-82b4-cbf35ad4b09f@github.com>
 <sI_6kzWem0EhxU3CQDlH8jmyELM7KkeZ52hLfIIshFU=.487045e6-02ea-4275-b67d-69b598366f9d@github.com>
 <7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>
 <Wf_vBr0V8XL7JOZ2PG_jkSjzIr6EN0JYCyGmCf3yV4Y=.8e50ad01-de11-4887-b7fe-d3dcf3f434a9@github.com>
Message-ID: <0dVXh91AhVTmtCLu_oJygSKc5M9KjmYXgCgHfFDcEO8=.ec5c485e-f7cc-41af-82e2-537141871c40@github.com>

On Wed, 10 May 2023 22:05:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> We probably should specify what happens if the stale property is negative. Looks like it might be ignored, which I guess is okay.
>
> I have update the text about "property is not set" case, but leave the text about "default value" as implementation-specific, similarly to what we have in the text about "networkaddress.cache.ttl" property, and this allow to change this value in some situations.

Right now the negative value is ignored, and is not mentioned in the new spec, But it could be used to cover "always use the stale data on error" case. So we can change this in the future, but probably it will not be a big deal to update the spec if that will happen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1190435743

From jpai at openjdk.org  Thu May 11 05:51:40 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 May 2023 05:51:40 GMT
Subject: RFR: 8307626: java/net/httpclient/FlowAdapter* tests should close
 the HttpClient instances
In-Reply-To: <Q3DjVj7srUAWZF8PJ5-FS8voeS9vRvVZA8N-bBkQ5tw=.a8ededc6-2249-4371-a068-7e76c632c80f@github.com>
References: <Q3DjVj7srUAWZF8PJ5-FS8voeS9vRvVZA8N-bBkQ5tw=.a8ededc6-2249-4371-a068-7e76c632c80f@github.com>
Message-ID: <Zb9bWJM6KynbUSzVLcBGre48UahS0SVN3KDXAVSNtzs=.c4c860f4-b44e-4396-931e-12b0b9bdeba2@github.com>

On Wed, 10 May 2023 16:19:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> java/net/httpclient/FlowAdapterPublisherTest.java and java/net/httpclient/FlowAdapterSubscriberTest.java create one HttpClient instance per test method. The test should use try-with-resources to close the client instances.

test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java line 100:

> 98:     }
> 99: 
> 100:     private HttpClient newHttpClient(String uri) {

Hello Daniel, the `uri` param doesn't seem to be used in this method. 

Same in the other test class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13909#discussion_r1190662233

From jpai at openjdk.org  Thu May 11 05:56:44 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 May 2023 05:56:44 GMT
Subject: RFR: 8307626: java/net/httpclient/FlowAdapter* tests should close
 the HttpClient instances
In-Reply-To: <Q3DjVj7srUAWZF8PJ5-FS8voeS9vRvVZA8N-bBkQ5tw=.a8ededc6-2249-4371-a068-7e76c632c80f@github.com>
References: <Q3DjVj7srUAWZF8PJ5-FS8voeS9vRvVZA8N-bBkQ5tw=.a8ededc6-2249-4371-a068-7e76c632c80f@github.com>
Message-ID: <qMYTnGpR_3Hfvp_fG96OWKU3o6DkJy0cJ6bldsMTny0=.1ab6163d-b66c-49ec-b229-4877086985e2@github.com>

On Wed, 10 May 2023 16:19:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> java/net/httpclient/FlowAdapterPublisherTest.java and java/net/httpclient/FlowAdapterSubscriberTest.java create one HttpClient instance per test method. The test should use try-with-resources to close the client instances.

This looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13909#pullrequestreview-1421800555

From dfuchs at openjdk.org  Thu May 11 16:35:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 May 2023 16:35:50 GMT
Subject: Integrated: 8307626: java/net/httpclient/FlowAdapter* tests should
 close the HttpClient instances
In-Reply-To: <Q3DjVj7srUAWZF8PJ5-FS8voeS9vRvVZA8N-bBkQ5tw=.a8ededc6-2249-4371-a068-7e76c632c80f@github.com>
References: <Q3DjVj7srUAWZF8PJ5-FS8voeS9vRvVZA8N-bBkQ5tw=.a8ededc6-2249-4371-a068-7e76c632c80f@github.com>
Message-ID: <seXX1WByyeFTKUkNNPYA7zghQ1EwJ0liE0gdlJV4fVU=.4e5ebac8-cf16-41c6-ba15-9e6e8c03fb2b@github.com>

On Wed, 10 May 2023 16:19:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> java/net/httpclient/FlowAdapterPublisherTest.java and java/net/httpclient/FlowAdapterSubscriberTest.java create one HttpClient instance per test method. The test should use try-with-resources to close the client instances.

This pull request has now been integrated.

Changeset: 9ad38cbe
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ad38cbeaf446776c4ab4fdb4605663fc517f11f
Stats:     481 lines in 2 files changed: 88 ins; 59 del; 334 mod

8307626: java/net/httpclient/FlowAdapter* tests should close the HttpClient instances

Reviewed-by: aefimov, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13909

From jlu at openjdk.org  Thu May 11 20:21:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:21:57 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Convert the merged master changes to UTF-8
 - Merge master and fix conflicts
 - Close streams when finished loading into props
 - Adjust CF test to read in with UTF-8 to fix failing test
 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties
 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

-------------

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05
  Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu May 11 21:39:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:39:50 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <w-aBr-h4WVCyWPDEHHatqoQcdQJp6dN4eld2Y-85Ak4=.558819ae-881a-42fb-8b67-7a6b5618e323@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. 

Although the default file-encoding for .properties can be switched to UTF-8, it is not the default.

Wondering what some solutions/thoughts to this are.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830

From naoto at openjdk.org  Thu May 11 21:51:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 21:51:13 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480

From xuelei at openjdk.org  Fri May 12 19:51:57 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 12 May 2023 19:51:57 GMT
Subject: RFR: 8308022: update for deprecated sprintf for java.base
Message-ID: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>

Hi,

May I have this update reviewed?

The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.

Thanks,
Xuelei

-------------

Commit messages:
 - update copyright year
 - 8308022: update for deprecated sprintf for java.base

Changes: https://git.openjdk.org/jdk/pull/13963/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13963&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308022
  Stats: 44 lines in 9 files changed: 5 ins; 0 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/13963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13963/head:pull/13963

PR: https://git.openjdk.org/jdk/pull/13963

From dfuchs at openjdk.org  Mon May 15 16:22:00 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 15 May 2023 16:22:00 GMT
Subject: RFR: 8308024: HttpClient (HTTP/1.1) sends an extraneous empty chunk if
 the BodyPublisher supplies an empty buffer
Message-ID: <WzhJYnQ0CmI-ydT7mgz8utJyhWzDPAM-6duNn7Qks5I=.c59b17d5-1d88-4c94-8133-606742540d68@github.com>

When using HTTP/1.1, if a BodyPublisher reports an unknown length (-1), the HttpClient will send the request body in Chunked mode. If the publisher publishes an empty byte buffer, the client will generate an empty chunk, which the server will interpret as the end of the request body. Sending an empty chunk can never be valid, unless it's the last body chunk and marks the end of the body.

A new subclass of `AbstractNoBody.java` `NoBodyPartThree.java` is created to check this scenario. While at it, the tests `java/net/httpclient/NoBodyPartOne.java` and `java/net/httpclient/NoBodyPartTwo.java` which create a lot of clients are also updated to make use of `HttpClient::close`.

-------------

Commit messages:
 - Fixed Http1Request::StreamSubscriber
 - More debug traces
 - 8308024

Changes: https://git.openjdk.org/jdk/pull/13988/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13988&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308024
  Stats: 454 lines in 5 files changed: 283 ins; 37 del; 134 mod
  Patch: https://git.openjdk.org/jdk/pull/13988.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13988/head:pull/13988

PR: https://git.openjdk.org/jdk/pull/13988

From dfuchs at openjdk.org  Mon May 15 16:31:54 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 15 May 2023 16:31:54 GMT
Subject: RFR: 8308024: HttpClient (HTTP/1.1) sends an extraneous empty
 chunk if the BodyPublisher supplies an empty buffer [v2]
In-Reply-To: <WzhJYnQ0CmI-ydT7mgz8utJyhWzDPAM-6duNn7Qks5I=.c59b17d5-1d88-4c94-8133-606742540d68@github.com>
References: <WzhJYnQ0CmI-ydT7mgz8utJyhWzDPAM-6duNn7Qks5I=.c59b17d5-1d88-4c94-8133-606742540d68@github.com>
Message-ID: <BwPk1_iYgDzwWGNf6qUjXgZcm85XEveATIvTyU9DCa4=.077f205f-bf25-4491-bf82-8323847dbff4@github.com>

> When using HTTP/1.1, if a BodyPublisher reports an unknown length (-1), the HttpClient will send the request body in Chunked mode. If the publisher publishes an empty byte buffer, the client will generate an empty chunk, which the server will interpret as the end of the request body. Sending an empty chunk can never be valid, unless it's the last body chunk and marks the end of the body.
> 
> A new subclass of `AbstractNoBody.java` `NoBodyPartThree.java` is created to check this scenario. While at it, the tests `java/net/httpclient/NoBodyPartOne.java` and `java/net/httpclient/NoBodyPartTwo.java` which create a lot of clients are also updated to make use of `HttpClient::close`.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Add bug id

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13988/files
  - new: https://git.openjdk.org/jdk/pull/13988/files/1b5b0507..2b6e7f07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13988&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13988&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13988.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13988/head:pull/13988

PR: https://git.openjdk.org/jdk/pull/13988

From naoto at openjdk.org  Mon May 15 17:09:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 15 May 2023 17:09:59 GMT
Subject: RFR: 8308022: update for deprecated sprintf for java.base
In-Reply-To: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
Message-ID: <Y8JiTAzeyM2YEjbGf5pMkBRc3Uom1xUBtJtUi_8dMw8=.8b8a8d67-0792-4aa9-a06a-71636102736c@github.com>

On Fri, 12 May 2023 17:57:43 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
> 
> Thanks,
> Xuelei

Looked at TimeZone_md.c and Console_md.c, and the changes look reasonable.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13963#pullrequestreview-1427001957

From djelinski at openjdk.org  Mon May 15 17:12:46 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 15 May 2023 17:12:46 GMT
Subject: RFR: 8308024: HttpClient (HTTP/1.1) sends an extraneous empty
 chunk if the BodyPublisher supplies an empty buffer [v2]
In-Reply-To: <BwPk1_iYgDzwWGNf6qUjXgZcm85XEveATIvTyU9DCa4=.077f205f-bf25-4491-bf82-8323847dbff4@github.com>
References: <WzhJYnQ0CmI-ydT7mgz8utJyhWzDPAM-6duNn7Qks5I=.c59b17d5-1d88-4c94-8133-606742540d68@github.com>
 <BwPk1_iYgDzwWGNf6qUjXgZcm85XEveATIvTyU9DCa4=.077f205f-bf25-4491-bf82-8323847dbff4@github.com>
Message-ID: <v7Q7lepoM6y7jiIOfuZH98v6tun18GXw9bfZ0IGfKls=.44771229-c0eb-42d2-9a97-97f059f03554@github.com>

On Mon, 15 May 2023 16:31:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> When using HTTP/1.1, if a BodyPublisher reports an unknown length (-1), the HttpClient will send the request body in Chunked mode. If the publisher publishes an empty byte buffer, the client will generate an empty chunk, which the server will interpret as the end of the request body. Sending an empty chunk can never be valid, unless it's the last body chunk and marks the end of the body.
>> 
>> A new subclass of `AbstractNoBody.java` `NoBodyPartThree.java` is created to check this scenario. While at it, the tests `java/net/httpclient/NoBodyPartOne.java` and `java/net/httpclient/NoBodyPartTwo.java` which create a lot of clients are also updated to make use of `HttpClient::close`.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug id

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13988#pullrequestreview-1427005781

From dfuchs at openjdk.org  Mon May 15 17:23:46 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 15 May 2023 17:23:46 GMT
Subject: RFR: 8308022: update for deprecated sprintf for java.base
In-Reply-To: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
Message-ID: <5gmranDThlQlFLXa2i6t9E-z5tQrClncgNOErGSrfT8=.679ad5b9-ac56-418d-896f-1052fc6c4020@github.com>

On Fri, 12 May 2023 17:57:43 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
> 
> Thanks,
> Xuelei

The libnet changes look reasonable to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13963#pullrequestreview-1427023621

From michaelm at openjdk.org  Mon May 15 18:04:45 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 15 May 2023 18:04:45 GMT
Subject: RFR: 8308024: HttpClient (HTTP/1.1) sends an extraneous empty
 chunk if the BodyPublisher supplies an empty buffer [v2]
In-Reply-To: <BwPk1_iYgDzwWGNf6qUjXgZcm85XEveATIvTyU9DCa4=.077f205f-bf25-4491-bf82-8323847dbff4@github.com>
References: <WzhJYnQ0CmI-ydT7mgz8utJyhWzDPAM-6duNn7Qks5I=.c59b17d5-1d88-4c94-8133-606742540d68@github.com>
 <BwPk1_iYgDzwWGNf6qUjXgZcm85XEveATIvTyU9DCa4=.077f205f-bf25-4491-bf82-8323847dbff4@github.com>
Message-ID: <KcrEd2wl-HNWHlm1XbUelLnd-fteuJC4j_YoqvPoBjU=.900d1e52-32ef-4986-a9c9-e0568ea401a8@github.com>

On Mon, 15 May 2023 16:31:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> When using HTTP/1.1, if a BodyPublisher reports an unknown length (-1), the HttpClient will send the request body in Chunked mode. If the publisher publishes an empty byte buffer, the client will generate an empty chunk, which the server will interpret as the end of the request body. Sending an empty chunk can never be valid, unless it's the last body chunk and marks the end of the body.
>> 
>> A new subclass of `AbstractNoBody.java` `NoBodyPartThree.java` is created to check this scenario. While at it, the tests `java/net/httpclient/NoBodyPartOne.java` and `java/net/httpclient/NoBodyPartTwo.java` which create a lot of clients are also updated to make use of `HttpClient::close`.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug id

Looks fine

-------------

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13988#pullrequestreview-1427086308

From serb at openjdk.org  Mon May 15 19:57:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 15 May 2023 19:57:49 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v8]
In-Reply-To: <RmpQ0UW0ax5JETdJuXpHCg-eqQX0oTZRRzbOZmrE3bE=.b416d435-569d-4bbd-a244-dbef98ebe013@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <RmpQ0UW0ax5JETdJuXpHCg-eqQX0oTZRRzbOZmrE3bE=.b416d435-569d-4bbd-a244-dbef98ebe013@github.com>
Message-ID: <c2gsv3xa4JtEXXluGeJyT1fnn0cwhVQIyvqBUqbFMXc=.3311760e-cae1-4414-a4f7-0e8dfa85c76d@github.com>

On Wed, 10 May 2023 21:58:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I would like to get preliminary feedback about the provided patch.
>> 
>> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
>> 
>> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
>> 
>> At the moment this cache can be configured by the application using the following two properties:
>>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
>> 
>> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
>> 
>> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
>> 
>> Possible solutions:
>>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
>> 
>> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
>> 
>> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
>> 
>> 
>> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
>> https://www.rfc-editor.org/rfc/rfc8767
>> 
>> Comments about current and other possible implementations:
>>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>>  * The refr...
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>

If there are no any other comments/objections I'll start to work in the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1548485422

From dfuchs at openjdk.org  Tue May 16 09:17:01 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 16 May 2023 09:17:01 GMT
Subject: Integrated: 8308024: HttpClient (HTTP/1.1) sends an extraneous empty
 chunk if the BodyPublisher supplies an empty buffer
In-Reply-To: <WzhJYnQ0CmI-ydT7mgz8utJyhWzDPAM-6duNn7Qks5I=.c59b17d5-1d88-4c94-8133-606742540d68@github.com>
References: <WzhJYnQ0CmI-ydT7mgz8utJyhWzDPAM-6duNn7Qks5I=.c59b17d5-1d88-4c94-8133-606742540d68@github.com>
Message-ID: <44K4G3GthmHPWXC_5gFoh9hbZsMZwa5IgY2MUVh1Mwo=.e0eecfa0-269a-4332-a331-fb84342cf0a3@github.com>

On Mon, 15 May 2023 14:21:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> When using HTTP/1.1, if a BodyPublisher reports an unknown length (-1), the HttpClient will send the request body in Chunked mode. If the publisher publishes an empty byte buffer, the client will generate an empty chunk, which the server will interpret as the end of the request body. Sending an empty chunk can never be valid, unless it's the last body chunk and marks the end of the body.
> 
> A new subclass of `AbstractNoBody.java` `NoBodyPartThree.java` is created to check this scenario. While at it, the tests `java/net/httpclient/NoBodyPartOne.java` and `java/net/httpclient/NoBodyPartTwo.java` which create a lot of clients are also updated to make use of `HttpClient::close`.

This pull request has now been integrated.

Changeset: 72294c54
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72294c5402dd11e3eb4922ad26e1b153098495ff
Stats:     454 lines in 5 files changed: 283 ins; 37 del; 134 mod

8308024: HttpClient (HTTP/1.1) sends an extraneous empty chunk if the BodyPublisher supplies an empty buffer

Reviewed-by: djelinski, michaelm

-------------

PR: https://git.openjdk.org/jdk/pull/13988

From duke at openjdk.org  Tue May 16 10:46:44 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 16 May 2023 10:46:44 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
Message-ID: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>

Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,

I didn't add any new tests but ran tier 1-3 with no issues

-------------

Commit messages:
 - added some case conversions missed previously
 - updated copyright year and cleaned up some formatting of imports
 - merged master into branch
 - Specify use of Locale.Root to avoid issues with case conversion

Changes: https://git.openjdk.org/jdk/pull/14006/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14006&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7065228
  Stats: 76 lines in 21 files changed: 15 ins; 0 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/14006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14006/head:pull/14006

PR: https://git.openjdk.org/jdk/pull/14006

From dfuchs at openjdk.org  Tue May 16 13:35:49 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 16 May 2023 13:35:49 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <DHtnnoADW3f5RUt0In8xkkrn09PAMAP-uQF-KUFS-9A=.c5b232c6-bf43-4f16-a0f9-4f9bed8eef69@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

Looks generally like a good improvement. In those places `toLowerCase` is called on strings (or substrings) that are expected to be ASCII, so using Locale.ROOT looks appropriate.
Would be good to get @Michael-Mc-Mahon validate these changes too.

src/java.base/share/classes/java/io/StreamTokenizer.java line 632:

> 630:             sval = String.copyValueOf(buf, 0, i);
> 631:             if (forceLower)
> 632:                 sval = sval.toLowerCase(Locale.ROOT);

This one gave me pause. AFAICS it's probably OK - but it might warant a CSR and an update of the specification to explicitly state how the lower case conversion is performed (update the `lowerCaseMode` method spec). Could we handle that in a separate PR?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1428569684
PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1195156280

From jpai at openjdk.org  Tue May 16 13:44:09 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 May 2023 13:44:09 GMT
Subject: RFR: 8308185: Update Http2TestServerConnection to use
 SSLSocket.startHandshake()
Message-ID: <FN5pu37Z_HfybraTBr5zQaNSf14m8RffiTI8XY2CT_s=.12aa41f6-e026-4b16-96d5-5d7e2f891fde@github.com>

Can I please get a review of this change in the `jdk.httpclient.test.lib.http2.Http2TestServerConnection` which proposes to use the `SSLSocket.startHandshake()`  to API propogate any handshake exception back to the test that uses this test server?

This addresses https://bugs.openjdk.org/browse/JDK-8308185 and as noted in that JBS issue should help diagnoze any handshake failures in httpclient tests, a bit more easily.

tier2 testing with this change came back without any failures.

-------------

Commit messages:
 - 8308185: Update Http2TestServerConnection to use SSLSocket.startHandshake()

Changes: https://git.openjdk.org/jdk/pull/14012/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14012&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308185
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14012.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14012/head:pull/14012

PR: https://git.openjdk.org/jdk/pull/14012

From djelinski at openjdk.org  Tue May 16 15:20:47 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 16 May 2023 15:20:47 GMT
Subject: RFR: 8308185: Update Http2TestServerConnection to use
 SSLSocket.startHandshake()
In-Reply-To: <FN5pu37Z_HfybraTBr5zQaNSf14m8RffiTI8XY2CT_s=.12aa41f6-e026-4b16-96d5-5d7e2f891fde@github.com>
References: <FN5pu37Z_HfybraTBr5zQaNSf14m8RffiTI8XY2CT_s=.12aa41f6-e026-4b16-96d5-5d7e2f891fde@github.com>
Message-ID: <fNpSdLru0cvXmPyn0pbw9x4DOyKLRdZ2DFKFtlfBkes=.64479c33-2af4-4582-a32a-35511dc19f35@github.com>

On Tue, 16 May 2023 13:36:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change in the `jdk.httpclient.test.lib.http2.Http2TestServerConnection` which proposes to use the `SSLSocket.startHandshake()`  to API propogate any handshake exception back to the test that uses this test server?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8308185 and as noted in that JBS issue should help diagnoze any handshake failures in httpclient tests, a bit more easily.
> 
> tier2 testing with this change came back without any failures.

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14012#pullrequestreview-1428839682

From naoto at openjdk.org  Tue May 16 15:59:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 May 2023 15:59:44 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <E8ot4-f4CJyVS8gx-EF6NL6p9Q_QASWAYOk4aZfERcg=.0b7e9507-d3ca-4e72-9d0c-fb92f8273d6d@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

LGTM. Nice clean-up!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1428917297

From serb at openjdk.org  Tue May 16 16:14:47 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 16 May 2023 16:14:47 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v8]
In-Reply-To: <RmpQ0UW0ax5JETdJuXpHCg-eqQX0oTZRRzbOZmrE3bE=.b416d435-569d-4bbd-a244-dbef98ebe013@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <RmpQ0UW0ax5JETdJuXpHCg-eqQX0oTZRRzbOZmrE3bE=.b416d435-569d-4bbd-a244-dbef98ebe013@github.com>
Message-ID: <ry_NUuj28Q0QuT2izvz9lWRo1pD96xeJhd-df8tpow0=.fbdc833f-f79c-417d-bbb9-b8e3133bfe92@github.com>

On Wed, 10 May 2023 21:58:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I would like to get preliminary feedback about the provided patch.
>> 
>> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
>> 
>> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
>> 
>> At the moment this cache can be configured by the application using the following two properties:
>>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
>> 
>> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
>> 
>> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
>> 
>> Possible solutions:
>>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
>> 
>> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
>> 
>> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
>> 
>> 
>> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
>> https://www.rfc-editor.org/rfc/rfc8767
>> 
>> Comments about current and other possible implementations:
>>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>>  * The refr...
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>

The CSR is updated, please take a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1549970700

From duke at openjdk.org  Tue May 16 17:22:46 2023
From: duke at openjdk.org (Dhamoder Nalla)
Date: Tue, 16 May 2023 17:22:46 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance
In-Reply-To: <E2nNyZZOWBxiYzfrvC77SOfUm9JPjZaKQrWARVIk5Us=.fe852045-fc5e-41b5-b933-a6193c1f77af@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
 <z7BTybOZSsBQQrFx_MgGnaWc1HTrC-sX9PHvnZGIfv8=.ae1b12c5-3432-4ebc-baa2-c6b688fdaa58@github.com>
 <gefFeVXa_HrxO6TyD-7G9F-vVgkOY2QoiZmcVIqnhUs=.482a8cfa-686d-441c-b102-e7ba26149d86@github.com>
 <E2nNyZZOWBxiYzfrvC77SOfUm9JPjZaKQrWARVIk5Us=.fe852045-fc5e-41b5-b933-a6193c1f77af@github.com>
Message-ID: <jLC09EUWbncgePxBObU98dB8D4pbArpC6B7BG1-vJcs=.0d5c360d-e872-4010-b03e-9da41a4f2563@github.com>

On Tue, 25 Apr 2023 18:20:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Thanks for reviewing @dfuch,
>> With this change, the below operation returns hostname "foo_bar"
>> 
>> jshell> new URI("http://foo_bar:8080/").getHost()
>> 
>> I will work on addressing this to keep the old behavior unchanged.
>
>> I will work on addressing this to keep the old behavior unchanged.
> 
> Please make sure to run the java/net/URI tests - and when these are successful, tier1, tier2 and tier3.

Thanks @dfuch,  
I have validated the following tests with the new change.
1.  JShell:
       jshell> new URI("http://foo_bar:8080/").getHost()
       $1 ==> null

      jshell> new URI("http://foo_bar:8080/").getPort()
      $2 ==> -1
      
      jshell> new URI("http://foobar:8080/").getHost()
      $3 ==> "foobar"
      
      jshell> new URI("http://foobar:8080/").getPort()
      $4 ==> 8080
2.  all tests under "java/net/URI" passed as expected.
3. no failures related my change in tier1, tier2 and tier3 tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13430#issuecomment-1550071618

From jpai at openjdk.org  Wed May 17 10:09:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 May 2023 10:09:52 GMT
Subject: RFR: 8308185: Update Http2TestServerConnection to use
 SSLSocket.startHandshake()
In-Reply-To: <FN5pu37Z_HfybraTBr5zQaNSf14m8RffiTI8XY2CT_s=.12aa41f6-e026-4b16-96d5-5d7e2f891fde@github.com>
References: <FN5pu37Z_HfybraTBr5zQaNSf14m8RffiTI8XY2CT_s=.12aa41f6-e026-4b16-96d5-5d7e2f891fde@github.com>
Message-ID: <FEEDNf-2xjVC2yVVJppDjgTQFecUy3YpEnyqeA8VcoI=.82df3f7b-5ce6-4d40-8c86-963ffb2bac7a@github.com>

On Tue, 16 May 2023 13:36:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change in the `jdk.httpclient.test.lib.http2.Http2TestServerConnection` which proposes to use the `SSLSocket.startHandshake()`  to API propogate any handshake exception back to the test that uses this test server?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8308185 and as noted in that JBS issue should help diagnoze any handshake failures in httpclient tests, a bit more easily.
> 
> tier2 testing with this change came back without any failures.

Thank you Daniel for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14012#issuecomment-1551110107

From jpai at openjdk.org  Wed May 17 10:09:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 May 2023 10:09:53 GMT
Subject: Integrated: 8308185: Update Http2TestServerConnection to use
 SSLSocket.startHandshake()
In-Reply-To: <FN5pu37Z_HfybraTBr5zQaNSf14m8RffiTI8XY2CT_s=.12aa41f6-e026-4b16-96d5-5d7e2f891fde@github.com>
References: <FN5pu37Z_HfybraTBr5zQaNSf14m8RffiTI8XY2CT_s=.12aa41f6-e026-4b16-96d5-5d7e2f891fde@github.com>
Message-ID: <PdLfwsPCoYbCTNDBTe65qEWdxPnPb1W7rtbkO5lJ7fg=.a86fb042-c66f-43a6-88c6-13b350f0c9c0@github.com>

On Tue, 16 May 2023 13:36:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change in the `jdk.httpclient.test.lib.http2.Http2TestServerConnection` which proposes to use the `SSLSocket.startHandshake()`  to API propogate any handshake exception back to the test that uses this test server?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8308185 and as noted in that JBS issue should help diagnoze any handshake failures in httpclient tests, a bit more easily.
> 
> tier2 testing with this change came back without any failures.

This pull request has now been integrated.

Changeset: 1a6f9810
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a6f9810cd5bcd3cdbdd1505900c0e8c7f091b22
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8308185: Update Http2TestServerConnection to use SSLSocket.startHandshake()

Reviewed-by: djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/14012

From djelinski at openjdk.org  Wed May 17 10:44:47 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 17 May 2023 10:44:47 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <khArxt__ygRlbr63kl1DtT4hHdV8MV7t649XSfhCvhI=.1c153e15-b509-4b30-833d-cdb196ea0ff7@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 516:

> 514: 
> 515:         if (nccount != -1) {
> 516:             ncstring = Integer.toHexString (nccount).toLowerCase(Locale.ROOT);

Suggestion:

            ncstring = Integer.toHexString(nccount);

`toHexString` returns lowercase string

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1196296029

From duke at openjdk.org  Wed May 17 13:53:55 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 17 May 2023 13:53:55 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
 - removed StreamTokenizer changes, will make seperate ticket for those

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14006/files
  - new: https://git.openjdk.org/jdk/pull/14006/files/a79969c2..6d40e1c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14006&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14006&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14006/head:pull/14006

PR: https://git.openjdk.org/jdk/pull/14006

From duke at openjdk.org  Wed May 17 13:53:57 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 17 May 2023 13:53:57 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <khArxt__ygRlbr63kl1DtT4hHdV8MV7t649XSfhCvhI=.1c153e15-b509-4b30-833d-cdb196ea0ff7@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <khArxt__ygRlbr63kl1DtT4hHdV8MV7t649XSfhCvhI=.1c153e15-b509-4b30-833d-cdb196ea0ff7@github.com>
Message-ID: <Og1RmemzWJrIVkwiivXnQs7MCuO7eFHzNkH2PPDLNLc=.56c9a06d-1ef9-4d53-a38f-408bdcd9ce4d@github.com>

On Wed, 17 May 2023 10:41:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>>    
>>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>>  - removed StreamTokenizer changes, will make seperate ticket for those
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 516:
> 
>> 514: 
>> 515:         if (nccount != -1) {
>> 516:             ncstring = Integer.toHexString (nccount).toLowerCase(Locale.ROOT);
> 
> Suggestion:
> 
>             ncstring = Integer.toHexString(nccount);
> 
> `toHexString` returns lowercase string

Thanks for pointing that out!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1196555183

From dfuchs at openjdk.org  Wed May 17 15:03:07 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 17 May 2023 15:03:07 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v8]
In-Reply-To: <RmpQ0UW0ax5JETdJuXpHCg-eqQX0oTZRRzbOZmrE3bE=.b416d435-569d-4bbd-a244-dbef98ebe013@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <RmpQ0UW0ax5JETdJuXpHCg-eqQX0oTZRRzbOZmrE3bE=.b416d435-569d-4bbd-a244-dbef98ebe013@github.com>
Message-ID: <ZGcdbJHelqSCx12keFeUKzY_urX2Bwh-mDcT5j1LGrM=.07b98c92-0180-4fa5-baca-c29f83bd2bcf@github.com>

On Wed, 10 May 2023 21:58:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I would like to get preliminary feedback about the provided patch.
>> 
>> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
>> 
>> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
>> 
>> At the moment this cache can be configured by the application using the following two properties:
>>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
>> 
>> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
>> 
>> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
>> 
>> Possible solutions:
>>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
>> 
>> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
>> 
>> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
>> 
>> 
>> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
>> https://www.rfc-editor.org/rfc/rfc8767
>> 
>> Comments about current and other possible implementations:
>>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>>  * The refr...
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>

src/java.base/share/classes/java/net/InetAddress.java line 215:

> 213:  * it were unsuccessful. This property is useful if it is preferable to use a
> 214:  * stale name rather than result of unsuccessful name lookup. The default
> 215:  * setting is to cache for an implementation specific period of time.

AFAICS the default setting is to attempt to refresh stale data immediately and not cache them.

src/java.base/share/classes/java/net/InetAddress.java line 966:

> 964:      * addresses or invalid (ie a failed lookup) containing no addresses.
> 965:      */
> 966:     private static class CachedLookup implements Addresses, Comparable<CachedLookup> {

I do not really like the fact that CachedAddress -> CachedLookup has transformed an immutable class into a mutable one, which in addition forces a volatile read to get the addresses.

Have you explored moving the new functionality implemented by `ValidCachedLookup` inside `NameServiceAddresses`?

Couldn't NameServiceAddresses be initialized with a (final) InetAddress[] array (from the previous stale lookup) that, if not null, would be returned when `tryLock` returns false?

In other words if NameServiceAddresses::staleAddresses is not null, and we are still in the stale window, use tryLock, and if false, return staleAddresses; otherwise, use lock.

Would that work, and keep everything final instead of volatile?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1196558484
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1196639624

From dfuchs at openjdk.org  Wed May 17 15:03:14 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 17 May 2023 15:03:14 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v7]
In-Reply-To: <0dVXh91AhVTmtCLu_oJygSKc5M9KjmYXgCgHfFDcEO8=.ec5c485e-f7cc-41af-82e2-537141871c40@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <IZ2tvUTjaeMVFxt-yA3AlJCx55ZSrPJ4TGbZmLFMs9g=.d8d9fd03-b99c-4aee-82b4-cbf35ad4b09f@github.com>
 <sI_6kzWem0EhxU3CQDlH8jmyELM7KkeZ52hLfIIshFU=.487045e6-02ea-4275-b67d-69b598366f9d@github.com>
 <7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>
 <Wf_vBr0V8XL7JOZ2PG_jkSjzIr6EN0JYCyGmCf3yV4Y=.8e50ad01-de11-4887-b7fe-d3dcf3f434a9@github.com>
 <0dVXh91AhVTmtCLu_oJygSKc5M9KjmYXgCgHfFDcEO8=.ec5c485e-f7cc-41af-82e2-537141871c40@github.com>
Message-ID: <xPl2aqf5nvDuq3QCbYr-aaX-d8SsfmYNe29-pMyxWoo=.cb4b3ef0-64f0-4f80-8513-4968d87abf9d@github.com>

On Wed, 10 May 2023 22:08:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I have update the text about "property is not set" case, but leave the text about "default value" as implementation-specific, similarly to what we have in the text about "networkaddress.cache.ttl" property, and this allow to change this value in some situations.
>
> Right now the negative value is ignored, and is not mentioned in the new spec, But it could be used to cover "always use the stale data on error" case. So we can change this in the future, but probably it will not be a big deal to update the spec if that will happen.

I believe we do need to specify what happens if the value is negative. We cannot leave that as "undefined behaviour that may change in the future".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1196583182

From serb at openjdk.org  Wed May 17 18:49:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 17 May 2023 18:49:54 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v8]
In-Reply-To: <ZGcdbJHelqSCx12keFeUKzY_urX2Bwh-mDcT5j1LGrM=.07b98c92-0180-4fa5-baca-c29f83bd2bcf@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <RmpQ0UW0ax5JETdJuXpHCg-eqQX0oTZRRzbOZmrE3bE=.b416d435-569d-4bbd-a244-dbef98ebe013@github.com>
 <ZGcdbJHelqSCx12keFeUKzY_urX2Bwh-mDcT5j1LGrM=.07b98c92-0180-4fa5-baca-c29f83bd2bcf@github.com>
Message-ID: <IsIw15ok7VYVfjX9JpehnoQ6PHiDZrXOFm5GHlo0hfQ=.5deb6f11-688b-4870-97c0-8bf569cdf80b@github.com>

On Wed, 17 May 2023 13:51:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>
>
> src/java.base/share/classes/java/net/InetAddress.java line 215:
> 
>> 213:  * it were unsuccessful. This property is useful if it is preferable to use a
>> 214:  * stale name rather than result of unsuccessful name lookup. The default
>> 215:  * setting is to cache for an implementation specific period of time.
> 
> AFAICS the default setting is to attempt to refresh stale data immediately and not cache them.

It is only true if the security property is not set for some specific binaries, and it can have some different value than zero by default.

> src/java.base/share/classes/java/net/InetAddress.java line 966:
> 
>> 964:      * addresses or invalid (ie a failed lookup) containing no addresses.
>> 965:      */
>> 966:     private static class CachedLookup implements Addresses, Comparable<CachedLookup> {
> 
> I do not really like the fact that CachedAddress -> CachedLookup has transformed an immutable class into a mutable one, which in addition forces a volatile read to get the addresses.
> 
> Have you explored moving the new functionality implemented by `ValidCachedLookup` inside `NameServiceAddresses`?
> 
> Couldn't NameServiceAddresses be initialized with a (final) InetAddress[] array (from the previous stale lookup) that, if not null, would be returned when `tryLock` returns false?
> 
> In other words if NameServiceAddresses::staleAddresses is not null, and we are still in the stale window, use tryLock, and if false, return staleAddresses; otherwise, use lock.
> 
> Would that work, and keep everything final instead of volatile?

This is what I tried to implement initially: NameServiceAddresses which stores the fallback value of staleAddresses. Unfortunately the NameServiceAddresses class is [used](https://github.com/openjdk/jdk/blob/aad899b7f964c4c4f05ad35208c58118692c9aa0/src/java.base/share/classes/java/net/InetAddress.java#L1808) when we already deleted the addresses from the caches. So the first thread may save the old stale data from the cache, delete and create a new "proper" NameServiceAddresses, but another thread may do the same and get the "empty" old stale data -> if the second request will be faster we will lost the stale data. It could be fixed by some additional synchronization, but that would be more expensive than one volatile read.

Note that we can eliminate that one volatile read by duplicating the logic of CachedLookup inside  ValidCachedLookup by using one interface for both, not sure that it is worth, since we already have a couple of loookups to the ConcurrentHashMap and ConcurrentSkipListSet on each call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1196928240
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1196926931

From serb at openjdk.org  Wed May 17 18:49:56 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 17 May 2023 18:49:56 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v7]
In-Reply-To: <xPl2aqf5nvDuq3QCbYr-aaX-d8SsfmYNe29-pMyxWoo=.cb4b3ef0-64f0-4f80-8513-4968d87abf9d@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <IZ2tvUTjaeMVFxt-yA3AlJCx55ZSrPJ4TGbZmLFMs9g=.d8d9fd03-b99c-4aee-82b4-cbf35ad4b09f@github.com>
 <sI_6kzWem0EhxU3CQDlH8jmyELM7KkeZ52hLfIIshFU=.487045e6-02ea-4275-b67d-69b598366f9d@github.com>
 <7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>
 <Wf_vBr0V8XL7JOZ2PG_jkSjzIr6EN0JYCyGmCf3yV4Y=.8e50ad01-de11-4887-b7fe-d3dcf3f434a9@github.com>
 <0dVXh91AhVTmtCLu_oJygSKc5M9KjmYXgCgHfFDcEO8=.ec5c485e-f7cc-41af-82e2-537141871c40@github.com>
 <xPl2aqf5nvDuq3QCbYr-aaX-d8SsfmYNe29-pMyxWoo=.cb4b3ef0-64f0-4f80-8513-4968d87abf9d@github.com>
Message-ID: <8HlyoqNh0_WszGqT9Y3OIvFhDOSE0zK6uflD5JewqcY=.35826ac8-e61e-496c-b545-01a4de78a987@github.com>

On Wed, 17 May 2023 14:08:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Right now the negative value is ignored, and is not mentioned in the new spec, But it could be used to cover "always use the stale data on error" case. So we can change this in the future, but probably it will not be a big deal to update the spec if that will happen.
>
> I believe we do need to specify what happens if the value is negative. We cannot leave that as "undefined behaviour that may change in the future".

will update the spec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1196928743

From dfuchs at openjdk.org  Wed May 17 18:54:20 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 17 May 2023 18:54:20 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks
Message-ID: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>

Please find here a change that revisits usage of monitors in the HttpClient.

With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.

This change aims at avoiding situations where the carrier threads might get pinned.

-------------

Commit messages:
 - 8308310

Changes: https://git.openjdk.org/jdk/pull/14038/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308310
  Stats: 886 lines in 31 files changed: 518 ins; 110 del; 258 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

PR: https://git.openjdk.org/jdk/pull/14038

From aturbanov at openjdk.org  Thu May 18 09:44:51 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 May 2023 09:44:51 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <PgUPXY3Qy_Nd3Uzwg-bkETS8iaDkPXr6knBWrZCUgzI=.84808108-8758-43c8-8589-517830aae5f5@github.com>

On Wed, 17 May 2023 18:46:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java line 61:

> 59:     // Pools of idle connections
> 60: 
> 61:     private final ReentrantLock stateLock =  new ReentrantLock();

Suggestion:

    private final ReentrantLock stateLock = new ReentrantLock();

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 130:

> 128:         }
> 129: 
> 130:         public  boolean acquire() {

Suggestion:

        public boolean acquire() {

test/jdk/java/net/httpclient/AuthFilterCacheTest.java line 298:

> 296:             synchronized (this) {
> 297:                 count = ++this.count;
> 298:                 passwordAuthentication =  super.requestPasswordAuthenticationInstance(

Suggestion:

                passwordAuthentication = super.requestPasswordAuthenticationInstance(

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1197618149
PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1197618347
PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1197617935

From djelinski at openjdk.org  Thu May 18 09:47:52 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 18 May 2023 09:47:52 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <Agw1U8jJIdnuZuC_WY3nK8Ht5oZi6J3rN17BQVLK2HI=.8056e5a9-caa7-43f1-9f6c-b55e899820fd@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1432388069

From serb at openjdk.org  Thu May 18 09:57:16 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 18 May 2023 09:57:16 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v9]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <n5sptc6DVimSAYwXN2Gm0GUGiYAZr09eiMejugr9bjA=.02920266-3d69-486d-b254-4c81bdd76a90@github.com>

> I would like to get preliminary feedback about the provided patch.
> 
> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
> 
> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
> 
> At the moment this cache can be configured by the application using the following two properties:
>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
> 
> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
> 
> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
> 
> Possible solutions:
>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
> 
> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
> 
> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
> 
> 
> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
> https://www.rfc-editor.org/rfc/rfc8767
> 
> Comments about current and other possible implementations:
>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>  * The refresh timeout includes the time s...

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge branch 'master' into JDK-8304885
 - The negative value is ignored
 - Apply suggestions from code review
   
   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>
 - delete 7 days cap
 - Merge branch 'master' into JDK-8304885
 - Merge remote-tracking branch 'upstream/master' into JDK-8304885
 - Rename the classes and add the javadoc.
 - Merge branch 'master' into JDK-8304885
 - documentation
 - PR feedback
 - ... and 7 more: https://git.openjdk.org/jdk/compare/d8ecd702...d1c28ab7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13285/files
  - new: https://git.openjdk.org/jdk/pull/13285/files/aad899b7..d1c28ab7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=07-08

  Stats: 147209 lines in 2469 files changed: 113642 ins; 14838 del; 18729 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

PR: https://git.openjdk.org/jdk/pull/13285

From serb at openjdk.org  Thu May 18 10:02:34 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 18 May 2023 10:02:34 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v10]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <rS_6gYmzVWjfleYC7ltzsnmzAgDldg_4VDDuLjhVMOY=.cf912e6d-adac-45b5-82b0-7961edce8ad7@github.com>

> I would like to get preliminary feedback about the provided patch.
> 
> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
> 
> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
> 
> At the moment this cache can be configured by the application using the following two properties:
>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
> 
> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
> 
> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
> 
> Possible solutions:
>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
> 
> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
> 
> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
> 
> 
> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
> https://www.rfc-editor.org/rfc/rfc8767
> 
> Comments about current and other possible implementations:
>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>  * The refresh timeout includes the time s...

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  The negative value is ignored

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13285/files
  - new: https://git.openjdk.org/jdk/pull/13285/files/d1c28ab7..a856cd36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=08-09

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

PR: https://git.openjdk.org/jdk/pull/13285

From dfuchs at openjdk.org  Thu May 18 10:04:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 10:04:10 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v2]
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <hVYRIhM9nKMzLixiCreIyOwy2j_7Q0aMOdY2sgzIRDo=.6bb819b1-3926-420d-9580-22ba0333d258@github.com>

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14038/files
  - new: https://git.openjdk.org/jdk/pull/14038/files/889122f0..e090e36e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

PR: https://git.openjdk.org/jdk/pull/14038

From dfuchs at openjdk.org  Thu May 18 10:04:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 10:04:51 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <0GxhPfV9kjdGq_66qtf-4bnWOhVwd5wZKr4HVDbBvkE=.fd5017df-882c-48a8-b373-34d6204664a1@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1432410653

From aturbanov at openjdk.org  Thu May 18 10:20:56 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 May 2023 10:20:56 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v2]
In-Reply-To: <hVYRIhM9nKMzLixiCreIyOwy2j_7Q0aMOdY2sgzIRDo=.6bb819b1-3926-420d-9580-22ba0333d258@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <hVYRIhM9nKMzLixiCreIyOwy2j_7Q0aMOdY2sgzIRDo=.6bb819b1-3926-420d-9580-22ba0333d258@github.com>
Message-ID: <yR4XTGhdkIYJw9_YHCCu07FTQG7CSp-8VE9751erTOg=.3d039342-4b6e-4a32-a0ae-a9e37989c2ba@github.com>

On Thu, 18 May 2023 10:04:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java line 167:

> 165: 
> 166:     private HttpConnection getConnection0(boolean secure,
> 167:                                   InetSocketAddress addr,

let's align parameters

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1197649916

From aturbanov at openjdk.org  Thu May 18 12:35:51 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 May 2023 12:35:51 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v2]
In-Reply-To: <hVYRIhM9nKMzLixiCreIyOwy2j_7Q0aMOdY2sgzIRDo=.6bb819b1-3926-420d-9580-22ba0333d258@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <hVYRIhM9nKMzLixiCreIyOwy2j_7Q0aMOdY2sgzIRDo=.6bb819b1-3926-420d-9580-22ba0333d258@github.com>
Message-ID: <DuINfvQMIKNlv8sN_gjKNTUcioKcVNkL9ITr4AHRPVA=.d5beba9b-94fa-4cf2-99e9-c9c963854410@github.com>

On Thu, 18 May 2023 10:04:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java line 72:

> 70:     /** Records a possible cancellation raised before any operation
> 71:      * has been initiated, or an error received while sending the request. */
> 72:     private AtomicReference<Throwable> failedRef = new AtomicReference<>();

Seems it's only modified under lock. Can we use `volatile` instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1197759798

From dfuchs at openjdk.org  Thu May 18 13:55:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 13:55:50 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v2]
In-Reply-To: <DuINfvQMIKNlv8sN_gjKNTUcioKcVNkL9ITr4AHRPVA=.d5beba9b-94fa-4cf2-99e9-c9c963854410@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <hVYRIhM9nKMzLixiCreIyOwy2j_7Q0aMOdY2sgzIRDo=.6bb819b1-3926-420d-9580-22ba0333d258@github.com>
 <DuINfvQMIKNlv8sN_gjKNTUcioKcVNkL9ITr4AHRPVA=.d5beba9b-94fa-4cf2-99e9-c9c963854410@github.com>
Message-ID: <wJv-ffyVsS5SRHrCDbHMiQJbg4yO93L43IeGlBpKNuM=.e0a64483-6b93-43ee-981f-333f628c7680@github.com>

On Thu, 18 May 2023 12:32:40 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java line 72:
> 
>> 70:     /** Records a possible cancellation raised before any operation
>> 71:      * has been initiated, or an error received while sending the request. */
>> 72:     private AtomicReference<Throwable> failedRef = new AtomicReference<>();
> 
> Seems it's only modified under lock. Can we use `volatile` instead?

I prefer to keep AtomicReference - it's easier to reason about.
Maybe at some time I'll do a pass to use VarHandles in various places but now is not the time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1197858774

From dfuchs at openjdk.org  Thu May 18 14:03:02 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 14:03:02 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v3]
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <BwZUw_Ax8OOYOInBojIhEgpDhlsKpVkPF_U0p-w8ZGo=.6af99bdb-bd56-4745-99c5-22bb63a67792@github.com>

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Align parameters

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14038/files
  - new: https://git.openjdk.org/jdk/pull/14038/files/e090e36e..b72cd989

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

PR: https://git.openjdk.org/jdk/pull/14038

From aturbanov at openjdk.org  Thu May 18 14:03:03 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 May 2023 14:03:03 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v2]
In-Reply-To: <wJv-ffyVsS5SRHrCDbHMiQJbg4yO93L43IeGlBpKNuM=.e0a64483-6b93-43ee-981f-333f628c7680@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <hVYRIhM9nKMzLixiCreIyOwy2j_7Q0aMOdY2sgzIRDo=.6bb819b1-3926-420d-9580-22ba0333d258@github.com>
 <DuINfvQMIKNlv8sN_gjKNTUcioKcVNkL9ITr4AHRPVA=.d5beba9b-94fa-4cf2-99e9-c9c963854410@github.com>
 <wJv-ffyVsS5SRHrCDbHMiQJbg4yO93L43IeGlBpKNuM=.e0a64483-6b93-43ee-981f-333f628c7680@github.com>
Message-ID: <ctQPCMdX13sSUOv0hcmOviCHrtqG9nulIVZ7v9vLIc8=.8bb34999-3776-45e2-83cd-b15050915e7b@github.com>

On Thu, 18 May 2023 13:53:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java line 72:
>> 
>>> 70:     /** Records a possible cancellation raised before any operation
>>> 71:      * has been initiated, or an error received while sending the request. */
>>> 72:     private AtomicReference<Throwable> failedRef = new AtomicReference<>();
>> 
>> Seems it's only modified under lock. Can we use `volatile` instead?
>
> I prefer to keep AtomicReference - it's easier to reason about.
> Maybe at some time I'll do a pass to use VarHandles in various places but now is not the time.

let's make it `final` at least

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1197864833

From dfuchs at openjdk.org  Thu May 18 14:49:14 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 14:49:14 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v4]
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <WJR5Sd7xoDHZdeBcBRgx3I_mnQnLLswsURm-nNDYuRw=.21f33be2-dae4-467c-8436-216957a2687b@github.com>

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  failedRef should be final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14038/files
  - new: https://git.openjdk.org/jdk/pull/14038/files/b72cd989..a62cfd7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

PR: https://git.openjdk.org/jdk/pull/14038

From dfuchs at openjdk.org  Thu May 18 14:49:15 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 14:49:15 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v2]
In-Reply-To: <ctQPCMdX13sSUOv0hcmOviCHrtqG9nulIVZ7v9vLIc8=.8bb34999-3776-45e2-83cd-b15050915e7b@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <hVYRIhM9nKMzLixiCreIyOwy2j_7Q0aMOdY2sgzIRDo=.6bb819b1-3926-420d-9580-22ba0333d258@github.com>
 <DuINfvQMIKNlv8sN_gjKNTUcioKcVNkL9ITr4AHRPVA=.d5beba9b-94fa-4cf2-99e9-c9c963854410@github.com>
 <wJv-ffyVsS5SRHrCDbHMiQJbg4yO93L43IeGlBpKNuM=.e0a64483-6b93-43ee-981f-333f628c7680@github.com>
 <ctQPCMdX13sSUOv0hcmOviCHrtqG9nulIVZ7v9vLIc8=.8bb34999-3776-45e2-83cd-b15050915e7b@github.com>
Message-ID: <GSdcvUug1ODrRcnrP-5xGxI9pGymscvK3HzN6flZjvE=.3798de7d-f3cf-4c9e-8744-bef3c1f641d5@github.com>

On Thu, 18 May 2023 13:58:08 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> I prefer to keep AtomicReference - it's easier to reason about.
>> Maybe at some time I'll do a pass to use VarHandles in various places but now is not the time.
>
> let's make it `final` at least

Oops! Thanks for noticing that. That's a bug. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1197916100

From dfuchs at openjdk.org  Thu May 18 15:07:04 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 15:07:04 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v5]
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <bHKWvCnO5ZTIuU-CeX5k2OAWnH05vB0fcaCdCQNLzVU=.d529451b-71bd-4d17-8508-572eecd0790e@github.com>

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Add debug traces to ExpectContinueTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14038/files
  - new: https://git.openjdk.org/jdk/pull/14038/files/a62cfd7e..7bd88c37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

PR: https://git.openjdk.org/jdk/pull/14038

From aturbanov at openjdk.org  Thu May 18 16:15:59 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 May 2023 16:15:59 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v5]
In-Reply-To: <bHKWvCnO5ZTIuU-CeX5k2OAWnH05vB0fcaCdCQNLzVU=.d529451b-71bd-4d17-8508-572eecd0790e@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <bHKWvCnO5ZTIuU-CeX5k2OAWnH05vB0fcaCdCQNLzVU=.d529451b-71bd-4d17-8508-572eecd0790e@github.com>
Message-ID: <u0etzMp4L0PQlaRocaduQG15A_sTwYQUvEKb94pZJuc=.86cdaf98-ab53-452f-9d75-4c5f5db30202@github.com>

On Thu, 18 May 2023 15:07:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add debug traces to ExpectContinueTest.java

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 125:

> 123:         // state & 0x02 != 0 => tryRelease called
> 124:         volatile byte state;
> 125:         ClientRefCountTracker(HttpClientImpl client, Logger logger) {

let's add an empty line before constructor to make distinguishing more easy

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 154:

> 152:     // send lock: prevent sending DataFrames after reset occurred.
> 153:     private final Lock sendLock = new ReentrantLock();
> 154:     final Lock stateLock = new ReentrantLock();

can it be `private` too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1198013994
PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1198011072

From dfuchs at openjdk.org  Thu May 18 16:47:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 16:47:10 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v6]
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <EJ5WBiXZwwsc3oiZ4C5ZsoB7vDxgTwqFnXaaMvY5zdI=.54e31d28-ca49-4109-824f-798272f3ab4a@github.com>

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  make stateLock final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14038/files
  - new: https://git.openjdk.org/jdk/pull/14038/files/7bd88c37..e3d60965

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=04-05

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

PR: https://git.openjdk.org/jdk/pull/14038

From dfuchs at openjdk.org  Thu May 18 16:47:13 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 16:47:13 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v5]
In-Reply-To: <u0etzMp4L0PQlaRocaduQG15A_sTwYQUvEKb94pZJuc=.86cdaf98-ab53-452f-9d75-4c5f5db30202@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <bHKWvCnO5ZTIuU-CeX5k2OAWnH05vB0fcaCdCQNLzVU=.d529451b-71bd-4d17-8508-572eecd0790e@github.com>
 <u0etzMp4L0PQlaRocaduQG15A_sTwYQUvEKb94pZJuc=.86cdaf98-ab53-452f-9d75-4c5f5db30202@github.com>
Message-ID: <h5ciX6t9v1YZ3DACNWrnjEYqzaLDsIULr73fYzi4Hog=.74afa813-b8e6-4836-9609-c06cafeebc1e@github.com>

On Thu, 18 May 2023 16:10:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add debug traces to ExpectContinueTest.java
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 154:
> 
>> 152:     // send lock: prevent sending DataFrames after reset occurred.
>> 153:     private final Lock sendLock = new ReentrantLock();
>> 154:     final Lock stateLock = new ReentrantLock();
> 
> can it be `private` too?

Good point

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1198042636

From duke at openjdk.org  Thu May 18 19:57:05 2023
From: duke at openjdk.org (Jesse Glick)
Date: Thu, 18 May 2023 19:57:05 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file handles
 for jar:file and file: URLs
Message-ID: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>

[JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).

[JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.

I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via


./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java


I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.

I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.

(This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)

-------------

Commit messages:
 - Simplified `instanceof` form
 - 6956385: `JarURLConnection` may fail to close its underlying `FileURLConnection`

Changes: https://git.openjdk.org/jdk/pull/12871/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12871&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6956385
  Stats: 85 lines in 3 files changed: 83 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12871/head:pull/12871

PR: https://git.openjdk.org/jdk/pull/12871

From duke at openjdk.org  Thu May 18 19:57:05 2023
From: duke at openjdk.org (Jesse Glick)
Date: Thu, 18 May 2023 19:57:05 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs
In-Reply-To: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
Message-ID: <tXXNxxd25h_rjIrL4yXMDts8SBig9JqjwbB2qfffDZ0=.d14097c5-c331-477b-a998-b8914e8d39d5@github.com>

On Sat, 4 Mar 2023 21:49:20 GMT, Jesse Glick <duke at openjdk.org> wrote:

> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
> 
> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
> 
> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
> 
> 
> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
> 
> 
> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
> 
> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
> 
> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)

(still trying to get formal confirmation from my employer that I can mark the OCA as signed)

https://oca.opensource.oracle.com/?ojr=contrib-list shows CloudBees, Inc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12871#issuecomment-1523867700
PR Comment: https://git.openjdk.org/jdk/pull/12871#issuecomment-1535109704

From duke at openjdk.org  Thu May 18 19:57:07 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 18 May 2023 19:57:07 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs
In-Reply-To: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
Message-ID: <8NcguDzLQAzA6SalumUib2N708-YjqU6Q_HfF5fVYpU=.4d4b03b1-47bc-48c7-af33-4a1cc0f9c236@github.com>

On Sat, 4 Mar 2023 21:49:20 GMT, Jesse Glick <duke at openjdk.org> wrote:

> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
> 
> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
> 
> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
> 
> 
> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
> 
> 
> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
> 
> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
> 
> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)

src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java line 103:

> 101:                             fileURLConnection.getInputStream().close();
> 102:                         }
> 103:                     }

This can?use `instanceof` pattern?matching:
Suggestion:

                    if (jarFileURLConnection instanceof FileURLConnection fileURLConnection
                        && fileURLConnection.isConnected()) {
                        fileURLConnection.getInputStream().close();
                    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1151455837

From duke at openjdk.org  Thu May 18 19:57:08 2023
From: duke at openjdk.org (Jesse Glick)
Date: Thu, 18 May 2023 19:57:08 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs
In-Reply-To: <8NcguDzLQAzA6SalumUib2N708-YjqU6Q_HfF5fVYpU=.4d4b03b1-47bc-48c7-af33-4a1cc0f9c236@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <8NcguDzLQAzA6SalumUib2N708-YjqU6Q_HfF5fVYpU=.4d4b03b1-47bc-48c7-af33-4a1cc0f9c236@github.com>
Message-ID: <GhWQkyUEYFjwiV4iC5tBq7I8Lp_I_JYkNRqAFGAWnAo=.cbba2a5a-2881-497b-a499-d74f096837a1@github.com>

On Wed, 29 Mar 2023 06:37:26 GMT, ExE Boss <duke at openjdk.org> wrote:

>> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
>> 
>> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
>> 
>> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
>> 
>> 
>> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
>> 
>> 
>> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
>> 
>> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
>> 
>> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)
>
> src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java line 103:
> 
>> 101:                             fileURLConnection.getInputStream().close();
>> 102:                         }
>> 103:                     }
> 
> This can?use `instanceof` pattern?matching:
> Suggestion:
> 
>                     if (jarFileURLConnection instanceof FileURLConnection fileURLConnection
>                         && fileURLConnection.isConnected()) {
>                         fileURLConnection.getInputStream().close();
>                     }

Thanks! My project is still stuck on Java 11 so I am not very familiar with the new toys.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1151785263

From jpai at openjdk.org  Fri May 19 05:18:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 May 2023 05:18:50 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <Exw7vHSSx1vZBRx6gEBLZoeMu_ttiiGWbOFZAKtHK38=.485a27a9-2d3d-4b8a-850c-fa1f928880d8@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

These changes look fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1433788568

From jpai at openjdk.org  Fri May 19 07:24:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 May 2023 07:24:53 GMT
Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled
 HTTP/2 connection for IPv6 address [v3]
In-Reply-To: <toVD9EaY8qxThRENfJZmZUVnLR6Qmy_VZ4BNyONKslI=.03a27f15-8e36-4624-a2c2-826e8b2d49e0@github.com>
References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
 <toVD9EaY8qxThRENfJZmZUVnLR6Qmy_VZ4BNyONKslI=.03a27f15-8e36-4624-a2c2-826e8b2d49e0@github.com>
Message-ID: <2jm2XhNWZZ7Bnjqra5pSa3jPAUtxo_IAxB3AGVrRh1s=.d8679325-6b49-467b-9e3e-e9e21bface45@github.com>

On Fri, 21 Apr 2023 01:26:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305906?
>> 
>> As noted in that issue, when IPv6 hosts are involved, the HttpClient on certain occasions can end up caching the connection with a key which doesn't match with the key which is then used in a subsequent request against the same target host. 
>> 
>> The commit in this PR now wraps the IPv6 address in a square bracket consistently so that the correct key is used both during storing the connection in the pool and when looking up.
>> 
>> A new jtreg test has been added which reproduces this issue without the fix and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wrapping into brackets is no longer needed

(can't believe it's already 4 weeks)
Please keep this open, I'll revive this shortly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13456#issuecomment-1554150570

From michaelm at openjdk.org  Fri May 19 11:26:52 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 19 May 2023 11:26:52 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <MIanutU-5zaHU08XWWykYRu2HSZhUfGSr70gu9SZ2ug=.77440635-04f7-4cbe-b573-a2322fed985b@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

Seems like a useful change and I can see how issues could arise if strings were stored somewhere after being upper/lower cased and then reused in a different locale. 

Is it correct to say that the assumption is these strings are all supposed to be US ASCII (eg protocol defined identifiers, or hostnames etc) rather than user generated text strings? That seems to be the case as far as I can see.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14006#issuecomment-1554431858

From dfuchs at openjdk.org  Fri May 19 11:34:55 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 May 2023 11:34:55 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs
In-Reply-To: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
Message-ID: <7_u3nhETmt1HNgygbQ_zcxrPrVixO_ea9BniH0GL_-k=.a1ecfa16-159e-4f0f-8272-775ec735dcca@github.com>

On Sat, 4 Mar 2023 21:49:20 GMT, Jesse Glick <duke at openjdk.org> wrote:

> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
> 
> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
> 
> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
> 
> 
> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
> 
> 
> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
> 
> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
> 
> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 96:

> 94:         return connected;
> 95:     }
> 96: 

I wonder if it would be better to add a


void closeInputStream() { ... } // (or void close() { ... }?)


that would simply close the input stream if it's not null...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1198859517

From michaelm at openjdk.org  Fri May 19 11:45:50 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 19 May 2023 11:45:50 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <lVPhG5xf1OqkUt02UdnjCSXVoF-H4KW_PGfrKQJ-Tto=.3980eaab-78e7-4ee4-8a62-6925757d9f9f@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

Marked as reviewed by michaelm (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1434277855

From alanb at openjdk.org  Fri May 19 11:53:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 11:53:52 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs
In-Reply-To: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
Message-ID: <Ll-SWEqW-DRV8bwe9oo3K9YBl1EJIgGu8YOIGl_uyMg=.10fd4b37-a86d-44b4-a47a-8220cf765115@github.com>

On Sat, 4 Mar 2023 21:49:20 GMT, Jesse Glick <duke at openjdk.org> wrote:

> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
> 
> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
> 
> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
> 
> 
> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
> 
> 
> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
> 
> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
> 
> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)

src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java line 28:

> 26: package sun.net.www.protocol.jar;
> 27: 
> 28: import sun.net.www.protocol.file.FileURLConnection;

How tightly connected are the two protocol handlers today?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1198873512

From duke at openjdk.org  Fri May 19 13:03:58 2023
From: duke at openjdk.org (Jesse Glick)
Date: Fri, 19 May 2023 13:03:58 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs
In-Reply-To: <7_u3nhETmt1HNgygbQ_zcxrPrVixO_ea9BniH0GL_-k=.a1ecfa16-159e-4f0f-8272-775ec735dcca@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7_u3nhETmt1HNgygbQ_zcxrPrVixO_ea9BniH0GL_-k=.a1ecfa16-159e-4f0f-8272-775ec735dcca@github.com>
Message-ID: <MH5D89e5VQToK7IOkspoRZ1xzwHIWcjj52lUJV6lqwA=.b23209f1-f22e-43d2-8611-139941c0afe7@github.com>

On Fri, 19 May 2023 11:32:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
>> 
>> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
>> 
>> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
>> 
>> 
>> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
>> 
>> 
>> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
>> 
>> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
>> 
>> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)
>
> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 96:
> 
>> 94:         return connected;
>> 95:     }
>> 96: 
> 
> I wonder if it would be better to add a
> 
> 
> void closeInputStream() { ... } // (or void close() { ... }?)
> 
> 
> that would simply close the input stream if it's not null...

`close()` would be natural enough, and would encapsulate behavior a bit better.

Should it then actually implement `Closeable`, permitting the implicit request in https://github.com/openjdk/jdk/pull/12871#discussion_r1198873512 to be addressed? That would not technically be an API change, since the implementation class is not exported, though it could be a behavioral change in case anyone is checking `instanceof Closeable` (or `instanceof AutoCloseable`); and would be a first step along the way to JDK-8224095, which may or may not be appropriate for something labeled a bug fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1198932229

From duke at openjdk.org  Fri May 19 13:04:00 2023
From: duke at openjdk.org (Jesse Glick)
Date: Fri, 19 May 2023 13:04:00 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs
In-Reply-To: <Ll-SWEqW-DRV8bwe9oo3K9YBl1EJIgGu8YOIGl_uyMg=.10fd4b37-a86d-44b4-a47a-8220cf765115@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <Ll-SWEqW-DRV8bwe9oo3K9YBl1EJIgGu8YOIGl_uyMg=.10fd4b37-a86d-44b4-a47a-8220cf765115@github.com>
Message-ID: <qQco8lEkX_MTjAIF-0DCrC88YwFQhFzCWtQDVwoBm4Q=.e88fcdf2-d0e9-4b41-bcb7-a0ec0923954f@github.com>

On Fri, 19 May 2023 11:50:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
>> 
>> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
>> 
>> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
>> 
>> 
>> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
>> 
>> 
>> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
>> 
>> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
>> 
>> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)
>
> src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java line 28:
> 
>> 26: package sun.net.www.protocol.jar;
>> 27: 
>> 28: import sun.net.www.protocol.file.FileURLConnection;
> 
> How tightly connected are the two protocol handlers today?

Previously not coupled explicitly, only by virtue of `jar:file:?` being parsed out using the default URL protocol handler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1198928526

From dfuchs at openjdk.org  Fri May 19 13:59:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 May 2023 13:59:51 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs
In-Reply-To: <MH5D89e5VQToK7IOkspoRZ1xzwHIWcjj52lUJV6lqwA=.b23209f1-f22e-43d2-8611-139941c0afe7@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7_u3nhETmt1HNgygbQ_zcxrPrVixO_ea9BniH0GL_-k=.a1ecfa16-159e-4f0f-8272-775ec735dcca@github.com>
 <MH5D89e5VQToK7IOkspoRZ1xzwHIWcjj52lUJV6lqwA=.b23209f1-f22e-43d2-8611-139941c0afe7@github.com>
Message-ID: <D5dItMJ7gX-7nva4VmmMdIxEZjN9-ttAot_fXcRmkOU=.f0daeb73-9fc1-4a53-8edf-a721aea091f9@github.com>

On Fri, 19 May 2023 13:00:30 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 96:
>> 
>>> 94:         return connected;
>>> 95:     }
>>> 96: 
>> 
>> I wonder if it would be better to add a
>> 
>> 
>> void closeInputStream() { ... } // (or void close() { ... }?)
>> 
>> 
>> that would simply close the input stream if it's not null...
>
> `close()` would be natural enough, and would encapsulate behavior a bit better.
> 
> Should it then actually implement `Closeable`, permitting the implicit request in https://github.com/openjdk/jdk/pull/12871#discussion_r1198873512 to be addressed? That would not technically be an API change, since the implementation class is not exported, though it could be a behavioral change in case anyone is checking `instanceof Closeable` (or `instanceof AutoCloseable`); and would be a first step along the way to JDK-8224095, which may or may not be appropriate for something labeled a bug fix.

This is a good question. I we made `FileURLConnection` `Closeable` or `AutoCloseable`, and called `close()` in `JarURLConnection` when the underlying connection is `(Auto)Closeable` then I believe it could warrant a CSR. On the other hand IIRC the `file:` protocol handler cannot be overridden - so I'm not sure whether we could actually have a custom underlying `URLConnection` - that would need to be carefully evaluated.

Also, as you note, instance of FileURLConnection may be returned to user code - so the fact that the URLConnection implements `Closeable`/`Autocloseable` could be observed, and would also require a CSR.

That said - we could simply expose a close() method on `FileURLConnection` without implementing `Closeable`/`Autocloseable` - and could examine that (implementing `Closeable`/`Autocloseable`) in a different PR - perhaps as a Enhencement request - rather than a bug fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1198989388

From dfuchs at openjdk.org  Fri May 19 14:09:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 May 2023 14:09:50 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs
In-Reply-To: <D5dItMJ7gX-7nva4VmmMdIxEZjN9-ttAot_fXcRmkOU=.f0daeb73-9fc1-4a53-8edf-a721aea091f9@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7_u3nhETmt1HNgygbQ_zcxrPrVixO_ea9BniH0GL_-k=.a1ecfa16-159e-4f0f-8272-775ec735dcca@github.com>
 <MH5D89e5VQToK7IOkspoRZ1xzwHIWcjj52lUJV6lqwA=.b23209f1-f22e-43d2-8611-139941c0afe7@github.com>
 <D5dItMJ7gX-7nva4VmmMdIxEZjN9-ttAot_fXcRmkOU=.f0daeb73-9fc1-4a53-8edf-a721aea091f9@github.com>
Message-ID: <oA0OMLwWhlXK6ncOnQAB4YXKmro_JQO7NEWdza5g-vA=.29c5ece5-938b-4528-b11c-60a5862dd0d9@github.com>

On Fri, 19 May 2023 13:56:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> On the other hand IIRC the `file:` protocol handler cannot be overridden - so I'm not sure whether we could actually have a custom underlying `URLConnection` - that would need to be carefully evaluated.

Strike that. We could have of course a `jar:http://...` URL so the underlying connection is not necessarily a file connection and therefore can come from a custom protocol handler. So a CSR would definitely be needed if we started calling close() on custom URLConnections.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199001292

From duke at openjdk.org  Fri May 19 14:42:51 2023
From: duke at openjdk.org (Jesse Glick)
Date: Fri, 19 May 2023 14:42:51 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs
In-Reply-To: <oA0OMLwWhlXK6ncOnQAB4YXKmro_JQO7NEWdza5g-vA=.29c5ece5-938b-4528-b11c-60a5862dd0d9@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7_u3nhETmt1HNgygbQ_zcxrPrVixO_ea9BniH0GL_-k=.a1ecfa16-159e-4f0f-8272-775ec735dcca@github.com>
 <MH5D89e5VQToK7IOkspoRZ1xzwHIWcjj52lUJV6lqwA=.b23209f1-f22e-43d2-8611-139941c0afe7@github.com>
 <D5dItMJ7gX-7nva4VmmMdIxEZjN9-ttAot_fXcRmkOU=.f0daeb73-9fc1-4a53-8edf-a721aea091f9@github.com>
 <oA0OMLwWhlXK6ncOnQAB4YXKmro_JQO7NEWdza5g-vA=.29c5ece5-938b-4528-b11c-60a5862dd0d9@github.com>
Message-ID: <RkP4v9lDAORwRtzHtWM2c09hC1xZwlZBnm33IWZlBAg=.d82b937f-f3f4-40ef-9b87-5df15b819a8c@github.com>

On Fri, 19 May 2023 14:05:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is a good question. I we made `FileURLConnection` `Closeable` or `AutoCloseable`, and called `close()` in `JarURLConnection` when the underlying connection is `(Auto)Closeable` then I believe it could warrant a CSR. On the other hand IIRC the `file:` protocol handler cannot be overridden - so I'm not sure whether we could actually have a custom underlying `URLConnection` - that would need to be carefully evaluated.
>> 
>> Also, as you note, instance of FileURLConnection may be returned to user code - so the fact that the URLConnection implements `Closeable`/`Autocloseable` could be observed, and would also require a CSR.
>> 
>> That said - we could simply expose a close() method on `FileURLConnection` without implementing `Closeable`/`Autocloseable` - and could examine that (implementing `Closeable`/`Autocloseable`) in a different PR - perhaps as a Enhencement request - rather than a bug fix.
>
>> On the other hand IIRC the `file:` protocol handler cannot be overridden - so I'm not sure whether we could actually have a custom underlying `URLConnection` - that would need to be carefully evaluated.
> 
> Strike that. We could have of course a `jar:http://...` URL so the underlying connection is not necessarily a file connection and therefore can come from a custom protocol handler. So a CSR would definitely be needed if we started calling close() on custom URLConnections.

Yes.

Also I noticed that we cannot define `void close() throws IOException` here either, because of https://github.com/openjdk/jdk/blob/44218b1c9e5daa33557aac9336251cf8398d81eb/src/java.base/share/classes/sun/net/www/URLConnection.java#L256-L262 so for now I will go with another method name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199044325

From duke at openjdk.org  Fri May 19 15:06:25 2023
From: duke at openjdk.org (Jesse Glick)
Date: Fri, 19 May 2023 15:06:25 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v2]
In-Reply-To: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
Message-ID: <dbLve3FdLH_lgLdsBMSBxhoEpupJ85H5QtjUgKzQCps=.9ca60204-5838-43ee-8c84-452cf0ced300@github.com>

> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
> 
> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
> 
> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
> 
> 
> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
> 
> 
> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
> 
> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
> 
> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)

Jesse Glick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Encapsulate logic as `FileURLConnection.closeInputStream` as suggested by @dfuch https://github.com/openjdk/jdk/pull/12871#discussion_r1198859517
 - Merge branch 'master' of https://github.com/openjdk/jdk into FileURLConnectionLeak-JDK-6956385
 - Simplified `instanceof` form
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - 6956385: `JarURLConnection` may fail to close its underlying `FileURLConnection`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12871/files
  - new: https://git.openjdk.org/jdk/pull/12871/files/d909a290..37b042c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12871&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12871&range=00-01

  Stats: 656633 lines in 6912 files changed: 510801 ins; 89679 del; 56153 mod
  Patch: https://git.openjdk.org/jdk/pull/12871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12871/head:pull/12871

PR: https://git.openjdk.org/jdk/pull/12871

From duke at openjdk.org  Fri May 19 15:06:26 2023
From: duke at openjdk.org (Jesse Glick)
Date: Fri, 19 May 2023 15:06:26 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v2]
In-Reply-To: <dbLve3FdLH_lgLdsBMSBxhoEpupJ85H5QtjUgKzQCps=.9ca60204-5838-43ee-8c84-452cf0ced300@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <dbLve3FdLH_lgLdsBMSBxhoEpupJ85H5QtjUgKzQCps=.9ca60204-5838-43ee-8c84-452cf0ced300@github.com>
Message-ID: <0-6v5S0WDJRboMlgY7N1l5OtdH_hUyZgCNHB9MFkJ8k=.1c5b25b3-af76-45f0-b60a-134da615bd86@github.com>

On Fri, 19 May 2023 15:01:12 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
>> 
>> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
>> 
>> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
>> 
>> 
>> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
>> 
>> 
>> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
>> 
>> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
>> 
>> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)
>
> Jesse Glick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Encapsulate logic as `FileURLConnection.closeInputStream` as suggested by @dfuch https://github.com/openjdk/jdk/pull/12871#discussion_r1198859517
>  - Merge branch 'master' of https://github.com/openjdk/jdk into FileURLConnectionLeak-JDK-6956385
>  - Simplified `instanceof` form
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - 6956385: `JarURLConnection` may fail to close its underlying `FileURLConnection`

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 93:

> 91:     }
> 92: 
> 93:     public synchronized void closeInputStream() throws IOException {

Note that synchronization matches https://github.com/openjdk/jdk/blob/37b042c121d39f7eeca6bd75d77224ed433b65ea/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L182-L214 though https://github.com/openjdk/jdk/blob/37b042c121d39f7eeca6bd75d77224ed433b65ea/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L73-L91 is not synchronized, which smells suspicious (at least I think SpotBugs would flag this). There are other oddities in this old code such as the unused variables https://github.com/openjdk/jdk/blob/37b042c121d39f7eeca6bd75d77224ed433b65ea/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L185-L186 so I am trying to avoid larger changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199066043

From duke at openjdk.org  Fri May 19 15:10:59 2023
From: duke at openjdk.org (Jesse Glick)
Date: Fri, 19 May 2023 15:10:59 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v2]
In-Reply-To: <RkP4v9lDAORwRtzHtWM2c09hC1xZwlZBnm33IWZlBAg=.d82b937f-f3f4-40ef-9b87-5df15b819a8c@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7_u3nhETmt1HNgygbQ_zcxrPrVixO_ea9BniH0GL_-k=.a1ecfa16-159e-4f0f-8272-775ec735dcca@github.com>
 <MH5D89e5VQToK7IOkspoRZ1xzwHIWcjj52lUJV6lqwA=.b23209f1-f22e-43d2-8611-139941c0afe7@github.com>
 <D5dItMJ7gX-7nva4VmmMdIxEZjN9-ttAot_fXcRmkOU=.f0daeb73-9fc1-4a53-8edf-a721aea091f9@github.com>
 <oA0OMLwWhlXK6ncOnQAB4YXKmro_JQO7NEWdza5g-vA=.29c5ece5-938b-4528-b11c-60a5862dd0d9@github.com>
 <RkP4v9lDAORwRtzHtWM2c09hC1xZwlZBnm33IWZlBAg=.d82b937f-f3f4-40ef-9b87-5df15b819a8c@github.com>
Message-ID: <TbH1lvCk5lg6Xxn1UrKYCkAQ-uB-sqmegg00XRs-zfw=.c77ffa32-fcf2-4ac5-afdf-53ce88188dea@github.com>

On Fri, 19 May 2023 14:40:02 GMT, Jesse Glick <duke at openjdk.org> wrote:

>>> On the other hand IIRC the `file:` protocol handler cannot be overridden - so I'm not sure whether we could actually have a custom underlying `URLConnection` - that would need to be carefully evaluated.
>> 
>> Strike that. We could have of course a `jar:http://...` URL so the underlying connection is not necessarily a file connection and therefore can come from a custom protocol handler. So a CSR would definitely be needed if we started calling close() on custom URLConnections.
>
> Yes.
> 
> Also I noticed that we cannot define `void close() throws IOException` here either, because of https://github.com/openjdk/jdk/blob/44218b1c9e5daa33557aac9336251cf8398d81eb/src/java.base/share/classes/sun/net/www/URLConnection.java#L256-L262 so for now I will go with another method name.

Curiously, this method appears to never be called; at least


diff --git src/java.base/share/classes/sun/net/www/URLConnection.java src/java.base/share/classes/sun/net/www/URLConnection.java
index b3af24c594b..f346cd8869b 100644
--- src/java.base/share/classes/sun/net/www/URLConnection.java
+++ src/java.base/share/classes/sun/net/www/URLConnection.java
@@ -253,14 +253,6 @@ public abstract class URLConnection extends java.net.URLConnection {
                 REMIND */ ;
     }
 
-    /**
-     * Call this to close the connection and flush any remaining data.
-     * Overriders must remember to call super.close()
-     */
-    public void close() {
-        url = null;
-    }
-
     private static HashMap<String,Void> proxiedHosts = new HashMap<>();
 
     public static synchronized void setProxiedHost(String host) {


does not cause


make images


to fail, though it seems that the JDK source base does not currently enforce use of `@Override`. (I did not find any overrides from a text search, and if there were some without the annotation, they were apparently not calling `super.close()`.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199074116

From dfuchs at openjdk.org  Fri May 19 15:19:02 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 May 2023 15:19:02 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v2]
In-Reply-To: <0-6v5S0WDJRboMlgY7N1l5OtdH_hUyZgCNHB9MFkJ8k=.1c5b25b3-af76-45f0-b60a-134da615bd86@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <dbLve3FdLH_lgLdsBMSBxhoEpupJ85H5QtjUgKzQCps=.9ca60204-5838-43ee-8c84-452cf0ced300@github.com>
 <0-6v5S0WDJRboMlgY7N1l5OtdH_hUyZgCNHB9MFkJ8k=.1c5b25b3-af76-45f0-b60a-134da615bd86@github.com>
Message-ID: <OtIgx_vXhjZvCLS5psnm2CBnnn4SRKIqgZpEm3D65TI=.61aad08a-b920-4b8f-80a8-e08a0993cd4a@github.com>

On Fri, 19 May 2023 15:00:17 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> Jesse Glick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Encapsulate logic as `FileURLConnection.closeInputStream` as suggested by @dfuch https://github.com/openjdk/jdk/pull/12871#discussion_r1198859517
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into FileURLConnectionLeak-JDK-6956385
>>  - Simplified `instanceof` form
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - 6956385: `JarURLConnection` may fail to close its underlying `FileURLConnection`
>
> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 93:
> 
>> 91:     }
>> 92: 
>> 93:     public synchronized void closeInputStream() throws IOException {
> 
> Note that synchronization matches https://github.com/openjdk/jdk/blob/37b042c121d39f7eeca6bd75d77224ed433b65ea/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L182-L214 though https://github.com/openjdk/jdk/blob/37b042c121d39f7eeca6bd75d77224ed433b65ea/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L73-L91 is not synchronized, which smells suspicious (at least I think SpotBugs would flag this). There are other oddities in this old code such as the unused variables https://github.com/openjdk/jdk/blob/37b042c121d39f7eeca6bd75d77224ed433b65ea/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L185-L186 so I am trying to avoid larger changes.

Yes - that seems reasonable. I agree the use of synchronization here is a bit dubious. URL / URLConnection and connection Handlers are quite old and unfortunately suffer from a bad case of technical debt - which is hard to remove.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199083103

From dfuchs at openjdk.org  Fri May 19 15:19:03 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 May 2023 15:19:03 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v2]
In-Reply-To: <TbH1lvCk5lg6Xxn1UrKYCkAQ-uB-sqmegg00XRs-zfw=.c77ffa32-fcf2-4ac5-afdf-53ce88188dea@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7_u3nhETmt1HNgygbQ_zcxrPrVixO_ea9BniH0GL_-k=.a1ecfa16-159e-4f0f-8272-775ec735dcca@github.com>
 <MH5D89e5VQToK7IOkspoRZ1xzwHIWcjj52lUJV6lqwA=.b23209f1-f22e-43d2-8611-139941c0afe7@github.com>
 <D5dItMJ7gX-7nva4VmmMdIxEZjN9-ttAot_fXcRmkOU=.f0daeb73-9fc1-4a53-8edf-a721aea091f9@github.com>
 <oA0OMLwWhlXK6ncOnQAB4YXKmro_JQO7NEWdza5g-vA=.29c5ece5-938b-4528-b11c-60a5862dd0d9@github.com>
 <RkP4v9lDAORwRtzHtWM2c09hC1xZwlZBnm33IWZlBAg=.d82b937f-f3f4-40ef-9b87-5df15b819a8c@github.com>
 <TbH1lvCk5lg6Xxn1UrKYCkAQ-uB-sqmegg00XRs-zfw=.c77ffa32-fcf2-4ac5-afdf-53ce88188dea@github.com>
Message-ID: <4afEhiZODXbb7GJvBJMFTxQwDWHxjh5m9o3PT6_k3ZA=.a448445c-4447-4390-8773-c66e655bdfd5@github.com>

On Fri, 19 May 2023 15:07:37 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> Yes.
>> 
>> Also I noticed that we cannot define `void close() throws IOException` here either, because of https://github.com/openjdk/jdk/blob/44218b1c9e5daa33557aac9336251cf8398d81eb/src/java.base/share/classes/sun/net/www/URLConnection.java#L256-L262 so for now I will go with another method name.
>
> Curiously, this method appears to never be called; at least
> 
> 
> diff --git src/java.base/share/classes/sun/net/www/URLConnection.java src/java.base/share/classes/sun/net/www/URLConnection.java
> index b3af24c594b..f346cd8869b 100644
> --- src/java.base/share/classes/sun/net/www/URLConnection.java
> +++ src/java.base/share/classes/sun/net/www/URLConnection.java
> @@ -253,14 +253,6 @@ public abstract class URLConnection extends java.net.URLConnection {
>                  REMIND */ ;
>      }
>  
> -    /**
> -     * Call this to close the connection and flush any remaining data.
> -     * Overriders must remember to call super.close()
> -     */
> -    public void close() {
> -        url = null;
> -    }
> -
>      private static HashMap<String,Void> proxiedHosts = new HashMap<>();
>  
>      public static synchronized void setProxiedHost(String host) {
> 
> 
> does not cause
> 
> 
> make images
> 
> 
> to fail, though it seems that the JDK source base does not currently enforce use of `@Override`. (I did not find any overrides from a text search, and if there were some without the annotation, they were apparently not calling `super.close()`.)

Interesting. If it's not called anywhere maybe we could investigate adding `throws IOException` to the signature...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199080504

From dfuchs at openjdk.org  Fri May 19 15:22:09 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 May 2023 15:22:09 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v2]
In-Reply-To: <dbLve3FdLH_lgLdsBMSBxhoEpupJ85H5QtjUgKzQCps=.9ca60204-5838-43ee-8c84-452cf0ced300@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <dbLve3FdLH_lgLdsBMSBxhoEpupJ85H5QtjUgKzQCps=.9ca60204-5838-43ee-8c84-452cf0ced300@github.com>
Message-ID: <oCC4k2aXpfWtmL6Yk1N_APZUHjYSImCqpT41jsMIveU=.9047edfd-fa5a-4256-bf8e-9c4732e9ca5f@github.com>

On Fri, 19 May 2023 15:06:25 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
>> 
>> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
>> 
>> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
>> 
>> 
>> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
>> 
>> 
>> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
>> 
>> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
>> 
>> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)
>
> Jesse Glick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Encapsulate logic as `FileURLConnection.closeInputStream` as suggested by @dfuch https://github.com/openjdk/jdk/pull/12871#discussion_r1198859517
>  - Merge branch 'master' of https://github.com/openjdk/jdk into FileURLConnectionLeak-JDK-6956385
>  - Simplified `instanceof` form
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - 6956385: `JarURLConnection` may fail to close its underlying `FileURLConnection`

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 97:

> 95:             is.close();
> 96:             is = null;
> 97:             connected = false;

Not sure about switching `connected` to false or setting `is` to null. That might allow to call `connect` again and might have unintended side effects?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199085883

From duke at openjdk.org  Fri May 19 15:27:00 2023
From: duke at openjdk.org (Jesse Glick)
Date: Fri, 19 May 2023 15:27:00 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v2]
In-Reply-To: <4afEhiZODXbb7GJvBJMFTxQwDWHxjh5m9o3PT6_k3ZA=.a448445c-4447-4390-8773-c66e655bdfd5@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7_u3nhETmt1HNgygbQ_zcxrPrVixO_ea9BniH0GL_-k=.a1ecfa16-159e-4f0f-8272-775ec735dcca@github.com>
 <MH5D89e5VQToK7IOkspoRZ1xzwHIWcjj52lUJV6lqwA=.b23209f1-f22e-43d2-8611-139941c0afe7@github.com>
 <D5dItMJ7gX-7nva4VmmMdIxEZjN9-ttAot_fXcRmkOU=.f0daeb73-9fc1-4a53-8edf-a721aea091f9@github.com>
 <oA0OMLwWhlXK6ncOnQAB4YXKmro_JQO7NEWdza5g-vA=.29c5ece5-938b-4528-b11c-60a5862dd0d9@github.com>
 <RkP4v9lDAORwRtzHtWM2c09hC1xZwlZBnm33IWZlBAg=.d82b937f-f3f4-40ef-9b87-5df15b819a8c@github.com>
 <TbH1lvCk5lg6Xxn1UrKYCkAQ-uB-sqmegg00XRs-zfw=.c77ffa32-fcf2-4ac5-afdf-53ce88188dea@github.com>
 <4afEhiZODXbb7GJvBJMFTxQwDWHxjh5m9o3PT6_k3ZA=.a448445c-4447-4390-8773-c66e655bdfd5@github.com>
Message-ID: <TKvYH7u2L-HN4VXIe1fl4_QsDxtk9VF377ja4nzVi3U=.3361b74c-b13b-4a3c-99e7-87efcf40bb16@github.com>

On Fri, 19 May 2023 15:13:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Curiously, this method appears to never be called; at least
>> 
>> 
>> diff --git src/java.base/share/classes/sun/net/www/URLConnection.java src/java.base/share/classes/sun/net/www/URLConnection.java
>> index b3af24c594b..f346cd8869b 100644
>> --- src/java.base/share/classes/sun/net/www/URLConnection.java
>> +++ src/java.base/share/classes/sun/net/www/URLConnection.java
>> @@ -253,14 +253,6 @@ public abstract class URLConnection extends java.net.URLConnection {
>>                  REMIND */ ;
>>      }
>>  
>> -    /**
>> -     * Call this to close the connection and flush any remaining data.
>> -     * Overriders must remember to call super.close()
>> -     */
>> -    public void close() {
>> -        url = null;
>> -    }
>> -
>>      private static HashMap<String,Void> proxiedHosts = new HashMap<>();
>>  
>>      public static synchronized void setProxiedHost(String host) {
>> 
>> 
>> does not cause
>> 
>> 
>> make images
>> 
>> 
>> to fail, though it seems that the JDK source base does not currently enforce use of `@Override`. (I did not find any overrides from a text search, and if there were some without the annotation, they were apparently not calling `super.close()`.)
>
> Interesting. If it's not called anywhere maybe we could investigate adding `throws IOException` to the signature...

That is also an option of course; would be binary compatible. Happy to take that approach if you think it would be clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199090958

From duke at openjdk.org  Fri May 19 15:37:57 2023
From: duke at openjdk.org (Jesse Glick)
Date: Fri, 19 May 2023 15:37:57 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v2]
In-Reply-To: <oCC4k2aXpfWtmL6Yk1N_APZUHjYSImCqpT41jsMIveU=.9047edfd-fa5a-4256-bf8e-9c4732e9ca5f@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <dbLve3FdLH_lgLdsBMSBxhoEpupJ85H5QtjUgKzQCps=.9ca60204-5838-43ee-8c84-452cf0ced300@github.com>
 <oCC4k2aXpfWtmL6Yk1N_APZUHjYSImCqpT41jsMIveU=.9047edfd-fa5a-4256-bf8e-9c4732e9ca5f@github.com>
Message-ID: <rRujNVZaElDFjRz92I0WoBf7jtsBKefS_J1vkVaGwqA=.33074fe0-e9bc-4d70-901c-297fe413e166@github.com>

On Fri, 19 May 2023 15:19:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jesse Glick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Encapsulate logic as `FileURLConnection.closeInputStream` as suggested by @dfuch https://github.com/openjdk/jdk/pull/12871#discussion_r1198859517
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into FileURLConnectionLeak-JDK-6956385
>>  - Simplified `instanceof` form
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - 6956385: `JarURLConnection` may fail to close its underlying `FileURLConnection`
>
> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 97:
> 
>> 95:             is.close();
>> 96:             is = null;
>> 97:             connected = false;
> 
> Not sure about switching `connected` to false or setting `is` to null. That might allow to call `connect` again and might have unintended side effects?

It depends on whether you consider the new method to be the opposite of `connect`, toggling between connected and unconnected states. Removing these two lines would mean that a subsequent call to `getInputStream()` would return a closed stream, which may or may not be surprising. An aspect of JDK-8224095 is that the state transitions for `URLConnection` are generally confusing. For now it seems irrelevant since `JarURLConnection.jarFileURLConnection` is never used for its input stream. In fact I think `closeInputStream` could just be moved into `JarURLConnection.<init>` for this reason.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199101446

From duke at openjdk.org  Fri May 19 15:46:14 2023
From: duke at openjdk.org (Jesse Glick)
Date: Fri, 19 May 2023 15:46:14 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
Message-ID: <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>

> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
> 
> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
> 
> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
> 
> 
> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
> 
> 
> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
> 
> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
> 
> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)

Jesse Glick has updated the pull request incrementally with one additional commit since the last revision:

  Leaving `FileURLConnection.is` non-null, and claiming `connected`, even after `closeInputStream` https://github.com/openjdk/jdk/pull/12871#discussion_r1199085883

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12871/files
  - new: https://git.openjdk.org/jdk/pull/12871/files/37b042c1..232e4f2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12871&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12871&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12871/head:pull/12871

PR: https://git.openjdk.org/jdk/pull/12871

From dfuchs at openjdk.org  Fri May 19 15:48:53 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 May 2023 15:48:53 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v2]
In-Reply-To: <rRujNVZaElDFjRz92I0WoBf7jtsBKefS_J1vkVaGwqA=.33074fe0-e9bc-4d70-901c-297fe413e166@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <dbLve3FdLH_lgLdsBMSBxhoEpupJ85H5QtjUgKzQCps=.9ca60204-5838-43ee-8c84-452cf0ced300@github.com>
 <oCC4k2aXpfWtmL6Yk1N_APZUHjYSImCqpT41jsMIveU=.9047edfd-fa5a-4256-bf8e-9c4732e9ca5f@github.com>
 <rRujNVZaElDFjRz92I0WoBf7jtsBKefS_J1vkVaGwqA=.33074fe0-e9bc-4d70-901c-297fe413e166@github.com>
Message-ID: <M7Vu2da7r9wWRxGABy5DVqDdjpU6xurIHmKfeL4YFj4=.299e3dfd-bde6-4637-9967-aaafff7e4ee8@github.com>

On Fri, 19 May 2023 15:34:45 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 97:
>> 
>>> 95:             is.close();
>>> 96:             is = null;
>>> 97:             connected = false;
>> 
>> Not sure about switching `connected` to false or setting `is` to null. That might allow to call `connect` again and might have unintended side effects?
>
> It depends on whether you consider the new method to be the opposite of `connect`, toggling between connected and unconnected states. Removing these two lines would mean that a subsequent call to `getInputStream()` would return a closed stream, which may or may not be surprising. An aspect of JDK-8224095 is that the state transitions for `URLConnection` are generally confusing. For now it seems irrelevant since `JarURLConnection.jarFileURLConnection` is never used for its input stream.
> 
> ~In fact I think `closeInputStream` could just be moved into `JarURLConnection.<init>` for this reason.~ No, it cannot, since `FileURLConnection.is` is opened only if and when a header is requested.

Well yes - exactly my point. At the moment if you call getInputStream() twice in succession you will get the same input stream. The transition from not connected to connected is stable. `connect` can only transition once from `false` to `true`.  There's nothing that sets `is` back to `null` or `connect` back to `false` so I believe it should stay that way.

Let's keep the (behaviour) changes minimal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1199112611

From dfuchs at openjdk.org  Fri May 19 15:56:55 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 May 2023 15:56:55 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
Message-ID: <5xC40F3-BUs0b0BxZOCo0WgeKexU3gv7XR30WvmGQWM=.177043ba-cbeb-42a2-b017-d9490cf36a43@github.com>

On Fri, 19 May 2023 15:46:14 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
>> 
>> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
>> 
>> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
>> 
>> 
>> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
>> 
>> 
>> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
>> 
>> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
>> 
>> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)
>
> Jesse Glick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leaving `FileURLConnection.is` non-null, and claiming `connected`, even after `closeInputStream` https://github.com/openjdk/jdk/pull/12871#discussion_r1199085883

The latest revision look reasonable to me. At a minimum please run all URL/URL Stream Handler tests. If you have no more changes planned I'll import the PR and give it a round of additional testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12871#issuecomment-1554783036

From duke at openjdk.org  Fri May 19 16:16:54 2023
From: duke at openjdk.org (Jesse Glick)
Date: Fri, 19 May 2023 16:16:54 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
Message-ID: <2s-hmbnCj5fZDhYNxA3vdDZG5KeqruwZoDukc44isN8=.0becbfa4-c362-4fe5-9f68-9d3bf4c88ee6@github.com>

On Fri, 19 May 2023 15:46:14 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
>> 
>> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
>> 
>> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
>> 
>> 
>> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
>> 
>> 
>> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
>> 
>> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
>> 
>> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)
>
> Jesse Glick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leaving `FileURLConnection.is` non-null, and claiming `connected`, even after `closeInputStream` https://github.com/openjdk/jdk/pull/12871#discussion_r1199085883

Running


make test TEST=:jdk_net


on Linux. Getting some sort of timeout error on `java/net/DatagramSocket/DatagramSocketExample.java` (will recheck against a clean build of `master`). Rest in progress?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12871#issuecomment-1554806616

From dfuchs at openjdk.org  Fri May 19 16:19:01 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 May 2023 16:19:01 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v7]
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <flbZotnSCZ5FqurFp8IBEppsmLj6GG3sw82U2hJf1zQ=.d8a78e71-40bc-410a-a136-a16841ca4fd3@github.com>

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14038/files
  - new: https://git.openjdk.org/jdk/pull/14038/files/e3d60965..153826db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

PR: https://git.openjdk.org/jdk/pull/14038

From duke at openjdk.org  Mon May 22 10:22:56 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 22 May 2023 10:22:56 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <MIanutU-5zaHU08XWWykYRu2HSZhUfGSr70gu9SZ2ug=.77440635-04f7-4cbe-b573-a2322fed985b@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
 <MIanutU-5zaHU08XWWykYRu2HSZhUfGSr70gu9SZ2ug=.77440635-04f7-4cbe-b573-a2322fed985b@github.com>
Message-ID: <_gCEzkKMiIQiTGFQMSmpM0E4xnXPig7RaUPT3tbZNts=.e904c7f1-cf98-4987-ad0f-861689b83078@github.com>

On Fri, 19 May 2023 11:24:30 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Seems like a useful change and I can see how issues could arise if strings were stored somewhere after being upper/lower cased and then reused in a different locale.
> 
> Is it correct to say that the assumption is these strings are all supposed to be US ASCII (eg protocol defined identifiers, or hostnames etc) rather than user generated text strings? That seems to be the case as far as I can see.

Yes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14006#issuecomment-1556955595

From serb at openjdk.org  Mon May 22 10:26:58 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 22 May 2023 10:26:58 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v5]
In-Reply-To: <41oJNq2m5C4tJe857tiFnCqn3kzidORfy_l0tsawgBQ=.c1bb39a6-01e3-4ffc-82c5-87280009e60b@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <32LnosjQ6BjtjndPmWiXGsnT_M2V23eiKf1g2sf__mM=.f80efa43-d669-4c68-81dc-5db1c3a44d97@github.com>
 <41oJNq2m5C4tJe857tiFnCqn3kzidORfy_l0tsawgBQ=.c1bb39a6-01e3-4ffc-82c5-87280009e60b@github.com>
Message-ID: <vMdlK42HTkmckBet2TEimMq8UWSMGZ0joWCrvC_m2Sk=.6aa72b4b-5783-427b-9e2a-de7c2ab76f84@github.com>

On Thu, 27 Apr 2023 13:55:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8304885
>>  - documentation
>>  - PR feedback
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8304885
>>  - Use "maximum stale timer" instead of the extended timeout, and bump it on each successful lookup
>>  -  the suggested cap is 7 days
>>  - simplify
>>  - comments
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8304885
>>  - 8304885: Reuse stale data to improve DNS resolver resiliency
>
> I think this is a very useful enhancement, and I like the approach. To aid understanding can I suggest renaming a couple of the implementation classes (one already existing) and adding some apidoc as follows. I'd like to spend some more time studying the change also.
> 
> 
> /**
>  * A cached result of a name service lookup. The result
>  * can be either valid addresses or invalid (ie a failed lookup) 
>  * containing no addresses
>  */
> CachedAddresses -> CachedLookup
> 
> /**
>  * A cached valid lookup containing addresses whose validity
>  * may be temporarily extended by an additional stale period
>  * pending the mapping being refreshed or updated
>  */
> ValidAddresses -> ValidCachedLookup

@Michael-Mc-Mahon @djelinski @dfuch do you have any other comments? The CSR was updated based on feedback, please take a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1556963916

From duke at openjdk.org  Mon May 22 10:57:02 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 22 May 2023 10:57:02 GMT
Subject: Integrated: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <UAfznS1njzmi0P8cL1j0-1NSA3gF-qhhWRAmqgiK0qM=.d8f27bbc-31d2-4936-9e23-1b7570696181@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

This pull request has now been integrated.

Changeset: 05e99db4
Author:    Darragh Clarke <darraghclarke98 at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05e99db466e7ef5c26f089db772a21cb2ca62e93
Stats:     74 lines in 20 files changed: 14 ins; 0 del; 60 mod

7065228: To interpret case-insensitive string locale independently

Reviewed-by: dfuchs, naoto, djelinski, jpai, michaelm

-------------

PR: https://git.openjdk.org/jdk/pull/14006

From dfuchs at openjdk.org  Mon May 22 13:01:19 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 May 2023 13:01:19 GMT
Subject: RFR: 8308545: java/net/httpclient/ShutdownNow.java fails with
 "stream 1 cancelled"
Message-ID: <FBq83YlKyoQcf-VMgSpZMVfpzfv5hg4Cj5XQ5IWoocw=.1b2caee2-aa0f-420f-bd86-6def72d75b49@github.com>

The test `test/jdk/java/net/httpclient/ShutdownNow.java` has been observed failing intermittently (though rarely) with an assertion error: `java.lang.AssertionError: 0: Unexpected exception: java.io.IOException: Stream 1 cancelled` caused by  


java.io.IOException: Stream 1 cancelled
at java.net.http/jdk.internal.net.http.Stream.cancel(Stream.java:1285) 


Given the nature of the test - which interrupts / cancel all operations asynchronously, then a "stream %d cancelled" exception should count as an acceptable result.

-------------

Commit messages:
 - 8308545

Changes: https://git.openjdk.org/jdk/pull/14081/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14081&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308545
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14081/head:pull/14081

PR: https://git.openjdk.org/jdk/pull/14081

From dfuchs at openjdk.org  Mon May 22 15:34:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 May 2023 15:34:51 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
Message-ID: <2hFkdbK-ftmaHm59InJYoVaxI_f1Q0wcsyUzAVBOkyg=.9fede49f-3867-4160-bce8-13a865b574ce@github.com>

On Fri, 19 May 2023 15:46:14 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
>> 
>> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
>> 
>> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
>> 
>> 
>> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
>> 
>> 
>> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
>> 
>> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
>> 
>> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)
>
> Jesse Glick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leaving `FileURLConnection.is` non-null, and claiming `connected`, even after `closeInputStream` https://github.com/openjdk/jdk/pull/12871#discussion_r1199085883

Marked as reviewed by dfuchs (Reviewer).

I have run tier1, tier2, tier3, and several repeated runs of jdk_net in our CI and haven't observed any failures related to the proposed changes. As far as I am concerned, this looks good. I am going to approve, but it would good to have a second Reviewer in case I missed anything.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12871#pullrequestreview-1436897162
PR Comment: https://git.openjdk.org/jdk/pull/12871#issuecomment-1557432162

From dfuchs at openjdk.org  Mon May 22 15:54:08 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 May 2023 15:54:08 GMT
Subject: RFR: 8308565: HttpClient: Sanitize logging while stopping
Message-ID: <VzQi0WRwmdVHhiXpyp8-N260r78PKSJ7gebVq-S6RlA=.5a15c4a5-e6f3-48d3-b3f2-c258a8e6cf82@github.com>

When the HttpClient is stopping many exception stack traces may be logged, in particular if the Http2Connection attempts to send a GOAWAY frame after the underlying TCP connection or the selector have been closed.

The Http2Connection should look at the Http2ClientImpl state before logging the exception as an error. If the Http2ClientImpl is stopping, a simple debug message should be enough.

-------------

Commit messages:
 - 8308565

Changes: https://git.openjdk.org/jdk/pull/14089/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14089&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308565
  Stats: 31 lines in 2 files changed: 25 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14089.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14089/head:pull/14089

PR: https://git.openjdk.org/jdk/pull/14089

From duke at openjdk.org  Mon May 22 16:04:00 2023
From: duke at openjdk.org (Bernd)
Date: Mon, 22 May 2023 16:04:00 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
Message-ID: <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>

On Fri, 19 May 2023 15:46:14 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
>> 
>> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
>> 
>> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
>> 
>> 
>> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
>> 
>> 
>> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
>> 
>> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
>> 
>> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)
>
> Jesse Glick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leaving `FileURLConnection.is` non-null, and claiming `connected`, even after `closeInputStream` https://github.com/openjdk/jdk/pull/12871#discussion_r1199085883

src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java line 97:

> 95:                     }
> 96:                 } finally {
> 97:                     if (jarFileURLConnection instanceof FileURLConnection fileURLConnection) {

I Wonder if closing all urlconnection types or the ones with a special interface instead of a specific type (which also introduces a dependency) would be the better way? what about other connections with even more temporary resources (like a temporary file copy?)

test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java line 53:

> 51:         // FileURLConnection.is opened implicitly:
> 52:         var conn = u.openConnection();
> 53:         conn.getContentEncoding();

Should it also call getLastModified() just to satisfy the bugs title?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200714487
PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200716271

From duke at openjdk.org  Mon May 22 16:07:02 2023
From: duke at openjdk.org (Jesse Glick)
Date: Mon, 22 May 2023 16:07:02 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
Message-ID: <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>

On Mon, 22 May 2023 15:58:01 GMT, Bernd <duke at openjdk.org> wrote:

>> Jesse Glick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Leaving `FileURLConnection.is` non-null, and claiming `connected`, even after `closeInputStream` https://github.com/openjdk/jdk/pull/12871#discussion_r1199085883
>
> src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java line 97:
> 
>> 95:                     }
>> 96:                 } finally {
>> 97:                     if (jarFileURLConnection instanceof FileURLConnection fileURLConnection) {
> 
> I Wonder if closing all urlconnection types or the ones with a special interface instead of a specific type (which also introduces a dependency) would be the better way? what about other connections with even more temporary resources (like a temporary file copy?)

See discussion at https://github.com/openjdk/jdk/pull/12871#discussion_r1198932229.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200725883

From duke at openjdk.org  Mon May 22 16:19:40 2023
From: duke at openjdk.org (Jesse Glick)
Date: Mon, 22 May 2023 16:19:40 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v4]
In-Reply-To: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
Message-ID: <mL1PdZQWs0Q7rqy0SSjEbBBJj5V4n90YhaffCBphoxw=.ad21f9dd-403f-4cd4-b30b-e3ea732728b0@github.com>

> [JDK-6956385](https://bugs.openjdk.org/browse/JDK-6956385): `JarURLConnection` properly tracks any `InputStream` it itself opened, and correspondingly closes the `JarFile` if necessary (when caches are disabled). However if its underlying `FileURLConnection` was used to retrieve a header field, that would have caused a `FileInputStream` to be opened which never gets closed until it is garbage collected. This means that an application which calls certain methods on `jar:file:/?something.jar!/?` URLs will leak file handles, even if `URLConnection` caches are supposed to be turned off. This can delay release of system resources, and on Windows can prevent the JAR file from being deleted even after it is no longer in use (for example after `URLClassLoader.close`).
> 
> [JDK-8224095](https://bugs.openjdk.org/browse/JDK-8224095) was marked as a duplicate, but I think incorrectly. It refers to `FileURLConnection`, and seems to be complaining about the confusing API design of `URLConnection` generally: that it is an object which you might expect to be `Closeable` but in fact it is its `inputStream` which must be `close`d. In JDK-6956385, even when the caller _does_ specifically call `InputStream.close`, a file handle may be leaked.
> 
> I managed to build the JDK on both Linux and (Cygwin) Windows to confirm the fix via
> 
> 
> ./build/?-x86_64-server-release/jdk/bin/java test/jdk/sun/net/www/protocol/jar/FileURLConnectionLeak.java
> 
> 
> I also ran jtreg on Linux (this test and various others in nearby packages); on Windows the `make test` target just hung for some reason.
> 
> I marked the test `othervm` out of caution, since it is mutating global state, and if it fails will leak a handle and prevent scratch dir cleanup on Windows.
> 
> (This is my first contribution, at least after the move to GitHub, so let me know if something is missing here technically or stylistically. None of the contribution guides appear to be up to date.)

Jesse Glick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into FileURLConnectionLeak-JDK-6956385
 - `URLConnection.getLastModified` reproduces the bug the same as `getContentEncoding` but better matches the bug title (suggested by @ecki https://github.com/openjdk/jdk/pull/12871#discussion_r1200716271)
 - Leaving `FileURLConnection.is` non-null, and claiming `connected`, even after `closeInputStream` https://github.com/openjdk/jdk/pull/12871#discussion_r1199085883
 - Encapsulate logic as `FileURLConnection.closeInputStream` as suggested by @dfuch https://github.com/openjdk/jdk/pull/12871#discussion_r1198859517
 - Merge branch 'master' of https://github.com/openjdk/jdk into FileURLConnectionLeak-JDK-6956385
 - Simplified `instanceof` form
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - 6956385: `JarURLConnection` may fail to close its underlying `FileURLConnection`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12871/files
  - new: https://git.openjdk.org/jdk/pull/12871/files/232e4f2e..64efe35a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12871&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12871&range=02-03

  Stats: 14525 lines in 574 files changed: 7767 ins; 4747 del; 2011 mod
  Patch: https://git.openjdk.org/jdk/pull/12871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12871/head:pull/12871

PR: https://git.openjdk.org/jdk/pull/12871

From duke at openjdk.org  Mon May 22 16:19:41 2023
From: duke at openjdk.org (Bernd)
Date: Mon, 22 May 2023 16:19:41 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
 <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
Message-ID: <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>

On Mon, 22 May 2023 16:04:10 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java line 97:
>> 
>>> 95:                     }
>>> 96:                 } finally {
>>> 97:                     if (jarFileURLConnection instanceof FileURLConnection fileURLConnection) {
>> 
>> I Wonder if closing all urlconnection types or the ones with a special interface instead of a specific type (which also introduces a dependency) would be the better way? what about other connections with even more temporary resources (like a temporary file copy?)
>
> See discussion at https://github.com/openjdk/jdk/pull/12871#discussion_r1198932229.

It does not address the question if it needs to close more than the file: protocol.

(And it still feels like a layering violation, should maybe the metadata function initializeHeaders close its own stream - balanced with connect())?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200732253

From dfuchs at openjdk.org  Mon May 22 16:34:52 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 May 2023 16:34:52 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
 <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
 <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>
Message-ID: <RCvm4JC-fpoR7bqrLdf2biktwyxX-5O9g81vRt0xy-c=.294b8c10-8634-4ea3-8fdb-71c6d918fdd0@github.com>

On Mon, 22 May 2023 16:10:17 GMT, Bernd <duke at openjdk.org> wrote:

>> See discussion at https://github.com/openjdk/jdk/pull/12871#discussion_r1198932229.
>
> It does not address the question if it needs to close more than the file: protocol.
> 
> (And it still feels like a layering violation, should maybe the metadata function initializeHeaders close its own stream - balanced with connect())?

If we wanted to make JarURLConnection call AutoCloseable::close (or Closeable::close) when the underlying URLConnection is `AutoCloseable` - that would be a change of behaviour that would be observable by custom URLConnection implementations provided by custom URL Stream Handler.

That would be a change of behavior requiring a CSR, and it might not be appropriate for backport, due to potential backward compatibility issue (well - that would be a matter to discuss in the CSR anyway).

That's why I would advise to not try to do this in this PR. If we wanted to do it - we should probably log an RFE for that. Also examine what it means for `URL.openConnection()` to return an object that implements `AutoCloseable`. A the very least, an `@apiNote` would be needed in URL API documentation. 

Unless this really solves some real hard issue (as opposed to theoretical issues) for which we have no solution today, I would be very prudent with making wider changes to this old, intricate, and hard to maintain piece of code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200754171

From duke at openjdk.org  Mon May 22 17:22:52 2023
From: duke at openjdk.org (Jesse Glick)
Date: Mon, 22 May 2023 17:22:52 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <RCvm4JC-fpoR7bqrLdf2biktwyxX-5O9g81vRt0xy-c=.294b8c10-8634-4ea3-8fdb-71c6d918fdd0@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
 <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
 <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>
 <RCvm4JC-fpoR7bqrLdf2biktwyxX-5O9g81vRt0xy-c=.294b8c10-8634-4ea3-8fdb-71c6d918fdd0@github.com>
Message-ID: <sz1ARwkmgyKicdVlKsVG2sXOCBFZYDxshlAEBd0LbKs=.f224ac95-b35b-4f1d-964c-af1ed565fbf0@github.com>

On Mon, 22 May 2023 16:31:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> It does not address the question if it needs to close more than the file: protocol.
>> 
>> (And it still feels like a layering violation, should maybe the metadata function initializeHeaders close its own stream - balanced with connect())?
>
> If we wanted to make JarURLConnection call AutoCloseable::close (or Closeable::close) when the underlying URLConnection is `AutoCloseable` - that would be a change of behaviour that would be observable by custom URLConnection implementations provided by custom URL Stream Handler.
> 
> That would be a change of behavior requiring a CSR, and it might not be appropriate for backport, due to potential backward compatibility issue (well - that would be a matter to discuss in the CSR anyway).
> 
> That's why I would advise to not try to do this in this PR. If we wanted to do it - we should probably log an RFE for that. Also examine what it means for `URL.openConnection()` to return an object that implements `AutoCloseable`. A the very least, an `@apiNote` would be needed in URL API documentation. 
> 
> Unless this really solves some real hard issue (as opposed to theoretical issues) for which we have no solution today, I would be very prudent with making wider changes to this old, intricate, and hard to maintain piece of code.

> should maybe the metadata function initializeHeaders close its own stream

Another possibility is for `FileURLConnection.getHeaderField(String)` and related methods to never open a `FileInputStream` to begin with, amending https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L96-L100 That would require overriding at least https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/URLConnection.java#L104-L131 since https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L137-L140 etc. call `super`. The legality of such a change in light of https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/java/net/URLConnection.java#L57-L66 https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/java/net/URLConnection.ja
 va#L92-L96 is unclear; the Javadoc implies but does not state that you _cannot_ access header fields before `connect()` is called. On the other hand https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java#L232-L235 apparently presumes that any request for a header field implicitly `connect()`s if it needed to.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200807234

From dfuchs at openjdk.org  Mon May 22 17:42:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 May 2023 17:42:51 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <sz1ARwkmgyKicdVlKsVG2sXOCBFZYDxshlAEBd0LbKs=.f224ac95-b35b-4f1d-964c-af1ed565fbf0@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
 <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
 <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>
 <RCvm4JC-fpoR7bqrLdf2biktwyxX-5O9g81vRt0xy-c=.294b8c10-8634-4ea3-8fdb-71c6d918fdd0@github.com>
 <sz1ARwkmgyKicdVlKsVG2sXOCBFZYDxshlAEBd0LbKs=.f224ac95-b35b-4f1d-964c-af1ed565fbf0@github.com>
Message-ID: <V69l5WRMZbFoOlnOBDAFHmHGc7x1Q_Htci4keiJPAig=.486d53f5-0ed9-4f60-a4ee-04457df74ac6@github.com>

On Mon, 22 May 2023 17:19:43 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> If we wanted to make JarURLConnection call AutoCloseable::close (or Closeable::close) when the underlying URLConnection is `AutoCloseable` - that would be a change of behaviour that would be observable by custom URLConnection implementations provided by custom URL Stream Handler.
>> 
>> That would be a change of behavior requiring a CSR, and it might not be appropriate for backport, due to potential backward compatibility issue (well - that would be a matter to discuss in the CSR anyway).
>> 
>> That's why I would advise to not try to do this in this PR. If we wanted to do it - we should probably log an RFE for that. Also examine what it means for `URL.openConnection()` to return an object that implements `AutoCloseable`. A the very least, an `@apiNote` would be needed in URL API documentation. 
>> 
>> Unless this really solves some real hard issue (as opposed to theoretical issues) for which we have no solution today, I would be very prudent with making wider changes to this old, intricate, and hard to maintain piece of code.
>
>> should maybe the metadata function initializeHeaders close its own stream
> 
> Another possibility is for `FileURLConnection.getHeaderField(String)` and related methods to never open a `FileInputStream` to begin with, amending https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L96-L100 That would require overriding at least https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/URLConnection.java#L104-L131 since https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L137-L140 etc. call `super`. The legality of such a change in light of https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/java/net/URLConnection.java#L57-L66 https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/java/net/URLConnection.
 java#L92-L96 is unclear; the Javadoc implies but does not state that you _cannot_ access header fields before `connect()` is called. On the other hand https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java#L232-L235 apparently presumes that any request for a header field implicitly `connect()`s if it needed to.

That seems like it could cause other issues down the road though. `FileURLConnection::connect` has this comment:


    /*
     * Note: the semantics of FileURLConnection object is that the
     * results of the various URLConnection calls, such as
     * getContentType, getInputStream or getContentLength reflect
     * whatever was true when connect was called.
     */
    public void connect() throws IOException {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200832807

From duke at openjdk.org  Mon May 22 17:46:50 2023
From: duke at openjdk.org (Jesse Glick)
Date: Mon, 22 May 2023 17:46:50 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <V69l5WRMZbFoOlnOBDAFHmHGc7x1Q_Htci4keiJPAig=.486d53f5-0ed9-4f60-a4ee-04457df74ac6@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
 <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
 <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>
 <RCvm4JC-fpoR7bqrLdf2biktwyxX-5O9g81vRt0xy-c=.294b8c10-8634-4ea3-8fdb-71c6d918fdd0@github.com>
 <sz1ARwkmgyKicdVlKsVG2sXOCBFZYDxshlAEBd0LbKs=.f224ac95-b35b-4f1d-964c-af1ed565fbf0@github.com>
 <V69l5WRMZbFoOlnOBDAFHmHGc7x1Q_Htci4keiJPAig=.486d53f5-0ed9-4f60-a4ee-04457df74ac6@github.com>
Message-ID: <Ff9qI39JwumYL0xlRRg_uQwbxMvsg6vx8HpxM6s1udU=.715b610d-5602-4c5f-9923-e2bbc4d62bb1@github.com>

On Mon, 22 May 2023 17:40:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> should maybe the metadata function initializeHeaders close its own stream
>> 
>> Another possibility is for `FileURLConnection.getHeaderField(String)` and related methods to never open a `FileInputStream` to begin with, amending https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L96-L100 That would require overriding at least https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/URLConnection.java#L104-L131 since https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java#L137-L140 etc. call `super`. The legality of such a change in light of https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/java/net/URLConnection.java#L57-L66 https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/java/net/URLConnection
 .java#L92-L96 is unclear; the Javadoc implies but does not state that you _cannot_ access header fields before `connect()` is called. On the other hand https://github.com/openjdk/jdk/blob/8474e693b4404ba62927fe0e43e68b904d66fbde/src/java.base/share/classes/sun/net/www/protocol/jar/JarURLConnection.java#L232-L235 apparently presumes that any request for a header field implicitly `connect()`s if it needed to.
>
> That seems like it could cause other issues down the road though. `FileURLConnection::connect` has this comment:
> 
> 
>     /*
>      * Note: the semantics of FileURLConnection object is that the
>      * results of the various URLConnection calls, such as
>      * getContentType, getInputStream or getContentLength reflect
>      * whatever was true when connect was called.
>      */
>     public void connect() throws IOException {

This patch appears to be work and may be preferable to what is currently proposed:


diff --git src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
index a9ce7cee9a1..55783474c22 100644
--- src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
+++ src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
@@ -53,7 +53,6 @@ public class FileURLConnection extends URLConnection {
     File file;
     String filename;
     boolean isDirectory = false;
-    boolean exists = false;
     List<String> files;
 
     long length = -1;
@@ -93,16 +92,12 @@ public class FileURLConnection extends URLConnection {
     private boolean initializedHeaders = false;
 
     private void initializeHeaders() {
-        try {
-            connect();
-            exists = file.exists();
-        } catch (IOException e) {
-        }
-        if (!initializedHeaders || !exists) {
+        if (!initializedHeaders || !file.exists()) {
             length = file.length();
             lastModified = file.lastModified();
+            filename = file.toString();
 
-            if (!isDirectory) {
+            if (!file.isDirectory()) {
                 FileNameMap map = java.net.URLConnection.getFileNameMap();
                 contentType = map.getContentTypeFor(filename);
                 if (contentType != null) {
@@ -131,17 +126,17 @@ public class FileURLConnection extends URLConnection {
 
     public Map<String,List<String>> getHeaderFields() {
         initializeHeaders();
-        return super.getHeaderFields();
+        return properties.getHeaders();
     }
 
     public String getHeaderField(String name) {
         initializeHeaders();
-        return super.getHeaderField(name);
+        return properties.findValue(name);
     }
 
     public String getHeaderField(int n) {
         initializeHeaders();
-        return super.getHeaderField(n);
+        return properties.getKey(n);
     }
 
     public int getContentLength() {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200835975

From djelinski at openjdk.org  Mon May 22 17:50:52 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 22 May 2023 17:50:52 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v10]
In-Reply-To: <rS_6gYmzVWjfleYC7ltzsnmzAgDldg_4VDDuLjhVMOY=.cf912e6d-adac-45b5-82b0-7961edce8ad7@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <rS_6gYmzVWjfleYC7ltzsnmzAgDldg_4VDDuLjhVMOY=.cf912e6d-adac-45b5-82b0-7961edce8ad7@github.com>
Message-ID: <W-we6Z8_bUscA6WgirGHKz5T25aCZRBXjc_PPhqxp-4=.d692535f-039b-4f34-88e0-7fc0376e0b5e@github.com>

On Thu, 18 May 2023 10:02:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I would like to get preliminary feedback about the provided patch.
>> 
>> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
>> 
>> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
>> 
>> At the moment this cache can be configured by the application using the following two properties:
>>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
>> 
>> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
>> 
>> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
>> 
>> Possible solutions:
>>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
>> 
>> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
>> 
>> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
>> 
>> 
>> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
>> https://www.rfc-editor.org/rfc/rfc8767
>> 
>> Comments about current and other possible implementations:
>>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>>  * The refr...
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The negative value is ignored

src/java.base/share/classes/java/net/InetAddress.java line 224:

> 222:  * 30 seconds.
> 223:  * <p>
> 224:  * A value of 0 (zero) means do not use stale names, the negative value is

Should we be more specific here? As far as I could tell, negative values also disable caching.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1200839453

From duke at openjdk.org  Mon May 22 17:51:51 2023
From: duke at openjdk.org (Jesse Glick)
Date: Mon, 22 May 2023 17:51:51 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <Ff9qI39JwumYL0xlRRg_uQwbxMvsg6vx8HpxM6s1udU=.715b610d-5602-4c5f-9923-e2bbc4d62bb1@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
 <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
 <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>
 <RCvm4JC-fpoR7bqrLdf2biktwyxX-5O9g81vRt0xy-c=.294b8c10-8634-4ea3-8fdb-71c6d918fdd0@github.com>
 <sz1ARwkmgyKicdVlKsVG2sXOCBFZYDxshlAEBd0LbKs=.f224ac95-b35b-4f1d-964c-af1ed565fbf0@github.com>
 <V69l5WRMZbFoOlnOBDAFHmHGc7x1Q_Htci4keiJPAig=.486d53f5-0ed9-4f60-a4ee-04457df74ac6@github.com>
 <Ff9qI39JwumYL0xlRRg_uQwbxMvsg6vx8HpxM6s1udU=.715b610d-5602-4c5f-9923-e2bbc4d62bb1@github.com>
Message-ID: <cndcfh4TKzQCHXLTvxv5UZBnDNU59cSAfuXGlQ1bRhU=.6dba72c0-a0dd-47b9-a72f-d760df24d572@github.com>

On Mon, 22 May 2023 17:43:51 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> That seems like it could cause other issues down the road though. `FileURLConnection::connect` has this comment:
>> 
>> 
>>     /*
>>      * Note: the semantics of FileURLConnection object is that the
>>      * results of the various URLConnection calls, such as
>>      * getContentType, getInputStream or getContentLength reflect
>>      * whatever was true when connect was called.
>>      */
>>     public void connect() throws IOException {
>
> This patch appears to be work and may be preferable to what is currently proposed:
> 
> 
> diff --git src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
> index a9ce7cee9a1..55783474c22 100644
> --- src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
> +++ src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
> @@ -53,7 +53,6 @@ public class FileURLConnection extends URLConnection {
>      File file;
>      String filename;
>      boolean isDirectory = false;
> -    boolean exists = false;
>      List<String> files;
>  
>      long length = -1;
> @@ -93,16 +92,12 @@ public class FileURLConnection extends URLConnection {
>      private boolean initializedHeaders = false;
>  
>      private void initializeHeaders() {
> -        try {
> -            connect();
> -            exists = file.exists();
> -        } catch (IOException e) {
> -        }
> -        if (!initializedHeaders || !exists) {
> +        if (!initializedHeaders || !file.exists()) {
>              length = file.length();
>              lastModified = file.lastModified();
> +            filename = file.toString();
>  
> -            if (!isDirectory) {
> +            if (!file.isDirectory()) {
>                  FileNameMap map = java.net.URLConnection.getFileNameMap();
>                  contentType = map.getContentTypeFor(filename);
>                  if (contentType != null) {
> @@ -131,17 +126,17 @@ public class FileURLConnection extends URLConnection {
>  
>      public Map<String,List<String>> getHeaderFields() {
>          initializeHeaders();
> -        return super.getHeaderFields();
> +        return properties.getHeaders();
>      }
>  
>      public String getHeaderField(String name) {
>          initializeHeaders();
> -        return super.getHeaderField(name);
> +        return properties.findValue(name);
>      }
>  
>      public String getHeaderField(int n) {
>          initializeHeaders();
> -        return super.getHeaderField(n);
> +        return properties.getKey(n);
>      }
>  
>      public int getContentLength() {

> has this comment

Interesting. And yet that does not appear to be true in `master`: `getContentType` and `getContentLength` will return whatever was in effect at the time `initializeHeaders()` was first called, which may have been before any explicit call to `connect()`, or hours after an explicit call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200840711

From dfuchs at openjdk.org  Mon May 22 17:56:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 May 2023 17:56:51 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <cndcfh4TKzQCHXLTvxv5UZBnDNU59cSAfuXGlQ1bRhU=.6dba72c0-a0dd-47b9-a72f-d760df24d572@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
 <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
 <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>
 <RCvm4JC-fpoR7bqrLdf2biktwyxX-5O9g81vRt0xy-c=.294b8c10-8634-4ea3-8fdb-71c6d918fdd0@github.com>
 <sz1ARwkmgyKicdVlKsVG2sXOCBFZYDxshlAEBd0LbKs=.f224ac95-b35b-4f1d-964c-af1ed565fbf0@github.com>
 <V69l5WRMZbFoOlnOBDAFHmHGc7x1Q_Htci4keiJPAig=.486d53f5-0ed9-4f60-a4ee-04457df74ac6@github.com>
 <Ff9qI39JwumYL0xlRRg_uQwbxMvsg6vx8HpxM6s1udU=.715b610d-5602-4c5f-9923-e2bbc4d62bb1@github.com>
 <cndcfh4TKzQCHXLTvxv5UZBnDNU59cSAfuXGlQ1bRhU=.6dba72c0-a0dd-47b9-a72f-d760df24d572@github.com>
Message-ID: <qrrwzWfec6ldPPGIT-J_L1hKygXgAPil2bYuLO4HXoc=.afcf135f-7e20-4697-b9d0-9b7943dc5ecc@github.com>

On Mon, 22 May 2023 17:49:12 GMT, Jesse Glick <duke at openjdk.org> wrote:

>> This patch appears to be work and may be preferable to what is currently proposed:
>> 
>> 
>> diff --git src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>> index a9ce7cee9a1..55783474c22 100644
>> --- src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>> +++ src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>> @@ -53,7 +53,6 @@ public class FileURLConnection extends URLConnection {
>>      File file;
>>      String filename;
>>      boolean isDirectory = false;
>> -    boolean exists = false;
>>      List<String> files;
>>  
>>      long length = -1;
>> @@ -93,16 +92,12 @@ public class FileURLConnection extends URLConnection {
>>      private boolean initializedHeaders = false;
>>  
>>      private void initializeHeaders() {
>> -        try {
>> -            connect();
>> -            exists = file.exists();
>> -        } catch (IOException e) {
>> -        }
>> -        if (!initializedHeaders || !exists) {
>> +        if (!initializedHeaders || !file.exists()) {
>>              length = file.length();
>>              lastModified = file.lastModified();
>> +            filename = file.toString();
>>  
>> -            if (!isDirectory) {
>> +            if (!file.isDirectory()) {
>>                  FileNameMap map = java.net.URLConnection.getFileNameMap();
>>                  contentType = map.getContentTypeFor(filename);
>>                  if (contentType != null) {
>> @@ -131,17 +126,17 @@ public class FileURLConnection extends URLConnection {
>>  
>>      public Map<String,List<String>> getHeaderFields() {
>>          initializeHeaders();
>> -        return super.getHeaderFields();
>> +        return properties.getHeaders();
>>      }
>>  
>>      public String getHeaderField(String name) {
>>          initializeHeaders();
>> -        return super.getHeaderField(name);
>> +        return properties.findValue(name);
>>      }
>>  
>>      public String getHeaderField(int n) {
>>          initializeHeaders();
>> -        return super.getHeaderField(n);
>> +        return properties.getKey(n);
>>      }
>>  
>>      public int getContentLength() {
>
>> has this comment
> 
> Interesting. And yet that does not appear to be true in `master`: `getContentType` and `getContentLength` will return whatever was in effect at the time `initializeHeaders()` was first called, which may have been before any explicit call to `connect()`, or hours after an explicit call.

Ah! It's true only if the first time connect is called, it's implicitly by `initializeHeaders()` (sigh)...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200844827

From dfuchs at openjdk.org  Mon May 22 18:03:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 May 2023 18:03:51 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <qrrwzWfec6ldPPGIT-J_L1hKygXgAPil2bYuLO4HXoc=.afcf135f-7e20-4697-b9d0-9b7943dc5ecc@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
 <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
 <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>
 <RCvm4JC-fpoR7bqrLdf2biktwyxX-5O9g81vRt0xy-c=.294b8c10-8634-4ea3-8fdb-71c6d918fdd0@github.com>
 <sz1ARwkmgyKicdVlKsVG2sXOCBFZYDxshlAEBd0LbKs=.f224ac95-b35b-4f1d-964c-af1ed565fbf0@github.com>
 <V69l5WRMZbFoOlnOBDAFHmHGc7x1Q_Htci4keiJPAig=.486d53f5-0ed9-4f60-a4ee-04457df74ac6@github.com>
 <Ff9qI39JwumYL0xlRRg_uQwbxMvsg6vx8HpxM6s1udU=.715b610d-5602-4c5f-9923-e2bbc4d62bb1@github.com>
 <cndcfh4TKzQCHXLTvxv5UZBnDNU59cSAfuXGlQ1bRhU=.6dba72c0-a0dd-47b9-a72f-d760df24d572@github.com>
 <qrrwzWfec6ldPPGIT-J_L1hKygXgAPil2bY
 uLO4HXoc=.afcf135f-7e20-4697-b9d0-9b7943dc5ecc@github.com>
Message-ID: <KKyXuNgZPg0cGzCh1XcPcKuhSJ1fAm2WWdFlDscbNGA=.a7871386-5374-481d-b4f5-345e1b5cb7f7@github.com>

On Mon, 22 May 2023 17:54:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> has this comment
>> 
>> Interesting. And yet that does not appear to be true in `master`: `getContentType` and `getContentLength` will return whatever was in effect at the time `initializeHeaders()` was first called, which may have been before any explicit call to `connect()`, or hours after an explicit call.
>
> Ah! It's true only if the first time connect is called, it's implicitly by `initializeHeaders()` (sigh)...

@Michael-Mc-Mahon what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1200855748

From serb at openjdk.org  Mon May 22 18:54:06 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 22 May 2023 18:54:06 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v11]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <lUCyEJk_BJzBJvhDYgHPyuvuhGFp0YKC-uvhrZOlmVk=.944bc613-1df5-41ff-89e9-e0592a1c0259@github.com>

> I would like to get preliminary feedback about the provided patch.
> 
> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
> 
> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
> 
> At the moment this cache can be configured by the application using the following two properties:
>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
> 
> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
> 
> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
> 
> Possible solutions:
>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
> 
> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
> 
> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
> 
> 
> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
> https://www.rfc-editor.org/rfc/rfc8767
> 
> Comments about current and other possible implementations:
>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>  * The refresh timeout includes the time s...

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  if the property is not set means do not use stale names

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13285/files
  - new: https://git.openjdk.org/jdk/pull/13285/files/a856cd36..ce595f74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=09-10

  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

PR: https://git.openjdk.org/jdk/pull/13285

From serb at openjdk.org  Mon May 22 18:54:08 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 22 May 2023 18:54:08 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v10]
In-Reply-To: <W-we6Z8_bUscA6WgirGHKz5T25aCZRBXjc_PPhqxp-4=.d692535f-039b-4f34-88e0-7fc0376e0b5e@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <rS_6gYmzVWjfleYC7ltzsnmzAgDldg_4VDDuLjhVMOY=.cf912e6d-adac-45b5-82b0-7961edce8ad7@github.com>
 <W-we6Z8_bUscA6WgirGHKz5T25aCZRBXjc_PPhqxp-4=.d692535f-039b-4f34-88e0-7fc0376e0b5e@github.com>
Message-ID: <7oA8v-AyFV2Laq3gV98aZosPdpk8V-hNGFv-jDsPCxw=.b6dacdf1-bd0e-42de-aabf-d43af8e3f659@github.com>

On Mon, 22 May 2023 17:47:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The negative value is ignored
>
> src/java.base/share/classes/java/net/InetAddress.java line 224:
> 
>> 222:  * 30 seconds.
>> 223:  * <p>
>> 224:  * A value of 0 (zero) means do not use stale names, the negative value is
> 
> Should we be more specific here? As far as I could tell, negative values also disable caching.

I guess it is an accurate description since the negative value is ignored by the implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1200905756

From jpai at openjdk.org  Tue May 23 06:23:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 23 May 2023 06:23:48 GMT
Subject: RFR: 8308545: java/net/httpclient/ShutdownNow.java fails with
 "stream 1 cancelled"
In-Reply-To: <FBq83YlKyoQcf-VMgSpZMVfpzfv5hg4Cj5XQ5IWoocw=.1b2caee2-aa0f-420f-bd86-6def72d75b49@github.com>
References: <FBq83YlKyoQcf-VMgSpZMVfpzfv5hg4Cj5XQ5IWoocw=.1b2caee2-aa0f-420f-bd86-6def72d75b49@github.com>
Message-ID: <th0mmgN5n3CTnai9Ixl-KjXm9I2bIkjKzcfYR1_AQlo=.3941c6a5-f906-403a-b0fb-e53ba0377a7a@github.com>

On Mon, 22 May 2023 12:52:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The test `test/jdk/java/net/httpclient/ShutdownNow.java` has been observed failing intermittently (though rarely) with an assertion error: `java.lang.AssertionError: 0: Unexpected exception: java.io.IOException: Stream 1 cancelled` caused by  
> 
> 
> java.io.IOException: Stream 1 cancelled
> at java.net.http/jdk.internal.net.http.Stream.cancel(Stream.java:1285) 
> 
> 
> Given the nature of the test - which interrupts / cancel all operations asynchronously, then a "stream %d cancelled" exception should count as an acceptable result.

The change looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14081#pullrequestreview-1438673832

From jpai at openjdk.org  Tue May 23 07:27:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 23 May 2023 07:27:52 GMT
Subject: RFR: 8308565: HttpClient: Sanitize logging while stopping
In-Reply-To: <VzQi0WRwmdVHhiXpyp8-N260r78PKSJ7gebVq-S6RlA=.5a15c4a5-e6f3-48d3-b3f2-c258a8e6cf82@github.com>
References: <VzQi0WRwmdVHhiXpyp8-N260r78PKSJ7gebVq-S6RlA=.5a15c4a5-e6f3-48d3-b3f2-c258a8e6cf82@github.com>
Message-ID: <Gg7-FHxPAEoSyUduGIGyzNJ-UDk5LkgF3PaIwfHizws=.31887f6d-b71f-44a1-ab25-e311d683e3fa@github.com>

On Mon, 22 May 2023 15:45:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> When the HttpClient is stopping many exception stack traces may be logged, in particular if the Http2Connection attempts to send a GOAWAY frame after the underlying TCP connection or the selector have been closed.
> 
> The Http2Connection should look at the Http2ClientImpl state before logging the exception as an error. If the Http2ClientImpl is stopping, a simple debug message should be enough.

These changes look good to me. Good to see that this can improve the situation where there logs would contain distracting exception stacktraces when the client was already shutting down.

src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 296:

> 294:     }
> 295: 
> 296:     public boolean stopping() {

Hello Daniel, I think this can be package private, but it's also OK if you want to keep it this way (this class is anyway an internal class in the `java.net.http` module)

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14089#pullrequestreview-1438842533
PR Review Comment: https://git.openjdk.org/jdk/pull/14089#discussion_r1201670807

From dfuchs at openjdk.org  Tue May 23 15:11:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 23 May 2023 15:11:10 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into HttpClient-Logging-8308310
 - Merge branch 'master' into HttpClient-Logging-8308310
 - Fix whitespace
 - make stateLock final
 - Add debug traces to ExpectContinueTest.java
 - failedRef should be final
 - Align parameters
 - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2

-------------

Changes: https://git.openjdk.org/jdk/pull/14038/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=07
  Stats: 891 lines in 32 files changed: 519 ins; 113 del; 259 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

PR: https://git.openjdk.org/jdk/pull/14038

From michaelm at openjdk.org  Tue May 23 15:11:22 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 23 May 2023 15:11:22 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters
Message-ID: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>

This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.

This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).

-------------

Commit messages:
 - test update
 - Merge branch 'master' into nullStrings
 - exception message update
 - test update
 - remve whitespace
 - update
 - Merge branch 'master' into nullStrings
 - first impl

Changes: https://git.openjdk.org/jdk/pull/14083/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14083&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300038
  Stats: 183 lines in 9 files changed: 163 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/14083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14083/head:pull/14083

PR: https://git.openjdk.org/jdk/pull/14083

From dfuchs at openjdk.org  Tue May 23 15:18:47 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 23 May 2023 15:18:47 GMT
Subject: Integrated: 8308545: java/net/httpclient/ShutdownNow.java fails with
 "stream 1 cancelled"
In-Reply-To: <FBq83YlKyoQcf-VMgSpZMVfpzfv5hg4Cj5XQ5IWoocw=.1b2caee2-aa0f-420f-bd86-6def72d75b49@github.com>
References: <FBq83YlKyoQcf-VMgSpZMVfpzfv5hg4Cj5XQ5IWoocw=.1b2caee2-aa0f-420f-bd86-6def72d75b49@github.com>
Message-ID: <xnPDkV74KNezkZOfhcMRAqhVLDzSBRp_WPN_2mNgi04=.ba509e14-0d4d-4ef0-a7ad-4565e6801f64@github.com>

On Mon, 22 May 2023 12:52:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The test `test/jdk/java/net/httpclient/ShutdownNow.java` has been observed failing intermittently (though rarely) with an assertion error: `java.lang.AssertionError: 0: Unexpected exception: java.io.IOException: Stream 1 cancelled` caused by  
> 
> 
> java.io.IOException: Stream 1 cancelled
> at java.net.http/jdk.internal.net.http.Stream.cancel(Stream.java:1285) 
> 
> 
> Given the nature of the test - which interrupts / cancel all operations asynchronously, then a "stream %d cancelled" exception should count as an acceptable result.

This pull request has now been integrated.

Changeset: 582ddeb2
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/582ddeb2b24f77307b89befc8c643290e0ed1b11
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8308545: java/net/httpclient/ShutdownNow.java fails with "stream 1 cancelled"

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14081

From dfuchs at openjdk.org  Tue May 23 15:18:53 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 23 May 2023 15:18:53 GMT
Subject: Integrated: 8308565: HttpClient: Sanitize logging while stopping
In-Reply-To: <VzQi0WRwmdVHhiXpyp8-N260r78PKSJ7gebVq-S6RlA=.5a15c4a5-e6f3-48d3-b3f2-c258a8e6cf82@github.com>
References: <VzQi0WRwmdVHhiXpyp8-N260r78PKSJ7gebVq-S6RlA=.5a15c4a5-e6f3-48d3-b3f2-c258a8e6cf82@github.com>
Message-ID: <SppxqdZH3RAMV-h-wqrAeFTUkRPfmI4m2nva4hXrNfk=.3dff382f-9500-45ad-953f-772bd10f5151@github.com>

On Mon, 22 May 2023 15:45:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> When the HttpClient is stopping many exception stack traces may be logged, in particular if the Http2Connection attempts to send a GOAWAY frame after the underlying TCP connection or the selector have been closed.
> 
> The Http2Connection should look at the Http2ClientImpl state before logging the exception as an error. If the Http2ClientImpl is stopping, a simple debug message should be enough.

This pull request has now been integrated.

Changeset: 9e196b36
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e196b3631af0156ce9958a2f631894968211a4c
Stats:     31 lines in 2 files changed: 25 ins; 1 del; 5 mod

8308565: HttpClient: Sanitize logging while stopping

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14089

From michaelm at openjdk.org  Tue May 23 15:31:49 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 23 May 2023 15:31:49 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v2]
In-Reply-To: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
Message-ID: <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>

> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
> 
> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  test comment update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14083/files
  - new: https://git.openjdk.org/jdk/pull/14083/files/8cf24635..0acc456a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14083&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14083&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14083/head:pull/14083

PR: https://git.openjdk.org/jdk/pull/14083

From dfuchs at openjdk.org  Tue May 23 15:31:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 23 May 2023 15:31:51 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v2]
In-Reply-To: <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
Message-ID: <srVILxcHJG1Yqnijz7VPoFC0UqUcvmts6eW_H1MqTGE=.f7fdee42-c681-42e1-b0f1-b3652229f554@github.com>

On Tue, 23 May 2023 15:18:36 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
>> 
>> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test comment update

test/jdk/java/net/InetAddress/NullCharDriver.java line 29:

> 27:  * @modules java.base/java.net
> 28:  * @compile/module=java.base java/net/NullChar.java
> 29:  * @summary foo

It would be good to have a better summary ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14083#discussion_r1202541587

From dfuchs at openjdk.org  Tue May 23 15:34:35 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 23 May 2023 15:34:35 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v2]
In-Reply-To: <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
Message-ID: <jmMenM59kPNjhv1hv630a4EuZOPU8D-wl15W08xD0kg=.81c28b6e-3a62-4f44-b3e5-6152d6f0454f@github.com>

On Tue, 23 May 2023 15:31:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
>> 
>> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test comment update

Looks good to me, but it would be good to get this reviewed by someone with more knowledge of native character encoding.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14083#pullrequestreview-1439991999

From naoto at openjdk.org  Tue May 23 16:21:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 May 2023 16:21:13 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v2]
In-Reply-To: <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
Message-ID: <5RK9fi9ix0bascOnml6sfEGvW2TrGRloVJ-ToEVly2I=.9630d5ad-0344-4127-b5bc-a82c05ba3b71@github.com>

On Tue, 23 May 2023 15:31:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
>> 
>> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test comment update

Looks good

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14083#pullrequestreview-1440123393

From michaelm at openjdk.org  Wed May 24 10:14:23 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 24 May 2023 10:14:23 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v3]
In-Reply-To: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
Message-ID: <uGGlsyDavyKXLuI-Ok4tj1iDR7oJ8ZqFRzM1V8wWH7o=.74d82f35-33e4-4ada-a3b5-f90307125344@github.com>

> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
> 
> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into nullStrings
 - test comment update
 - test update
 - Merge branch 'master' into nullStrings
 - exception message update
 - test update
 - remve whitespace
 - update
 - Merge branch 'master' into nullStrings
 - first impl

-------------

Changes: https://git.openjdk.org/jdk/pull/14083/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14083&range=02
  Stats: 183 lines in 9 files changed: 163 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/14083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14083/head:pull/14083

PR: https://git.openjdk.org/jdk/pull/14083

From jpai at openjdk.org  Wed May 24 10:37:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 10:37:59 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
Message-ID: <emAkYg9RM1jRpPRsvtuOoR31GxEEgGWnh7EWLm654mY=.1d6dbbb0-57f6-422c-a197-164cbda8db36@github.com>

On Tue, 23 May 2023 15:11:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Fix whitespace
>  - make stateLock final
>  - Add debug traces to ExpectContinueTest.java
>  - failedRef should be final
>  - Align parameters
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2

src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java line 476:

> 474:         }
> 475: 
> 476:         // should only be called while holding the ConnectionPool stateLock.

Hello Daniel, all these methods which say a lock needs to be held when they are called, should we add a `assert stateLock.isHeldByCurrentThread();` to make it verifiable? I understand we didn't have a similar assert when the comment said the method needs to be called while holding the monitor, but since we are changing this part now, perhaps we can add those asserts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203869893

From jpai at openjdk.org  Wed May 24 10:46:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 10:46:59 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
Message-ID: <v8aBN7Lm_RcI4rk-W23PdptnXITVHeVqmQP2E_zh2fc=.9c681505-0dfb-465b-9911-d2f2e2e7b303@github.com>

On Tue, 23 May 2023 15:11:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Fix whitespace
>  - make stateLock final
>  - Add debug traces to ExpectContinueTest.java
>  - failedRef should be final
>  - Align parameters
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2

src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java line 354:

> 352:                         lock.lock();
> 353:                         try {
> 354:                             state = State.HEADERS;

Can this code be replaced by a call to `switchState(...)` to be consistent with the rest of the places in this class which do a similar call?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203878587

From dfuchs at openjdk.org  Wed May 24 11:02:00 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 11:02:00 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <emAkYg9RM1jRpPRsvtuOoR31GxEEgGWnh7EWLm654mY=.1d6dbbb0-57f6-422c-a197-164cbda8db36@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
 <emAkYg9RM1jRpPRsvtuOoR31GxEEgGWnh7EWLm654mY=.1d6dbbb0-57f6-422c-a197-164cbda8db36@github.com>
Message-ID: <OIYMOqKekVpPj9C4P5MA5O9GJl6XLdeVx29OoM4CihQ=.f7cc4d59-aebd-48b8-a413-94724c2af475@github.com>

On Wed, 24 May 2023 10:35:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Fix whitespace
>>  - make stateLock final
>>  - Add debug traces to ExpectContinueTest.java
>>  - failedRef should be final
>>  - Align parameters
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2
>
> src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java line 476:
> 
>> 474:         }
>> 475: 
>> 476:         // should only be called while holding the ConnectionPool stateLock.
> 
> Hello Daniel, all these methods which say a lock needs to be held when they are called, should we add a `assert stateLock.isHeldByCurrentThread();` to make it verifiable? I understand we didn't have a similar assert when the comment said the method needs to be called while holding the monitor, but since we are changing this part now, perhaps we can add those asserts?

The `stateLock` variable is not available from within the method:

Non-static field 'stateLock' cannot be referenced from a static context

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203899099

From jpai at openjdk.org  Wed May 24 11:02:04 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 11:02:04 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
Message-ID: <mkkR2tj3uSQmNa8sr58yAYuEJG4iOUD7kL1lB3Ad-FI=.f3c0bd80-231e-4366-a3dd-8749bf26d456@github.com>

On Tue, 23 May 2023 15:11:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Fix whitespace
>  - make stateLock final
>  - Add debug traces to ExpectContinueTest.java
>  - failedRef should be final
>  - Align parameters
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 150:

> 148: 
> 149:         public void tryRelease() {
> 150:             if (STATE.compareAndSet(this, (byte)0x01, (byte)0x03)) {

Nit - a space is missing between the cast and the value for the second and third parameters.

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 158:

> 156:                     debug.log("ref count for %s already released", client);
> 157:             }
> 158:             state |= 0x02;

It looks like previously (before the changes in this PR), the `tryRelease` could incorrectly set this `state` to `0x02` even when the `state` was `0`. From what I see in this change, that seems to have been addressed now.

src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 323:

> 321:     private void unlock() {
> 322:         lock.unlock();
> 323:     }

Any specific reason for creating private wrapper methods instead of just using `lock.lock()` and `lock.unlock()` at the call sites?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203894064
PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203892337
PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203896133

From dfuchs at openjdk.org  Wed May 24 11:08:04 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 11:08:04 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <mkkR2tj3uSQmNa8sr58yAYuEJG4iOUD7kL1lB3Ad-FI=.f3c0bd80-231e-4366-a3dd-8749bf26d456@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
 <mkkR2tj3uSQmNa8sr58yAYuEJG4iOUD7kL1lB3Ad-FI=.f3c0bd80-231e-4366-a3dd-8749bf26d456@github.com>
Message-ID: <f3gWNqCPR-Nft67uzCHWpWa7WKSLRuCmltYO5_x9OoQ=.31df5041-9afd-4700-b22c-518d8ea4e37b@github.com>

On Wed, 24 May 2023 10:55:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Fix whitespace
>>  - make stateLock final
>>  - Add debug traces to ExpectContinueTest.java
>>  - failedRef should be final
>>  - Align parameters
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 150:
> 
>> 148: 
>> 149:         public void tryRelease() {
>> 150:             if (STATE.compareAndSet(this, (byte)0x01, (byte)0x03)) {
> 
> Nit - a space is missing between the cast and the value for the second and third parameters.

OK - will do - though I usually don't put a space there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203905137

From jpai at openjdk.org  Wed May 24 11:08:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 11:08:08 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
Message-ID: <Mv6X9hRsvy550MnwuUXQPE1xmULJG0ytU7Dge40HjMU=.6cafe846-fbca-4e91-ac9d-ce1a4fbfc2e4@github.com>

On Tue, 23 May 2023 15:11:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Fix whitespace
>  - make stateLock final
>  - Add debug traces to ExpectContinueTest.java
>  - failedRef should be final
>  - Align parameters
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 579:

> 577:         stateLock.lock();
> 578:         try {
> 579:             return finalStream;

Perhaps we can make `finalStream` volatile and remove the use of locks when accessing and setting it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203907147

From jpai at openjdk.org  Wed May 24 11:14:02 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 11:14:02 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <OIYMOqKekVpPj9C4P5MA5O9GJl6XLdeVx29OoM4CihQ=.f7cc4d59-aebd-48b8-a413-94724c2af475@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
 <emAkYg9RM1jRpPRsvtuOoR31GxEEgGWnh7EWLm654mY=.1d6dbbb0-57f6-422c-a197-164cbda8db36@github.com>
 <OIYMOqKekVpPj9C4P5MA5O9GJl6XLdeVx29OoM4CihQ=.f7cc4d59-aebd-48b8-a413-94724c2af475@github.com>
Message-ID: <juwGx9ESovaqijfEtwU9-4sdBlUc6ve5QgAKKAVxg_M=.2dd3985c-1953-42fb-a879-12643c7d8be0@github.com>

On Wed, 24 May 2023 10:59:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java line 476:
>> 
>>> 474:         }
>>> 475: 
>>> 476:         // should only be called while holding the ConnectionPool stateLock.
>> 
>> Hello Daniel, all these methods which say a lock needs to be held when they are called, should we add a `assert stateLock.isHeldByCurrentThread();` to make it verifiable? I understand we didn't have a similar assert when the comment said the method needs to be called while holding the monitor, but since we are changing this part now, perhaps we can add those asserts?
>
> The `stateLock` variable is not available from within the method:
> 
> Non-static field 'stateLock' cannot be referenced from a static context

Thank you, that wasn't clearly noticable in the diff.

>> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 150:
>> 
>>> 148: 
>>> 149:         public void tryRelease() {
>>> 150:             if (STATE.compareAndSet(this, (byte)0x01, (byte)0x03)) {
>> 
>> Nit - a space is missing between the cast and the value for the second and third parameters.
>
> OK - will do - though I usually don't put a space there.

It's fine with me in the current form if this wasn't an oversight.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203912652
PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203918122

From dfuchs at openjdk.org  Wed May 24 11:14:06 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 11:14:06 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <mkkR2tj3uSQmNa8sr58yAYuEJG4iOUD7kL1lB3Ad-FI=.f3c0bd80-231e-4366-a3dd-8749bf26d456@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
 <mkkR2tj3uSQmNa8sr58yAYuEJG4iOUD7kL1lB3Ad-FI=.f3c0bd80-231e-4366-a3dd-8749bf26d456@github.com>
Message-ID: <xEmnpWR7s4Ma3s3llhdvgpR97o_6SSN0EFqlPG2O54c=.f9a4ac85-b34f-4f0a-a28b-e2383086717d@github.com>

On Wed, 24 May 2023 10:56:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Fix whitespace
>>  - make stateLock final
>>  - Add debug traces to ExpectContinueTest.java
>>  - failedRef should be final
>>  - Align parameters
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java line 323:
> 
>> 321:     private void unlock() {
>> 322:         lock.unlock();
>> 323:     }
> 
> Any specific reason for creating private wrapper methods instead of just using `lock.lock()` and `lock.unlock()` at the call sites?

removed private methods

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203917592

From dfuchs at openjdk.org  Wed May 24 11:17:02 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 11:17:02 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <Mv6X9hRsvy550MnwuUXQPE1xmULJG0ytU7Dge40HjMU=.6cafe846-fbca-4e91-ac9d-ce1a4fbfc2e4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
 <Mv6X9hRsvy550MnwuUXQPE1xmULJG0ytU7Dge40HjMU=.6cafe846-fbca-4e91-ac9d-ce1a4fbfc2e4@github.com>
Message-ID: <O3sLXB3yP-0lV9lD_uwm-mfh25ETYk62gQkhqYFJS3M=.27ec98d3-c578-43a1-9173-dd08a74b6acd@github.com>

On Wed, 24 May 2023 11:05:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Fix whitespace
>>  - make stateLock final
>>  - Add debug traces to ExpectContinueTest.java
>>  - failedRef should be final
>>  - Align parameters
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 579:
> 
>> 577:         stateLock.lock();
>> 578:         try {
>> 579:             return finalStream;
> 
> Perhaps we can make `finalStream` volatile and remove the use of locks when accessing and setting it?

Looks doable

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203921984

From jpai at openjdk.org  Wed May 24 11:24:06 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 11:24:06 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
Message-ID: <r7qYRCaqQEsmj-SosCgXOMiVeqQAs6kvf6OBBsN1Mk4=.f9166cb5-ea3c-42a6-946b-4f03c239827e@github.com>

On Tue, 23 May 2023 15:11:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Fix whitespace
>  - make stateLock final
>  - Add debug traces to ExpectContinueTest.java
>  - failedRef should be final
>  - Align parameters
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2

src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 218:

> 216:         synchronized (this) {
> 217:             previousExchange = this.exchange;
> 218:             this.exchange = exchange;

There's a behavioural change here as compared to before this change. Previously, we used to first call `released()` on the old exchange and `cancel()` the new exchange, before setting the `this.exchange` to the new exchange. Now, with this change, we first switch the `this.exchange` to the new exchange and then call `released()` and `cancel()`. Do you think that could have any (odd) issues?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203930954

From dfuchs at openjdk.org  Wed May 24 11:34:02 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 11:34:02 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <r7qYRCaqQEsmj-SosCgXOMiVeqQAs6kvf6OBBsN1Mk4=.f9166cb5-ea3c-42a6-946b-4f03c239827e@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
 <r7qYRCaqQEsmj-SosCgXOMiVeqQAs6kvf6OBBsN1Mk4=.f9166cb5-ea3c-42a6-946b-4f03c239827e@github.com>
Message-ID: <L5xmcEdS3gKXjenTusexlobnPtt1EdMvmObnH9D1ynQ=.a08609f4-57ac-420a-9db7-bc7773943b9d@github.com>

On Wed, 24 May 2023 11:20:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Fix whitespace
>>  - make stateLock final
>>  - Add debug traces to ExpectContinueTest.java
>>  - failedRef should be final
>>  - Align parameters
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2
>
> src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 218:
> 
>> 216:         synchronized (this) {
>> 217:             previousExchange = this.exchange;
>> 218:             this.exchange = exchange;
> 
> There's a behavioural change here as compared to before this change. Previously, we used to first call `released()` on the old exchange and `cancel()` the new exchange, before setting the `this.exchange` to the new exchange. Now, with this change, we first switch the `this.exchange` to the new exchange and then call `released()` and `cancel()`. Do you think that could have any (odd) issues?

Good observation. When we reach here the previous exchange is practically terminated. Looking at the implementation of released(), and at the place where `setExchange` is called, I don't think it matters.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203945286

From dfuchs at openjdk.org  Wed May 24 11:39:26 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 11:39:26 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v9]
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <Q5t_hs0-UdGEOsJhCTpdeRId18Zsh23-VFOxkzkTjuQ=.3e202841-fcae-43b0-af2f-4d281c9af256@github.com>

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14038/files
  - new: https://git.openjdk.org/jdk/pull/14038/files/c5d2f1f2..f5986f93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=07-08

  Stats: 40 lines in 4 files changed: 0 ins; 23 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

PR: https://git.openjdk.org/jdk/pull/14038

From jpai at openjdk.org  Wed May 24 11:44:00 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 11:44:00 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
Message-ID: <uhIQsR39FSVLiU_4wTHtBGuODjOOFE2Zs34TvCGK4zY=.dc186c97-3372-4f84-97dc-fa09dfeab01b@github.com>

On Tue, 23 May 2023 15:11:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Fix whitespace
>  - make stateLock final
>  - Add debug traces to ExpectContinueTest.java
>  - failedRef should be final
>  - Align parameters
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2

test/jdk/java/net/httpclient/ConcurrentResponses.java line 182:

> 180:                 .join();
> 181:         client.close();
> 182:         virtualExecutor.close();

Could we do this in a try/finally block? Same for the other test method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203957739

From jpai at openjdk.org  Wed May 24 11:51:01 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 11:51:01 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
Message-ID: <Jlcvd4XMruU9rplCVEZhm78TLfheN6KTO-l9Kxh2a6I=.b5599ebd-5a8e-43b9-a5b3-7d00cef4a9af@github.com>

On Tue, 23 May 2023 15:11:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Merge branch 'master' into HttpClient-Logging-8308310
>  - Fix whitespace
>  - make stateLock final
>  - Add debug traces to ExpectContinueTest.java
>  - failedRef should be final
>  - Align parameters
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2

test/jdk/java/net/httpclient/ManyRequests.java line 274:

> 272:             } catch (CompletionException e) {
> 273:                 if (!Platform.isWindows()) throw e;
> 274:                 if (LIMIT.get() < MAX_LIMIT) throw e;

Previously, `LIMIT.get()` was being compared against `MAX_COUNT`, because `REQUEST` was initialized (as `final`) to that value. Now it's being compared to `MAX_LIMIT`. Is this intentional?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203967858

From jpai at openjdk.org  Wed May 24 11:55:57 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 11:55:57 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v9]
In-Reply-To: <Q5t_hs0-UdGEOsJhCTpdeRId18Zsh23-VFOxkzkTjuQ=.3e202841-fcae-43b0-af2f-4d281c9af256@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <Q5t_hs0-UdGEOsJhCTpdeRId18Zsh23-VFOxkzkTjuQ=.3e202841-fcae-43b0-af2f-4d281c9af256@github.com>
Message-ID: <O1mcEzXZXXeXIUk06Mlhj5hjQ1z4Bz9zltgqrYiHDwQ=.64344b5c-4ad7-40fd-bda3-1ab9693f8fc7@github.com>

On Wed, 24 May 2023 11:39:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

The tests that have been selectively changed to use virtual threads for the HttpClient (and have been  set with `-Djdk.tracePinnedThreads=full`), I'm guessing were selected based on some of the failures that were noticed when virtual threads were used?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14038#issuecomment-1560975920

From jpai at openjdk.org  Wed May 24 11:55:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 11:55:59 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <L5xmcEdS3gKXjenTusexlobnPtt1EdMvmObnH9D1ynQ=.a08609f4-57ac-420a-9db7-bc7773943b9d@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
 <r7qYRCaqQEsmj-SosCgXOMiVeqQAs6kvf6OBBsN1Mk4=.f9166cb5-ea3c-42a6-946b-4f03c239827e@github.com>
 <L5xmcEdS3gKXjenTusexlobnPtt1EdMvmObnH9D1ynQ=.a08609f4-57ac-420a-9db7-bc7773943b9d@github.com>
Message-ID: <TJzpxfFC7e_lBOy2uldg0nazHfnHrdJxlPruz1ASDQ0=.b856660c-71de-4ff8-8d18-d6983cd1cd5c@github.com>

On Wed, 24 May 2023 11:31:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 218:
>> 
>>> 216:         synchronized (this) {
>>> 217:             previousExchange = this.exchange;
>>> 218:             this.exchange = exchange;
>> 
>> There's a behavioural change here as compared to before this change. Previously, we used to first call `released()` on the old exchange and `cancel()` the new exchange, before setting the `this.exchange` to the new exchange. Now, with this change, we first switch the `this.exchange` to the new exchange and then call `released()` and `cancel()`. Do you think that could have any (odd) issues?
>
> Good observation. When we reach here the previous exchange is practically terminated. Looking at the implementation of released(), and at the place where `setExchange` is called, I don't think it matters.

Thank you Daniel for checking.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1203977099

From dfuchs at openjdk.org  Wed May 24 12:37:58 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 12:37:58 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <Jlcvd4XMruU9rplCVEZhm78TLfheN6KTO-l9Kxh2a6I=.b5599ebd-5a8e-43b9-a5b3-7d00cef4a9af@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
 <Jlcvd4XMruU9rplCVEZhm78TLfheN6KTO-l9Kxh2a6I=.b5599ebd-5a8e-43b9-a5b3-7d00cef4a9af@github.com>
Message-ID: <OQ9_DpK9RhLQX4r2aZXn8tuT1pgxXjsiqbzWme3ILoI=.dc8f9656-0c5e-4541-aa3e-af2dff4fae8d@github.com>

On Wed, 24 May 2023 11:48:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Fix whitespace
>>  - make stateLock final
>>  - Add debug traces to ExpectContinueTest.java
>>  - failedRef should be final
>>  - Align parameters
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2
>
> test/jdk/java/net/httpclient/ManyRequests.java line 274:
> 
>> 272:             } catch (CompletionException e) {
>> 273:                 if (!Platform.isWindows()) throw e;
>> 274:                 if (LIMIT.get() < MAX_LIMIT) throw e;
> 
> Previously, `LIMIT.get()` was being compared against `MAX_COUNT`, because `REQUEST` was initialized (as `final`) to that value. Now it's being compared to `MAX_LIMIT`. Is this intentional?

Yes. I think the previous behaviour was buggy. The idea is to reduce concurrency if the underlying OS has trouble with too many concurrent connections.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1204046449

From dfuchs at openjdk.org  Wed May 24 12:42:07 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 12:42:07 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <OQ9_DpK9RhLQX4r2aZXn8tuT1pgxXjsiqbzWme3ILoI=.dc8f9656-0c5e-4541-aa3e-af2dff4fae8d@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
 <Jlcvd4XMruU9rplCVEZhm78TLfheN6KTO-l9Kxh2a6I=.b5599ebd-5a8e-43b9-a5b3-7d00cef4a9af@github.com>
 <OQ9_DpK9RhLQX4r2aZXn8tuT1pgxXjsiqbzWme3ILoI=.dc8f9656-0c5e-4541-aa3e-af2dff4fae8d@github.com>
Message-ID: <HpC62K0IwPvUUZJguxn6fMyE9SVASct7Y28wugk11Rw=.735595aa-5c71-453c-89b5-146442806d38@github.com>

On Wed, 24 May 2023 12:35:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/ManyRequests.java line 274:
>> 
>>> 272:             } catch (CompletionException e) {
>>> 273:                 if (!Platform.isWindows()) throw e;
>>> 274:                 if (LIMIT.get() < MAX_LIMIT) throw e;
>> 
>> Previously, `LIMIT.get()` was being compared against `MAX_COUNT`, because `REQUEST` was initialized (as `final`) to that value. Now it's being compared to `MAX_LIMIT`. Is this intentional?
>
> Yes. I think the previous behaviour was buggy. The idea is to reduce concurrency if the underlying OS has trouble with too many concurrent connections.

What it says here is that if we already reduced the LIMIT once and it fails again we should fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1204053958

From dfuchs at openjdk.org  Wed May 24 12:49:05 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 12:49:05 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v9]
In-Reply-To: <O1mcEzXZXXeXIUk06Mlhj5hjQ1z4Bz9zltgqrYiHDwQ=.64344b5c-4ad7-40fd-bda3-1ab9693f8fc7@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <Q5t_hs0-UdGEOsJhCTpdeRId18Zsh23-VFOxkzkTjuQ=.3e202841-fcae-43b0-af2f-4d281c9af256@github.com>
 <O1mcEzXZXXeXIUk06Mlhj5hjQ1z4Bz9zltgqrYiHDwQ=.64344b5c-4ad7-40fd-bda3-1ab9693f8fc7@github.com>
Message-ID: <vFOKgnogbYSaMg6EakRVjPdV4e59HUFhWDI6M9HoMQI=.924a6a1c-0740-4c29-b544-8f88d4a329f6@github.com>

On Wed, 24 May 2023 11:51:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The tests that have been selectively changed to use virtual threads for the HttpClient (and have been set with -Djdk.tracePinnedThreads=full), I'm guessing were selected based on some of the failures that were noticed when virtual threads were used?

Yes - these were the bigger offenders causing virtual threads to get pinned.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14038#issuecomment-1561076460

From dfuchs at openjdk.org  Wed May 24 13:01:31 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 13:01:31 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v10]
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <f9xbCgPoobBjzi3p0qwUL4pPk2v8Q4wF0uJNzUF6WyQ=.62330ad6-5716-47ff-8d5c-a37a4d736145@github.com>

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  More review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14038/files
  - new: https://git.openjdk.org/jdk/pull/14038/files/f5986f93..0f34be9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14038&range=08-09

  Stats: 69 lines in 1 file changed: 31 ins; 26 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/14038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14038/head:pull/14038

PR: https://git.openjdk.org/jdk/pull/14038

From jpai at openjdk.org  Wed May 24 13:15:02 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 13:15:02 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v9]
In-Reply-To: <Q5t_hs0-UdGEOsJhCTpdeRId18Zsh23-VFOxkzkTjuQ=.3e202841-fcae-43b0-af2f-4d281c9af256@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <Q5t_hs0-UdGEOsJhCTpdeRId18Zsh23-VFOxkzkTjuQ=.3e202841-fcae-43b0-af2f-4d281c9af256@github.com>
Message-ID: <nZGscTpc5eRXkJXnF-NIMC4fTGxtW3uArucoxScgx84=.d8c92fac-ef3a-4b1f-af49-db29a73b9674@github.com>

On Wed, 24 May 2023 11:39:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

The latest changes in `f5986f93` look fine to me. There's just one suggestion that's remaining in the `ConcurrentResponses` test about moving the closing of the client and virtual thread executor in a finally block, but other than that this looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14038#pullrequestreview-1441771566

From dfuchs at openjdk.org  Wed May 24 13:15:07 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 13:15:07 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v8]
In-Reply-To: <uhIQsR39FSVLiU_4wTHtBGuODjOOFE2Zs34TvCGK4zY=.dc186c97-3372-4f84-97dc-fa09dfeab01b@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <diHP20FD0GtB2ZHT8iP9Kqi5RU9HSHFOQwxD98jXeSQ=.374d237f-a948-48bb-b9e5-a320eec72e98@github.com>
 <uhIQsR39FSVLiU_4wTHtBGuODjOOFE2Zs34TvCGK4zY=.dc186c97-3372-4f84-97dc-fa09dfeab01b@github.com>
Message-ID: <ocdTYiuZZuEcZ7OoX2PuVGsXhTTPdNKA4hh5kWXM7JM=.fe81409e-fc0a-41d7-9124-5174a580bb43@github.com>

On Wed, 24 May 2023 11:40:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Merge branch 'master' into HttpClient-Logging-8308310
>>  - Fix whitespace
>>  - make stateLock final
>>  - Add debug traces to ExpectContinueTest.java
>>  - failedRef should be final
>>  - Align parameters
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2
>
> test/jdk/java/net/httpclient/ConcurrentResponses.java line 182:
> 
>> 180:                 .join();
>> 181:         client.close();
>> 182:         virtualExecutor.close();
> 
> Could we do this in a try/finally block? Same for the other test method.

Done. Note that I avoided try-with-resource in order to ensure that the client would be closed first.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1204108668

From dfuchs at openjdk.org  Wed May 24 13:25:57 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 13:25:57 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance [v2]
In-Reply-To: <UvKB0YQgyBfdj_yUzclD3q916l37O-U4icvfwP7j9Mc=.e8262f3e-9b26-4940-9ed4-7ea4fc4762d3@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
 <UvKB0YQgyBfdj_yUzclD3q916l37O-U4icvfwP7j9Mc=.e8262f3e-9b26-4940-9ed4-7ea4fc4762d3@github.com>
Message-ID: <fIT3w7Xnwa7pgOQEoBxBedO8F-xMWe9LRSQa_HA3XFk=.1325e839-fe81-475f-bd07-db7d9d6b1bed@github.com>

On Thu, 4 May 2023 20:31:32 GMT, Dhamoder Nalla <duke at openjdk.org> wrote:

>> Issue 8305763 : Using underscores in the name for a URI triggers a silent exception in the java standard library, which consumes 5% of the CPU.
>> 
>> Exception:
>> java.net.URISyntaxException: Illegal character in hostname at index N: xyz1_abcd.com
>>     at java.base/java.net.URI$Parser.fail(URI.java:2943)
>>     at java.base/java.net.URI$Parser.parseHostname(URI.java:3487)
>>     at java.base/java.net.URI$Parser.parseServer(URI.java:3329)
>>     
>>     This exception is silent and does not produce any messages, except for ODP profiler, there is no other evidence that it?s happening (the stack trace above was printed after changes to Java library). The reason for this is because of how the URI creation is implemented in the java.net.URI class. There are two paths for creating a valid URI, and one of them goes through an exception.
>> 
>> We can see that if parseServer fails, there is still a way the authority gets assigned and we don?t throw an exception from the method. This means, not being able to parse the server is ok and the exception is silenced. In our case, the server parsing fails because we find an illegal character, as only alphanumeric and dash characters are allowed.
>
> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing CR comments

I have given this a round of testing and I believe the logic is now right.
I'd suggest adding curly braces around else blocks in case of nested if statements though (see suggestion below) as it makes it easier to verify which belongs to which.

src/java.base/share/classes/java/net/URI.java line 3314:

> 3312:                             failExpecting("end of authority", q);
> 3313:                     } else
> 3314:                         authority = input.substring(p, n);

Suggestion:

                        } else {
                            failExpecting("end of authority", q);
                        }
                    } else {
                        authority = input.substring(p, n);
                    }

-------------

PR Review: https://git.openjdk.org/jdk/pull/13430#pullrequestreview-1441834815
PR Review Comment: https://git.openjdk.org/jdk/pull/13430#discussion_r1204123026

From jpai at openjdk.org  Wed May 24 13:51:07 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 13:51:07 GMT
Subject: RFR: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks [v10]
In-Reply-To: <f9xbCgPoobBjzi3p0qwUL4pPk2v8Q4wF0uJNzUF6WyQ=.62330ad6-5716-47ff-8d5c-a37a4d736145@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
 <f9xbCgPoobBjzi3p0qwUL4pPk2v8Q4wF0uJNzUF6WyQ=.62330ad6-5716-47ff-8d5c-a37a4d736145@github.com>
Message-ID: <t28p-FimH09w085gaQEymj3trYwfMaOZztzZ8Mj2pH8=.d868c8f5-fcc1-461d-80ff-f073600a3f0a@github.com>

On Wed, 24 May 2023 13:01:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a change that revisits usage of monitors in the HttpClient.
>> 
>> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
>> 
>> This change aims at avoiding situations where the carrier threads might get pinned.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More review feedback

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14038#pullrequestreview-1441918515

From dfuchs at openjdk.org  Wed May 24 14:27:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 May 2023 14:27:10 GMT
Subject: Integrated: 8308310: HttpClient: Avoid logging or locking from within
 synchronized blocks
In-Reply-To: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
References: <v5cGlTY76coiLrgGzfyhIrbZz21NGIt6FtZZehX8cu4=.c7afd791-92ee-4d40-8326-86679250e8d4@github.com>
Message-ID: <cyD93oxd8OdyXQKX3wnRrF0Lc6Bv1xGXJmqkqq9nhQY=.7fef8c01-2919-4b28-8900-0b53d1f25111@github.com>

On Wed, 17 May 2023 18:46:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a change that revisits usage of monitors in the HttpClient.
> 
> With Virtual Threads now part of the platform it should be possible to pass a newVirtualThreadPerTaskExecutor to the HttpClient. Logging, when enabled, and when called from a synchronized block, can cause the carrier thread to get pinned in case of contention when printing through the underlying PrintStream.
> 
> This change aims at avoiding situations where the carrier threads might get pinned.

This pull request has now been integrated.

Changeset: 736b90d5
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/736b90d54b51830de7757a8de3ad9c98437c824a
Stats:     933 lines in 32 files changed: 525 ins; 137 del; 271 mod

8308310: HttpClient: Avoid logging or locking from within synchronized blocks

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14038

From alanb at openjdk.org  Wed May 24 14:33:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 May 2023 14:33:00 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v3]
In-Reply-To: <uGGlsyDavyKXLuI-Ok4tj1iDR7oJ8ZqFRzM1V8wWH7o=.74d82f35-33e4-4ada-a3b5-f90307125344@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <uGGlsyDavyKXLuI-Ok4tj1iDR7oJ8ZqFRzM1V8wWH7o=.74d82f35-33e4-4ada-a3b5-f90307125344@github.com>
Message-ID: <4k8EWVU6magkRGFo4MkojmXsZpdIW94CpdLPhKoYlcM=.d2a74b5b-cc20-4b06-a5a4-123edbeecca9@github.com>

On Wed, 24 May 2023 10:14:23 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
>> 
>> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into nullStrings
>  - test comment update
>  - test update
>  - Merge branch 'master' into nullStrings
>  - exception message update
>  - test update
>  - remve whitespace
>  - update
>  - Merge branch 'master' into nullStrings
>  - first impl

I skimmed through the changes and mostly look okay. There's a few usage of "NULL" in exception messages that I assume should be "NUL character".  Probably need to bump the copyright date on several files.  You might want to find a better name for the test as NullChar isn't too descriptive, the test is really doing a lookup of a hostname that contains a NUL character. I assume there will be follow up issues to change other parts of the system to use the strict functions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14083#issuecomment-1561271438

From xuelei at openjdk.org  Wed May 24 19:15:55 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 24 May 2023 19:15:55 GMT
Subject: RFR: 8308801: update for deprecated sprintf for libnet in java.base
Message-ID: <27mqO5iBzeN15Nmf2MbNnl5hZHJQIjmk4qStetwzP2c=.52603d08-0179-48a4-bda7-6f4e85a087cd@github.com>

Hi,

May I have this update reviewed?

The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in libnet in the java.base module.

Thanks,
Xuelei

-------------

Commit messages:
 - 8308801: update for deprecated sprintf for libnet in java.base

Changes: https://git.openjdk.org/jdk/pull/14132/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14132&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308801
  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14132/head:pull/14132

PR: https://git.openjdk.org/jdk/pull/14132

From michaelm at openjdk.org  Wed May 24 20:46:23 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 24 May 2023 20:46:23 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v4]
In-Reply-To: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
Message-ID: <2rjN4GzOonpuRQUt_3QkkgAYJ1ZYs81tl8bpZ6wWpYY=.dfb0aeb3-32bc-4ede-bd45-041413455347@github.com>

> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
> 
> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into nullStrings
 - error message and test update
 - Merge branch 'master' into nullStrings
 - test comment update
 - test update
 - Merge branch 'master' into nullStrings
 - exception message update
 - test update
 - remve whitespace
 - update
 - ... and 2 more: https://git.openjdk.org/jdk/compare/207fbcb0...35df1a67

-------------

Changes: https://git.openjdk.org/jdk/pull/14083/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14083&range=03
  Stats: 188 lines in 9 files changed: 163 ins; 1 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/14083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14083/head:pull/14083

PR: https://git.openjdk.org/jdk/pull/14083

From michaelm at openjdk.org  Wed May 24 20:46:23 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 24 May 2023 20:46:23 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v3]
In-Reply-To: <4k8EWVU6magkRGFo4MkojmXsZpdIW94CpdLPhKoYlcM=.d2a74b5b-cc20-4b06-a5a4-123edbeecca9@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <uGGlsyDavyKXLuI-Ok4tj1iDR7oJ8ZqFRzM1V8wWH7o=.74d82f35-33e4-4ada-a3b5-f90307125344@github.com>
 <4k8EWVU6magkRGFo4MkojmXsZpdIW94CpdLPhKoYlcM=.d2a74b5b-cc20-4b06-a5a4-123edbeecca9@github.com>
Message-ID: <8ZifTD2mMXOKHuqAbPvML6rpg8GCtq_lIyAMIzC0y0M=.cd5b1bfd-3770-4ab6-b2eb-d3ceba603c09@github.com>

On Wed, 24 May 2023 14:30:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I skimmed through the changes and mostly look okay. There's a few usage of "NULL" in exception messages that I assume should be "NUL character". Probably need to bump the copyright date on several files. You might want to find a better name for the test as NullChar isn't too descriptive, the test is really doing a lookup of a hostname that contains a NUL character. I assume there will be follow up issues to change other parts of the system to use the strict functions.

Thanks, I've updated per these comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14083#issuecomment-1561899890

From duke at openjdk.org  Wed May 24 22:16:20 2023
From: duke at openjdk.org (Dhamoder Nalla)
Date: Wed, 24 May 2023 22:16:20 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance [v3]
In-Reply-To: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
Message-ID: <cgl99gEp8r8XGnG70RyCZhoMJ3uWR-6hmod1_k3urjE=.d3bd3b42-f4d3-4f45-8f9a-6a7f3fd4700a@github.com>

> Issue 8305763 : Using underscores in the name for a URI triggers a silent exception in the java standard library, which consumes 5% of the CPU.
> 
> Exception:
> java.net.URISyntaxException: Illegal character in hostname at index N: xyz1_abcd.com
>     at java.base/java.net.URI$Parser.fail(URI.java:2943)
>     at java.base/java.net.URI$Parser.parseHostname(URI.java:3487)
>     at java.base/java.net.URI$Parser.parseServer(URI.java:3329)
>     
>     This exception is silent and does not produce any messages, except for ODP profiler, there is no other evidence that it?s happening (the stack trace above was printed after changes to Java library). The reason for this is because of how the URI creation is implemented in the java.net.URI class. There are two paths for creating a valid URI, and one of them goes through an exception.
> 
> We can see that if parseServer fails, there is still a way the authority gets assigned and we don?t throw an exception from the method. This means, not being able to parse the server is ok and the exception is silenced. In our case, the server parsing fails because we find an illegal character, as only alphanumeric and dash characters are allowed.

Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:

  address CR comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13430/files
  - new: https://git.openjdk.org/jdk/pull/13430/files/00fa09ea..1e7b597d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13430&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13430&range=01-02

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13430/head:pull/13430

PR: https://git.openjdk.org/jdk/pull/13430

From duke at openjdk.org  Wed May 24 22:16:20 2023
From: duke at openjdk.org (Dhamoder Nalla)
Date: Wed, 24 May 2023 22:16:20 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance [v2]
In-Reply-To: <fIT3w7Xnwa7pgOQEoBxBedO8F-xMWe9LRSQa_HA3XFk=.1325e839-fe81-475f-bd07-db7d9d6b1bed@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
 <UvKB0YQgyBfdj_yUzclD3q916l37O-U4icvfwP7j9Mc=.e8262f3e-9b26-4940-9ed4-7ea4fc4762d3@github.com>
 <fIT3w7Xnwa7pgOQEoBxBedO8F-xMWe9LRSQa_HA3XFk=.1325e839-fe81-475f-bd07-db7d9d6b1bed@github.com>
Message-ID: <qysyCvQakS0A60ucvknIDebamR5bZKK5V3xC3LZOqz4=.e5e422c8-5960-4860-ad38-fdd99aea0323@github.com>

On Wed, 24 May 2023 13:19:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing CR comments
>
> src/java.base/share/classes/java/net/URI.java line 3314:
> 
>> 3312:                             failExpecting("end of authority", q);
>> 3313:                     } else
>> 3314:                         authority = input.substring(p, n);
> 
> Suggestion:
> 
>                         } else {
>                             failExpecting("end of authority", q);
>                         }
>                     } else {
>                         authority = input.substring(p, n);
>                     }

Thank you @dfuch

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13430#discussion_r1204807611

From duke at openjdk.org  Thu May 25 07:22:22 2023
From: duke at openjdk.org (Deepa Kumari)
Date: Thu, 25 May 2023 07:22:22 GMT
Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to
 joinGroup
Message-ID: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>

DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. 

On AIX, IPv6 datagramSocket can not join an IPv4 multicast group.

These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. 




Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807)

-------------

Commit messages:
 - 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup

Changes: https://git.openjdk.org/jdk/pull/14142/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14142&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308807
  Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14142/head:pull/14142

PR: https://git.openjdk.org/jdk/pull/14142

From alanb at openjdk.org  Thu May 25 07:39:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 May 2023 07:39:56 GMT
Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to
 joinGroup
In-Reply-To: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
Message-ID: <pF7Q-TGg-D1dRJqHgYBxMEWI_2MB7qVS6FtwKSvntts=.70d367ad-eff7-457f-ac52-4425953f6934@github.com>

On Thu, 25 May 2023 07:14:19 GMT, Deepa Kumari <duke at openjdk.org> wrote:

> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. 
> 
> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group.
> 
> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. 
> 
> 
> 
> 
> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807)

I've moved the JBS issue to the right place and fix the description.

The changes proposed here impact all platforms and will require discussion and cleanup. Also can you look at the isXXX methods defined by sun.nio.ch.Net to see how it is handled on other platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1562425027

From duke at openjdk.org  Thu May 25 09:57:57 2023
From: duke at openjdk.org (Deepa Kumari)
Date: Thu, 25 May 2023 09:57:57 GMT
Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to
 joinGroup
In-Reply-To: <pF7Q-TGg-D1dRJqHgYBxMEWI_2MB7qVS6FtwKSvntts=.70d367ad-eff7-457f-ac52-4425953f6934@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
 <pF7Q-TGg-D1dRJqHgYBxMEWI_2MB7qVS6FtwKSvntts=.70d367ad-eff7-457f-ac52-4425953f6934@github.com>
Message-ID: <K0aNEOOldvYOxNKpvVS3YScN7eUBBI0GVZewntOfIS4=.7a90c841-5fad-4f0d-99de-d6b2dc2e61e6@github.com>

On Thu, 25 May 2023 07:37:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I've moved the JBS issue to the right place and fix the description.
> 
> The changes proposed here impact all platforms and will require discussion and cleanup. If I understand the intent, if you create a DatagramSocket or MulticastSocket that is bound to a specific local address then you want to use that to determine if the underlying socket is IPv4 or IPv6. That might be okay but multicasting normally means binding to the wildcard address so it doesn't help. In any case, can you look at the isXXX methods defined by sun.nio.ch.Net to see how it is handled on other platforms.

Thanks @AlanBateman  for fix JBS issue description. I will look at the isXXX methods defined by sun.nio.ch.Net.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1562620701

From aturbanov at openjdk.org  Thu May 25 10:29:58 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 25 May 2023 10:29:58 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance [v3]
In-Reply-To: <cgl99gEp8r8XGnG70RyCZhoMJ3uWR-6hmod1_k3urjE=.d3bd3b42-f4d3-4f45-8f9a-6a7f3fd4700a@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
 <cgl99gEp8r8XGnG70RyCZhoMJ3uWR-6hmod1_k3urjE=.d3bd3b42-f4d3-4f45-8f9a-6a7f3fd4700a@github.com>
Message-ID: <zFD-GjV8ijEgRDIVZIvgG1WB8Sz8RWlpPUHhGfrSlWY=.2dd83134-e5f8-4d03-8d39-071018f9129f@github.com>

On Wed, 24 May 2023 22:16:20 GMT, Dhamoder Nalla <duke at openjdk.org> wrote:

>> Issue 8305763 : Using underscores in the name for a URI triggers a silent exception in the java standard library, which consumes 5% of the CPU.
>> 
>> Exception:
>> java.net.URISyntaxException: Illegal character in hostname at index N: xyz1_abcd.com
>>     at java.base/java.net.URI$Parser.fail(URI.java:2943)
>>     at java.base/java.net.URI$Parser.parseHostname(URI.java:3487)
>>     at java.base/java.net.URI$Parser.parseServer(URI.java:3329)
>>     
>>     This exception is silent and does not produce any messages, except for ODP profiler, there is no other evidence that it?s happening (the stack trace above was printed after changes to Java library). The reason for this is because of how the URI creation is implemented in the java.net.URI class. There are two paths for creating a valid URI, and one of them goes through an exception.
>> 
>> We can see that if parseServer fails, there is still a way the authority gets assigned and we don?t throw an exception from the method. This means, not being able to parse the server is ok and the exception is silenced. In our case, the server parsing fails because we find an illegal character, as only alphanumeric and dash characters are allowed.
>
> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address CR comments

src/java.base/share/classes/java/net/URI.java line 3306:

> 3304:                     q = parseServer(p, n, skipParseException);
> 3305:                     if (q < n) {
> 3306:                         if(skipParseException) {

Suggestion:

                        if (skipParseException) {

src/java.base/share/classes/java/net/URI.java line 3411:

> 3409:                     p = q;
> 3410:                 }
> 3411:             } else if( p < n && skipParseException) {

Suggestion:

            } else if (p < n && skipParseException) {

src/java.base/share/classes/java/net/URI.java line 3545:

> 3543:             if ((p < n) && !at(p, n, ':'))
> 3544:             {
> 3545:                 if(skipParseException)

Suggestion:

                if (skipParseException) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13430#discussion_r1205315982
PR Review Comment: https://git.openjdk.org/jdk/pull/13430#discussion_r1205316171
PR Review Comment: https://git.openjdk.org/jdk/pull/13430#discussion_r1205316378

From msheppar at openjdk.org  Thu May 25 11:21:57 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 25 May 2023 11:21:57 GMT
Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to
 joinGroup
In-Reply-To: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
Message-ID: <qxx7kBv2qUW4mUOHUV2Lrtkpwqwo9NzyDnRHXCNpltE=.311ed661-76fd-4a59-9d05-8259cb1bc791@github.com>

On Thu, 25 May 2023 07:14:19 GMT, Deepa Kumari <duke at openjdk.org> wrote:

> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. 
> 
> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group.
> 
> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. 
> 
> 
> 
> 
> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807)

at a cursory glance, and without a deep dive to follow any associated call flows into native code, these changes look like the are not aligned with the semantics espoused in the systems newtwork properties, especially  that of the first:

IPv4 / IPv6

    java.net.preferIPv4Stack (default: false)
    If IPv6 is available on the operating system the underlying native socket will be, by default, an IPv6 socket which lets applications connect to, and accept connections from, both IPv4 and IPv6 hosts. However, in the case an application would rather use IPv4 only sockets, then this property can be set to true. The implication is that it will not be possible for the application to communicate with IPv6 only hosts.

    java.net.preferIPv6Addresses (default: false)
    When dealing with a host which has both IPv4 and IPv6 addresses, and if IPv6 is available on the operating system, the default behavior is to prefer using IPv4 addresses over IPv6 ones. This is to ensure backward compatibility: for example, for applications that depend on the representation of an IPv4 address (e.g. 192.168.1.1). This property can be set to true to change that preference and use IPv6 addresses over IPv4 ones where possible, or system to preserve the order of the addresses as returned by the system-wide resolver

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1562728340

From michaelm at openjdk.org  Thu May 25 14:23:58 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 25 May 2023 14:23:58 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v4]
In-Reply-To: <2rjN4GzOonpuRQUt_3QkkgAYJ1ZYs81tl8bpZ6wWpYY=.dfb0aeb3-32bc-4ede-bd45-041413455347@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <2rjN4GzOonpuRQUt_3QkkgAYJ1ZYs81tl8bpZ6wWpYY=.dfb0aeb3-32bc-4ede-bd45-041413455347@github.com>
Message-ID: <JK1PFQPJMurx3Sa5NOcN4OBMLIJogHKgj7gDU0NpCjo=.0a961217-d9d3-4f08-89cc-01a768366a64@github.com>

On Wed, 24 May 2023 20:46:23 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
>> 
>> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into nullStrings
>  - error message and test update
>  - Merge branch 'master' into nullStrings
>  - test comment update
>  - test update
>  - Merge branch 'master' into nullStrings
>  - exception message update
>  - test update
>  - remve whitespace
>  - update
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/207fbcb0...35df1a67

I'll integrate this today unless there are further comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14083#issuecomment-1562998991

From alanb at openjdk.org  Thu May 25 14:26:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 May 2023 14:26:58 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v4]
In-Reply-To: <JK1PFQPJMurx3Sa5NOcN4OBMLIJogHKgj7gDU0NpCjo=.0a961217-d9d3-4f08-89cc-01a768366a64@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <2rjN4GzOonpuRQUt_3QkkgAYJ1ZYs81tl8bpZ6wWpYY=.dfb0aeb3-32bc-4ede-bd45-041413455347@github.com>
 <JK1PFQPJMurx3Sa5NOcN4OBMLIJogHKgj7gDU0NpCjo=.0a961217-d9d3-4f08-89cc-01a768366a64@github.com>
Message-ID: <ENMam1qOqATPY7ZCuLPATIBYzauLNs_cZ2NR5bbw_s8=.59d83d88-a9a0-49b9-91c4-5a38bbc01f17@github.com>

On Thu, 25 May 2023 14:21:34 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> I'll integrate this today unless there are further comments.

Thanks for addressing my comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14083#issuecomment-1563002770

From michaelm at openjdk.org  Thu May 25 15:01:21 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 25 May 2023 15:01:21 GMT
Subject: Integrated: 8300038: Make new version of JNU_GetStringPlatformChars
 which checks for null characters
In-Reply-To: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
Message-ID: <nTSeCoG82gv_0ih-Wyez0gLuIW_s7VN8B2eK4jA4vRA=.ed7090ff-1e87-4fc3-baa7-0c0bdec7bbf8@github.com>

On Mon, 22 May 2023 13:19:04 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
> 
> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).

This pull request has now been integrated.

Changeset: e7edf8d1
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7edf8d1458ff0d66aedbb0086050c36864702f6
Stats:     188 lines in 9 files changed: 163 ins; 1 del; 24 mod

8300038: Make new version of JNU_GetStringPlatformChars which checks for null characters

Reviewed-by: dfuchs, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14083

From duke at openjdk.org  Thu May 25 19:34:35 2023
From: duke at openjdk.org (Dhamoder Nalla)
Date: Thu, 25 May 2023 19:34:35 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance [v4]
In-Reply-To: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
Message-ID: <egcPdIfbnxpmtJXYGQQrkbhExiC7PPtaOxhgD8wuPNA=.93590282-2958-4bca-93f7-a9162e2b11fe@github.com>

> Issue 8305763 : Using underscores in the name for a URI triggers a silent exception in the java standard library, which consumes 5% of the CPU.
> 
> Exception:
> java.net.URISyntaxException: Illegal character in hostname at index N: xyz1_abcd.com
>     at java.base/java.net.URI$Parser.fail(URI.java:2943)
>     at java.base/java.net.URI$Parser.parseHostname(URI.java:3487)
>     at java.base/java.net.URI$Parser.parseServer(URI.java:3329)
>     
>     This exception is silent and does not produce any messages, except for ODP profiler, there is no other evidence that it?s happening (the stack trace above was printed after changes to Java library). The reason for this is because of how the URI creation is implemented in the java.net.URI class. There are two paths for creating a valid URI, and one of them goes through an exception.
> 
> We can see that if parseServer fails, there is still a way the authority gets assigned and we don?t throw an exception from the method. This means, not being able to parse the server is ok and the exception is silenced. In our case, the server parsing fails because we find an illegal character, as only alphanumeric and dash characters are allowed.

Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:

  address CR comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13430/files
  - new: https://git.openjdk.org/jdk/pull/13430/files/1e7b597d..feeb2a82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13430&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13430&range=02-03

  Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13430/head:pull/13430

PR: https://git.openjdk.org/jdk/pull/13430

From duke at openjdk.org  Thu May 25 19:34:36 2023
From: duke at openjdk.org (Dhamoder Nalla)
Date: Thu, 25 May 2023 19:34:36 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance [v3]
In-Reply-To: <zFD-GjV8ijEgRDIVZIvgG1WB8Sz8RWlpPUHhGfrSlWY=.2dd83134-e5f8-4d03-8d39-071018f9129f@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
 <cgl99gEp8r8XGnG70RyCZhoMJ3uWR-6hmod1_k3urjE=.d3bd3b42-f4d3-4f45-8f9a-6a7f3fd4700a@github.com>
 <zFD-GjV8ijEgRDIVZIvgG1WB8Sz8RWlpPUHhGfrSlWY=.2dd83134-e5f8-4d03-8d39-071018f9129f@github.com>
Message-ID: <c-Qdqe4mltEqFkG0XKbD02XABntdZURS_I1BYXUFgMA=.fa600525-0afe-4577-8408-c83ab4d4ed0c@github.com>

On Thu, 25 May 2023 10:26:27 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address CR comments
>
> src/java.base/share/classes/java/net/URI.java line 3306:
> 
>> 3304:                     q = parseServer(p, n, skipParseException);
>> 3305:                     if (q < n) {
>> 3306:                         if(skipParseException) {
> 
> Suggestion:
> 
>                         if (skipParseException) {

Thanks for reviewing the PR @turbanoff

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13430#discussion_r1205927755

From duke at openjdk.org  Thu May 25 20:44:04 2023
From: duke at openjdk.org (zhurs)
Date: Thu, 25 May 2023 20:44:04 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
Message-ID: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>

When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

-------------

Commit messages:
 - 8308144: HttpClient - uncontrolled memory consumption in SSLFlowDelegate.Reader

Changes: https://git.openjdk.org/jdk/pull/14159/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14159&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308144
  Stats: 190 lines in 2 files changed: 188 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14159/head:pull/14159

PR: https://git.openjdk.org/jdk/pull/14159

From dfuchs at openjdk.org  Thu May 25 21:43:55 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 25 May 2023 21:43:55 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <ItT6wFvg6mZlISFClWaOA1oiT_UD-kNstEIrkZsbsTw=.5f0ecfa7-ae0e-46dc-a89c-e0e265bcf7a7@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

Hi, thanks a lot for the bug report and the fix.

The fix looks reasonable, however the test fails quite consistently in our CI on many platform:


java.lang.RuntimeException: Too large intermediate buffer, server sent 10x300000 bytes
	at HttpsBackpressureTest.main(HttpsBackpressureTest.java:87)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1583)


I'm not sure I understand the logic of the test either. Does it depend on some assumption about the size of the socket buffers? From where do the various constants in the test come from? Also could there be a better solution than `sleep(2000)` ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1563538468

From duke at openjdk.org  Thu May 25 22:10:55 2023
From: duke at openjdk.org (zhurs)
Date: Thu, 25 May 2023 22:10:55 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <ItT6wFvg6mZlISFClWaOA1oiT_UD-kNstEIrkZsbsTw=.5f0ecfa7-ae0e-46dc-a89c-e0e265bcf7a7@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
 <ItT6wFvg6mZlISFClWaOA1oiT_UD-kNstEIrkZsbsTw=.5f0ecfa7-ae0e-46dc-a89c-e0e265bcf7a7@github.com>
Message-ID: <sDoh9D7x8WFB3hIzWo2S_VpEnJ1tYG9Q1p0a5wB7jIE=.e8451673-06a3-411b-b1bc-2e0377108802@github.com>

On Thu, 25 May 2023 21:40:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
>> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.
>
> Hi, thanks a lot for the bug report and the fix.
> 
> The fix looks reasonable, however the test fails quite consistently in our CI on many platform:
> 
> 
> java.lang.RuntimeException: Too large intermediate buffer, server sent 10x300000 bytes
> 	at HttpsBackpressureTest.main(HttpsBackpressureTest.java:87)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> 
> I'm not sure I understand the logic of the test either. Does it depend on some assumption about the size of the socket buffers? From where do the various constants in the test come from? Also could there be a better solution than `sleep(2000)` ?

@dfuch, thanks for your lightning-fast reply.

Indeed it relies on buffer sizes.
The test works for me on Linux and Mac, but real life seems to be more diverse.

Unfortunately, I don't know how else to reproduce the problem and test the fix - the tested logic is hidden deep.

It may be possible to commit the fix without unit-test?
The regression is not affected, and the behavior can be checked manually using the recipe from the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1563562380

From djelinski at openjdk.org  Fri May 26 06:51:56 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 26 May 2023 06:51:56 GMT
Subject: RFR: 8308801: update for deprecated sprintf for libnet in
 java.base
In-Reply-To: <27mqO5iBzeN15Nmf2MbNnl5hZHJQIjmk4qStetwzP2c=.52603d08-0179-48a4-bda7-6f4e85a087cd@github.com>
References: <27mqO5iBzeN15Nmf2MbNnl5hZHJQIjmk4qStetwzP2c=.52603d08-0179-48a4-bda7-6f4e85a087cd@github.com>
Message-ID: <iivk15sioPXw_caglRnHSJVvjkPNt4gaX2Lnvke4P_k=.5099ceb3-cb73-4bce-b56e-0d5794606bf8@github.com>

On Wed, 24 May 2023 18:53:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in libnet in the java.base module.
> 
> Thanks,
> Xuelei

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14132#pullrequestreview-1445295175

From dfuchs at openjdk.org  Fri May 26 08:29:58 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 26 May 2023 08:29:58 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <tHDZDBHPlHFtsFJdP2NYBO-cX0b5AUpfSkuqLbIvh3k=.532b5504-92b9-4995-9fba-b3aa729603c0@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

The HttpClient supports properties that can be used to tune the SEND and RCV buffer sizes. I would not recommend to use them in production unless you absolutely know what you do, because setting them can prevent underlying OD optimizations which in turn can affect performance negatively. However - using them in tests is fair game. If you could explain the relationship between the constants in the test and the assumed socket buffer sizes (on the client size I assume) then we may try to experiment forcing the test's client to use some specific value for SNDBUF and RCVBUF, and see if that works. It may not, but maybe we could explore this possibility before ditching the test. If we notice that there are some platforms where the test always pass reliably we could also experiment with using `@requires` to restrict the test to run on these platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1564006762

From dfuchs at openjdk.org  Fri May 26 08:34:01 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 26 May 2023 08:34:01 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <yNsNbfybht3tIQ-lV25F8RDXSRVCZvHq3XfJUQ1wmaM=.16cc32d3-3877-4a28-ae56-88aa9038c965@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

See https://docs.oracle.com/en/java/javase/20/docs/api/java.net.http/module-summary.html

- jdk.httpclient.receiveBufferSize (default: operating system default): The HTTP client[ socket receive buffer size](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/StandardSocketOptions.html#SO_RCVBUF) in bytes.

- jdk.httpclient.sendBufferSize (default: operating system default): The HTTP client socket [send buffer size](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/StandardSocketOptions.html#SO_SNDBUF). Values less than or equal to zero are ignored.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1564011270

From dfuchs at openjdk.org  Fri May 26 08:53:55 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 26 May 2023 08:53:55 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <t9GFwrWd3YpTqrBnuZ7TCgAO-qjoT72IxH3GP5JuRC4=.bde198aa-6284-4f30-a489-f03d714c61ac@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

>From the CI results it seems it only passes on macOS and fails consistently on all Linux or Windows flavors. But if it depends on socket buffer sizes it may actually depend on how these machines are configured by default.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1564038114

From duke at openjdk.org  Fri May 26 09:20:55 2023
From: duke at openjdk.org (zhurs)
Date: Fri, 26 May 2023 09:20:55 GMT
Subject: RFR: 8308144: HttpClient - uncontrolled memory consumption in
 SSLFlowDelegate.Reader
In-Reply-To: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
References: <rac3zYdOdmd20sDfDD_-mosBC01acaO_OyZ9VBsZ8nE=.52008b27-8e1b-48f6-bc98-afeed8a187ef@github.com>
Message-ID: <gQRy8DtWqKlVlh0oonOd3ImdFILJOT9uPIXQM1_SWEU=.9371a0ff-51cf-49e8-89e8-dbde699e4ed2@github.com>

On Thu, 25 May 2023 20:17:39 GMT, zhurs <duke at openjdk.org> wrote:

> When using HttpClient to make requests to HTTPS resources, there is an issue where the entire file is being downloaded into memory without the ability to limit the buffer size.
> If the SSLEngine cannot decode the entire buffer due to the algorithm's blocking nature, it returns a decoded chunk of data and BUFFER_UNDERFLOW status, which leads to SSLFlowDelegate.Reader requesting more data despite the output queue being full.

Thank you, I will look at these options.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14159#issuecomment-1564081579

From duke at openjdk.org  Fri May 26 13:05:08 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Fri, 26 May 2023 13:05:08 GMT
Subject: RFR: 8308336: Test
 java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed:
 java.net.BindException: Address already in use
Message-ID: <T5lr_3v0CyMinDd_4x2sn-V8wS6z_MeI9lV1G-dAmEY=.d0dfdd63-53d6-4b19-8f8e-ce9b2427304e@github.com>

`HttpURLConnectionExpectContinueTest` was throwing an error due to port being hardcoded, updated test to let the system decide which port to use.

-------------

Commit messages:
 - change test to use ephemeral port

Changes: https://git.openjdk.org/jdk/pull/14177/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14177&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308336
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14177/head:pull/14177

PR: https://git.openjdk.org/jdk/pull/14177

From dfuchs at openjdk.org  Fri May 26 13:36:57 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 26 May 2023 13:36:57 GMT
Subject: RFR: 8308336: Test
 java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed:
 java.net.BindException: Address already in use
In-Reply-To: <T5lr_3v0CyMinDd_4x2sn-V8wS6z_MeI9lV1G-dAmEY=.d0dfdd63-53d6-4b19-8f8e-ce9b2427304e@github.com>
References: <T5lr_3v0CyMinDd_4x2sn-V8wS6z_MeI9lV1G-dAmEY=.d0dfdd63-53d6-4b19-8f8e-ce9b2427304e@github.com>
Message-ID: <j_qmiNJqZ6EyeVNrj2sfJL6kpUQSF7qU-nUy8gIgJ1E=.d2b03a74-0ca5-4faf-b1ba-454d50b36f40@github.com>

On Fri, 26 May 2023 12:57:59 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> `HttpURLConnectionExpectContinueTest` was throwing an error due to port being hardcoded, updated test to let the system decide which port to use.

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 76:

> 74:         control.serverSocket = new ServerSocket();
> 75:         control.serverSocket.setReuseAddress(true);
> 76:         control.serverSocket.bind(new InetSocketAddress("127.0.0.1", 0));

While you're at it can you change the address to use `InetAddress.getLoopbackAddress()`here, and the URIBuilder in createConnection() below?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14177#discussion_r1206793826

From rriggs at openjdk.org  Fri May 26 14:16:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 May 2023 14:16:56 GMT
Subject: RFR: 8308801: update for deprecated sprintf for libnet in
 java.base
In-Reply-To: <27mqO5iBzeN15Nmf2MbNnl5hZHJQIjmk4qStetwzP2c=.52603d08-0179-48a4-bda7-6f4e85a087cd@github.com>
References: <27mqO5iBzeN15Nmf2MbNnl5hZHJQIjmk4qStetwzP2c=.52603d08-0179-48a4-bda7-6f4e85a087cd@github.com>
Message-ID: <PcOUsz2SAnNWcP_c9JbVubdwnMXqB14jiZ16mISIZgA=.56a5483d-b8f2-4263-a2fa-c9c0d69bb512@github.com>

On Wed, 24 May 2023 18:53:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in libnet in the java.base module.
> 
> Thanks,
> Xuelei

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14132#pullrequestreview-1446332604

From xuelei at openjdk.org  Fri May 26 16:51:04 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 26 May 2023 16:51:04 GMT
Subject: RFR: 8308801: update for deprecated sprintf for libnet in
 java.base
In-Reply-To: <iivk15sioPXw_caglRnHSJVvjkPNt4gaX2Lnvke4P_k=.5099ceb3-cb73-4bce-b56e-0d5794606bf8@github.com>
References: <27mqO5iBzeN15Nmf2MbNnl5hZHJQIjmk4qStetwzP2c=.52603d08-0179-48a4-bda7-6f4e85a087cd@github.com>
 <iivk15sioPXw_caglRnHSJVvjkPNt4gaX2Lnvke4P_k=.5099ceb3-cb73-4bce-b56e-0d5794606bf8@github.com>
Message-ID: <AUQ9ZbNNvt3X3c7-Rw6I6kn2z3Isev3ifjUytK20X8k=.46f0c390-af0b-4afb-bc26-d1fc30a4398e@github.com>

On Fri, 26 May 2023 06:48:45 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in libnet in the java.base module.
>> 
>> Thanks,
>> Xuelei
>
> Marked as reviewed by djelinski (Reviewer).

Thank you for the review, @djelinski @RogerRiggs !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14132#issuecomment-1564657845

From xuelei at openjdk.org  Fri May 26 16:51:06 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 26 May 2023 16:51:06 GMT
Subject: Integrated: 8308801: update for deprecated sprintf for libnet in
 java.base
In-Reply-To: <27mqO5iBzeN15Nmf2MbNnl5hZHJQIjmk4qStetwzP2c=.52603d08-0179-48a4-bda7-6f4e85a087cd@github.com>
References: <27mqO5iBzeN15Nmf2MbNnl5hZHJQIjmk4qStetwzP2c=.52603d08-0179-48a4-bda7-6f4e85a087cd@github.com>
Message-ID: <S88kcCMoc_VnRSdWjKsRja2WYmtvIEFQUTfoE18MGQU=.32b942db-e37b-4aab-9efe-6fb21eeb3268@github.com>

On Wed, 24 May 2023 18:53:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in libnet in the java.base module.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

Changeset: c72b5474
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c72b5474255d56f704930509525de69711dd9bfb
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8308801: update for deprecated sprintf for libnet in java.base

Reviewed-by: djelinski, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14132

From serb at openjdk.org  Mon May 29 03:59:57 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 29 May 2023 03:59:57 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v11]
In-Reply-To: <lUCyEJk_BJzBJvhDYgHPyuvuhGFp0YKC-uvhrZOlmVk=.944bc613-1df5-41ff-89e9-e0592a1c0259@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <lUCyEJk_BJzBJvhDYgHPyuvuhGFp0YKC-uvhrZOlmVk=.944bc613-1df5-41ff-89e9-e0592a1c0259@github.com>
Message-ID: <hcDMsOUGtTIgD0LeHgqLR4ImS3AUoXeMRST5h55IIaI=.08ce18eb-3834-4798-9cef-53c505bbe460@github.com>

On Mon, 22 May 2023 18:54:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I would like to get preliminary feedback about the provided patch.
>> 
>> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
>> 
>> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
>> 
>> At the moment this cache can be configured by the application using the following two properties:
>>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
>> 
>> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
>> 
>> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
>> 
>> Possible solutions:
>>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
>> 
>> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
>> 
>> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
>> 
>> 
>> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
>> https://www.rfc-editor.org/rfc/rfc8767
>> 
>> Comments about current and other possible implementations:
>>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>>  * The refr...
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   if the property is not set means do not use stale names

Since the RDP 1 for JDK 21 is coming, I would like to accelerate the review of this PR, do I need to provide some additional information to make it easy to review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1566478290

From dfuchs at openjdk.org  Mon May 29 13:22:02 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 29 May 2023 13:22:02 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v11]
In-Reply-To: <lUCyEJk_BJzBJvhDYgHPyuvuhGFp0YKC-uvhrZOlmVk=.944bc613-1df5-41ff-89e9-e0592a1c0259@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <lUCyEJk_BJzBJvhDYgHPyuvuhGFp0YKC-uvhrZOlmVk=.944bc613-1df5-41ff-89e9-e0592a1c0259@github.com>
Message-ID: <0nGTt5JIwhPP8i5pQTAhcc6cOIU7_8m6T3dRKxuAUtc=.482bdd55-b000-4827-9489-8826da9360fe@github.com>

On Mon, 22 May 2023 18:54:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I would like to get preliminary feedback about the provided patch.
>> 
>> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
>> 
>> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
>> 
>> At the moment this cache can be configured by the application using the following two properties:
>>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
>> 
>> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
>> 
>> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
>> 
>> Possible solutions:
>>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
>> 
>> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
>> 
>> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
>> 
>> 
>> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
>> https://www.rfc-editor.org/rfc/rfc8767
>> 
>> Comments about current and other possible implementations:
>>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>>  * The refr...
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   if the property is not set means do not use stale names

src/java.base/share/classes/java/net/InetAddress.java line 225:

> 223:  * <p>
> 224:  * A value of 0 (zero) or if the property is not set means do not use stale
> 225:  * names, the negative value is ignored.

Suggestion:

 * names. Negative values are ignored.

src/java.base/share/classes/java/net/doc-files/net-properties.html line 276:

> 274: 	preferable to use a stale name rather than result of unsuccessful name lookup.
> 275: 	A value of 0 (zero) or if the property is not set means do not use stale
> 276: 	names, the negative value is ignored.

I'd suggest to rephrase:

Suggestion:

	A value of 0 (zero) or if the property is not set means do not use stale
	names. Negative values are ignored.

src/java.base/share/classes/java/net/doc-files/net-properties.html line 277:

> 275: 	A value of 0 (zero) or if the property is not set means do not use stale
> 276: 	names, the negative value is ignored.
> 277: 	The default value is implementation-specific.</P>

Maybe we should say that the default value is 0 since this is what is documented in `java.security`

src/java.base/share/conf/security/java.security line 366:

> 364: # zero: do not use stale names
> 365: #
> 366: # default value is never (NEVER).

Suggestion:

# any positive value: the number of seconds to use the stale names
# zero: do not use stale names
# negative values are ignored
#
# default value is 0 (NEVER).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1209308636
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1209303760
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1209307516
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1209306126

From serb at openjdk.org  Mon May 29 16:05:08 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 29 May 2023 16:05:08 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v12]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <Yhk53JKULUT9xQYYMUwvoTGasa_KP5j_kddBe2QnF9Y=.63727242-5cc4-4d45-9900-3493113ecace@github.com>

> I would like to get preliminary feedback about the provided patch.
> 
> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
> 
> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
> 
> At the moment this cache can be configured by the application using the following two properties:
>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
> 
> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
> 
> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
> 
> Possible solutions:
>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
> 
> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
> 
> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
> 
> 
> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
> https://www.rfc-editor.org/rfc/rfc8767
> 
> Comments about current and other possible implementations:
>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>  * The refresh timeout includes the time s...

Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:

 - Apply suggestions from code review
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Apply suggestions from code review
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13285/files
  - new: https://git.openjdk.org/jdk/pull/13285/files/ce595f74..e0de2e0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=10-11

  Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

PR: https://git.openjdk.org/jdk/pull/13285

From serb at openjdk.org  Mon May 29 16:13:59 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 29 May 2023 16:13:59 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v11]
In-Reply-To: <0nGTt5JIwhPP8i5pQTAhcc6cOIU7_8m6T3dRKxuAUtc=.482bdd55-b000-4827-9489-8826da9360fe@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <lUCyEJk_BJzBJvhDYgHPyuvuhGFp0YKC-uvhrZOlmVk=.944bc613-1df5-41ff-89e9-e0592a1c0259@github.com>
 <0nGTt5JIwhPP8i5pQTAhcc6cOIU7_8m6T3dRKxuAUtc=.482bdd55-b000-4827-9489-8826da9360fe@github.com>
Message-ID: <NcBOtilRYbOj1BhqwN00W1M0QO2w1AQQizy3IWPFbAg=.f17c3b43-8d00-4079-9151-d198af39440b@github.com>

On Mon, 29 May 2023 13:16:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   if the property is not set means do not use stale names
>
> src/java.base/share/classes/java/net/doc-files/net-properties.html line 277:
> 
>> 275: 	A value of 0 (zero) or if the property is not set means do not use stale
>> 276: 	names, the negative value is ignored.
>> 277: 	The default value is implementation-specific.</P>
> 
> Maybe we should say that the default value is 0 since this is what is documented in `java.security`

In the "java.security" file we documented the default value of the property in that file but it is commented out. Right now the new property specified in the same way as the old "networkaddress.cache.ttl", see [net-properties.html](https://github.com/openjdk/jdk/pull/13285/files/ce595f74f511553274c9da254d53b368abe44408#diff-21ffe1f9a665c0f70cc9888d2da937a2a77fadfdacc23d0bd59506595e668c5fR267) and [InetAddress.java](https://github.com/openjdk/jdk/pull/13285/files/a856cd36eba1efacbc0f95918ac6aa2712cab870#diff-55d4acc64110543896bf6c289d6247cded986edfe9ccce3a9bca88a197711d58R204)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1209443997

From serb at openjdk.org  Mon May 29 16:18:58 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 29 May 2023 16:18:58 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v11]
In-Reply-To: <NcBOtilRYbOj1BhqwN00W1M0QO2w1AQQizy3IWPFbAg=.f17c3b43-8d00-4079-9151-d198af39440b@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <lUCyEJk_BJzBJvhDYgHPyuvuhGFp0YKC-uvhrZOlmVk=.944bc613-1df5-41ff-89e9-e0592a1c0259@github.com>
 <0nGTt5JIwhPP8i5pQTAhcc6cOIU7_8m6T3dRKxuAUtc=.482bdd55-b000-4827-9489-8826da9360fe@github.com>
 <NcBOtilRYbOj1BhqwN00W1M0QO2w1AQQizy3IWPFbAg=.f17c3b43-8d00-4079-9151-d198af39440b@github.com>
Message-ID: <jPRRhl_eE0vP2G81IAyk6h3Ov5phpLJIKUcOO4kX1Jo=.ca1d04dc-aead-4858-bc14-8e839059e0fe@github.com>

On Mon, 29 May 2023 16:11:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/doc-files/net-properties.html line 277:
>> 
>>> 275: 	A value of 0 (zero) or if the property is not set means do not use stale
>>> 276: 	names, the negative value is ignored.
>>> 277: 	The default value is implementation-specific.</P>
>> 
>> Maybe we should say that the default value is 0 since this is what is documented in `java.security`
>
> In the "java.security" file we documented the default value of the property in that file but it is commented out. Right now the new property specified in the same way as the old "networkaddress.cache.ttl", see [net-properties.html](https://github.com/openjdk/jdk/pull/13285/files/ce595f74f511553274c9da254d53b368abe44408#diff-21ffe1f9a665c0f70cc9888d2da937a2a77fadfdacc23d0bd59506595e668c5fR267) and [InetAddress.java](https://github.com/openjdk/jdk/pull/13285/files/a856cd36eba1efacbc0f95918ac6aa2712cab870#diff-55d4acc64110543896bf6c289d6247cded986edfe9ccce3a9bca88a197711d58R204)

In the [InetAddress.java](https://github.com/openjdk/jdk/pull/13285/files/a856cd36eba1efacbc0f95918ac6aa2712cab870#diff-55d4acc64110543896bf6c289d6247cded986edfe9ccce3a9bca88a197711d58R204)

 * <dt><b>networkaddress.cache.ttl</b></dt>
 * <dd>Indicates the caching policy for successful name lookups from
 * the name service. The value is specified as an integer to indicate
 * the number of seconds to cache the successful lookup. The default
 * setting is to cache for an implementation specific period of time.

In the [java.security](https://github.com/openjdk/jdk/pull/13285/files/ce595f74f511553274c9da254d53b368abe44408#diff-)

# default value is forever (FOREVER). For security reasons, this
# caching is made forever when a security manager is set. When a security
# manager is not set, the default behavior in this implementation
# is to cache for 30 seconds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1209446262

From dfuchs at openjdk.org  Mon May 29 17:18:20 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 29 May 2023 17:18:20 GMT
Subject: RFR: 8307648: java/net/httpclient/ExpectContinueTest.java timed out
Message-ID: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>

Please find here a fix for the java/net/httpclient/ExpectContinueTest.java which was failing intermittently.

It turns out there was two bugs here:

- on on the server side, which added the END_STREAM flag to the HeaderFrame containing the 100 response.
  This can obviously never be right since 100 is an intermediary response, which should be followed by a final response.
  
- on the client side, because this was interpreted as "there will be no body" - but it didn't prevent the client from waiting for the final response.

With this fix a 100 response carrying the END_STREAM flag will cause the exchange to be cancelled. I manually verified that this worked before fixing the server side.

The logic on server side is fixed to ignore whatever length is passed to sendResponseHeaders() if 100 is supplied, and to not add the END_STREAM flag to the HeaderFrame that carries the 100 response (which is a side effect of setting the expected length parameter to 0 in that case).

-------------

Commit messages:
 - 8307648

Changes: https://git.openjdk.org/jdk/pull/14207/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14207&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307648
  Stats: 61 lines in 3 files changed: 54 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14207/head:pull/14207

PR: https://git.openjdk.org/jdk/pull/14207

From djelinski at openjdk.org  Tue May 30 11:28:55 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 30 May 2023 11:28:55 GMT
Subject: RFR: 8307648: java/net/httpclient/ExpectContinueTest.java timed
 out
In-Reply-To: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
References: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
Message-ID: <M5MbXr0vHyWe_xbUmi1IPIgiuDSlxf6QXqnEvNljn3g=.246de36c-aa6e-4d02-844a-5a95f261faaa@github.com>

On Mon, 29 May 2023 17:10:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a fix for the java/net/httpclient/ExpectContinueTest.java which was failing intermittently.
> 
> It turns out there was two bugs here:
> 
> - on on the server side, which added the END_STREAM flag to the HeaderFrame containing the 100 response.
>   This can obviously never be right since 100 is an intermediary response, which should be followed by a final response.
>   
> - on the client side, because this was interpreted as "there will be no body" - but it didn't prevent the client from waiting for the final response.
> 
> With this fix a 100 response carrying the END_STREAM flag will cause the exchange to be cancelled. I manually verified that this worked before fixing the server side.
> 
> The logic on server side is fixed to ignore whatever length is passed to sendResponseHeaders() if 100 is supplied, and to not add the END_STREAM flag to the HeaderFrame that carries the 100 response (which is a side effect of setting the expected length parameter to 0 in that case).

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 529:

> 527:                     debug.log("Received 100 statusCode, but FIN bit is set");
> 528:                 }
> 529:                 cancelImpl(new IOException("stream closed after 100, no other response expected"));

This will produce the wrong error code; see https://datatracker.ietf.org/doc/html/rfc9113#name-http-message-framing :
> An interim response consists of a [HEADERS](https://datatracker.ietf.org/doc/html/rfc9113#HEADERS) frame (which might be followed by zero or more [CONTINUATION](https://datatracker.ietf.org/doc/html/rfc9113#CONTINUATION) frames) containing the control data and header section of an interim (1xx) HTTP response (see [Section 15](https://www.rfc-editor.org/rfc/rfc9110#section-15) of [[HTTP](https://datatracker.ietf.org/doc/html/rfc9110)]). A [HEADERS](https://datatracker.ietf.org/doc/html/rfc9113#HEADERS) frame with the END_STREAM flag set that carries an informational status code is [malformed](https://datatracker.ietf.org/doc/html/rfc9113#malformed) ([Section 8.1.1](https://datatracker.ietf.org/doc/html/rfc9113#malformed)).

> Malformed requests or responses that are detected MUST be treated as a [stream error](https://datatracker.ietf.org/doc/html/rfc9113#StreamErrorHandler) ([Section 5.4.2](https://datatracker.ietf.org/doc/html/rfc9113#StreamErrorHandler)) of type [PROTOCOL_ERROR](https://datatracker.ietf.org/doc/html/rfc9113#PROTOCOL_ERROR).

as far as I could tell, `cancelImpl` sends `CANCEL` error code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14207#discussion_r1210132757

From dfuchs at openjdk.org  Tue May 30 11:57:41 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 May 2023 11:57:41 GMT
Subject: RFR: 8307648: java/net/httpclient/ExpectContinueTest.java timed
 out [v2]
In-Reply-To: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
References: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
Message-ID: <hL57jS20dODFDqY7ec7Z2ZMsWsKd9f8YWqi5FhiH0VA=.ea3d9edc-ba3f-4482-9e45-de0acd6340ab@github.com>

> Please find here a fix for the java/net/httpclient/ExpectContinueTest.java which was failing intermittently.
> 
> It turns out there was two bugs here:
> 
> - on on the server side, which added the END_STREAM flag to the HeaderFrame containing the 100 response.
>   This can obviously never be right since 100 is an intermediary response, which should be followed by a final response.
>   
> - on the client side, because this was interpreted as "there will be no body" - but it didn't prevent the client from waiting for the final response.
> 
> With this fix a 100 response carrying the END_STREAM flag will cause the exchange to be cancelled. I manually verified that this worked before fixing the server side.
> 
> The logic on server side is fixed to ignore whatever length is passed to sendResponseHeaders() if 100 is supplied, and to not add the END_STREAM flag to the HeaderFrame that carries the 100 response (which is a side effect of setting the expected length parameter to 0 in that case).

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  A HEADERS frame with the END_STREAM flag set that carries an informational status code is malformed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14207/files
  - new: https://git.openjdk.org/jdk/pull/14207/files/1ca3000c..f046291f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14207&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14207&range=00-01

  Stats: 11 lines in 1 file changed: 5 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14207/head:pull/14207

PR: https://git.openjdk.org/jdk/pull/14207

From djelinski at openjdk.org  Tue May 30 13:06:04 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 30 May 2023 13:06:04 GMT
Subject: RFR: 8307648: java/net/httpclient/ExpectContinueTest.java timed
 out [v2]
In-Reply-To: <hL57jS20dODFDqY7ec7Z2ZMsWsKd9f8YWqi5FhiH0VA=.ea3d9edc-ba3f-4482-9e45-de0acd6340ab@github.com>
References: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
 <hL57jS20dODFDqY7ec7Z2ZMsWsKd9f8YWqi5FhiH0VA=.ea3d9edc-ba3f-4482-9e45-de0acd6340ab@github.com>
Message-ID: <VBNneH-Zt4rluqrnmrIOCa5r_k2KcMQrknHcIE1Po5g=.354465f1-b55b-49be-b97f-cb1f9d59468b@github.com>

On Tue, 30 May 2023 11:57:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a fix for the java/net/httpclient/ExpectContinueTest.java which was failing intermittently.
>> 
>> It turns out there was two bugs here:
>> 
>> - on on the server side, which added the END_STREAM flag to the HeaderFrame containing the 100 response.
>>   This can obviously never be right since 100 is an intermediary response, which should be followed by a final response.
>>   
>> - on the client side, because this was interpreted as "there will be no body" - but it didn't prevent the client from waiting for the final response.
>> 
>> With this fix a 100 response carrying the END_STREAM flag will cause the exchange to be cancelled. I manually verified that this worked before fixing the server side.
>> 
>> The logic on server side is fixed to ignore whatever length is passed to sendResponseHeaders() if 100 is supplied, and to not add the END_STREAM flag to the HeaderFrame that carries the 100 response (which is a side effect of setting the expected length parameter to 0 in that case).
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A HEADERS frame with the END_STREAM flag set that carries an informational status code is malformed

LGTM.
Given that this alters the client behavior, please add a test or a noreg label.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14207#pullrequestreview-1450888088

From dfuchs at openjdk.org  Tue May 30 14:17:55 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 May 2023 14:17:55 GMT
Subject: RFR: 8307648: java/net/httpclient/ExpectContinueTest.java timed
 out [v3]
In-Reply-To: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
References: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
Message-ID: <4vR72zceom9BrqKCGfe3noVagiTzG1g5aFv_qidd3XE=.5ddc8441-afc0-43a3-b92f-f1d264a459d2@github.com>

> Please find here a fix for the java/net/httpclient/ExpectContinueTest.java which was failing intermittently.
> 
> It turns out there was two bugs here:
> 
> - on on the server side, which added the END_STREAM flag to the HeaderFrame containing the 100 response.
>   This can obviously never be right since 100 is an intermediary response, which should be followed by a final response.
>   
> - on the client side, because this was interpreted as "there will be no body" - but it didn't prevent the client from waiting for the final response.
> 
> With this fix a 100 response carrying the END_STREAM flag will cause the exchange to be cancelled. I manually verified that this worked before fixing the server side.
> 
> The logic on server side is fixed to ignore whatever length is passed to sendResponseHeaders() if 100 is supplied, and to not add the END_STREAM flag to the HeaderFrame that carries the 100 response (which is a side effect of setting the expected length parameter to 0 in that case).

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  If RESET is received before the final response has been received the request should be cancelled too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14207/files
  - new: https://git.openjdk.org/jdk/pull/14207/files/f046291f..aed7d649

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14207&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14207&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14207/head:pull/14207

PR: https://git.openjdk.org/jdk/pull/14207

From dfuchs at openjdk.org  Tue May 30 14:26:56 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 May 2023 14:26:56 GMT
Subject: RFR: 8307648: java/net/httpclient/ExpectContinueTest.java timed
 out [v3]
In-Reply-To: <4vR72zceom9BrqKCGfe3noVagiTzG1g5aFv_qidd3XE=.5ddc8441-afc0-43a3-b92f-f1d264a459d2@github.com>
References: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
 <4vR72zceom9BrqKCGfe3noVagiTzG1g5aFv_qidd3XE=.5ddc8441-afc0-43a3-b92f-f1d264a459d2@github.com>
Message-ID: <EwTnNeJJgKfRVLEnSjYr3iGOUS2vR1brFZQ2kgonN9M=.d6240923-654f-4c9c-9ec3-34aad889e81e@github.com>

On Tue, 30 May 2023 14:17:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a fix for the java/net/httpclient/ExpectContinueTest.java which was failing intermittently.
>> 
>> It turns out there was two bugs here:
>> 
>> - on on the server side, which added the END_STREAM flag to the HeaderFrame containing the 100 response.
>>   This can obviously never be right since 100 is an intermediary response, which should be followed by a final response.
>>   
>> - on the client side, because this was interpreted as "there will be no body" - but it didn't prevent the client from waiting for the final response.
>> 
>> With this fix a 100 response carrying the END_STREAM flag will cause the exchange to be cancelled. I manually verified that this worked before fixing the server side.
>> 
>> The logic on server side is fixed to ignore whatever length is passed to sendResponseHeaders() if 100 is supplied, and to not add the END_STREAM flag to the HeaderFrame that carries the 100 response (which is a side effect of setting the expected length parameter to 0 in that case).
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   If RESET is received before the final response has been received the request should be cancelled too

I have added 8307648 to the `@bug` tag in ExpectContinueTest, and also logged https://bugs.openjdk.org/browse/JDK-8309118 to add more deterministic tests for various scenarios.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14207#issuecomment-1568529721

From dfuchs at openjdk.org  Tue May 30 14:26:58 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 May 2023 14:26:58 GMT
Subject: RFR: 8307648: java/net/httpclient/ExpectContinueTest.java timed
 out [v3]
In-Reply-To: <M5MbXr0vHyWe_xbUmi1IPIgiuDSlxf6QXqnEvNljn3g=.246de36c-aa6e-4d02-844a-5a95f261faaa@github.com>
References: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
 <M5MbXr0vHyWe_xbUmi1IPIgiuDSlxf6QXqnEvNljn3g=.246de36c-aa6e-4d02-844a-5a95f261faaa@github.com>
Message-ID: <5mDss1Uoaz2etXteIwoOINSHx9AUcYwfyZHbSxjQZNs=.b55da098-f841-4d8f-98ae-68bbfb569f51@github.com>

On Tue, 30 May 2023 11:26:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   If RESET is received before the final response has been received the request should be cancelled too
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 529:
> 
>> 527:                     debug.log("Received 100 statusCode, but FIN bit is set");
>> 528:                 }
>> 529:                 cancelImpl(new IOException("stream closed after 100, no other response expected"));
> 
> This will produce the wrong error code; see https://datatracker.ietf.org/doc/html/rfc9113#name-http-message-framing :
>> An interim response consists of a [HEADERS](https://datatracker.ietf.org/doc/html/rfc9113#HEADERS) frame (which might be followed by zero or more [CONTINUATION](https://datatracker.ietf.org/doc/html/rfc9113#CONTINUATION) frames) containing the control data and header section of an interim (1xx) HTTP response (see [Section 15](https://www.rfc-editor.org/rfc/rfc9110#section-15) of [[HTTP](https://datatracker.ietf.org/doc/html/rfc9110)]). A [HEADERS](https://datatracker.ietf.org/doc/html/rfc9113#HEADERS) frame with the END_STREAM flag set that carries an informational status code is [malformed](https://datatracker.ietf.org/doc/html/rfc9113#malformed) ([Section 8.1.1](https://datatracker.ietf.org/doc/html/rfc9113#malformed)).
> 
>> Malformed requests or responses that are detected MUST be treated as a [stream error](https://datatracker.ietf.org/doc/html/rfc9113#StreamErrorHandler) ([Section 5.4.2](https://datatracker.ietf.org/doc/html/rfc9113#StreamErrorHandler)) of type [PROTOCOL_ERROR](https://datatracker.ietf.org/doc/html/rfc9113#PROTOCOL_ERROR).
> 
> as far as I could tell, `cancelImpl` sends `CANCEL` error code.

Fixed in https://git.openjdk.org/jdk/pull/14207/files/f046291f4ace4e6ccc932e67dcb8a3d12e5f788a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14207#discussion_r1210359741

From serb at openjdk.org  Tue May 30 16:03:00 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 May 2023 16:03:00 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v12]
In-Reply-To: <Yhk53JKULUT9xQYYMUwvoTGasa_KP5j_kddBe2QnF9Y=.63727242-5cc4-4d45-9900-3493113ecace@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <Yhk53JKULUT9xQYYMUwvoTGasa_KP5j_kddBe2QnF9Y=.63727242-5cc4-4d45-9900-3493113ecace@github.com>
Message-ID: <wWsC_oa-CduWsb_7VghKtcheYbwDbMMiQavD1MIEF6Q=.4464897e-0828-4911-9713-6b4d4b4ef18e@github.com>

On Mon, 29 May 2023 16:05:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I would like to get preliminary feedback about the provided patch.
>> 
>> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
>> 
>> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.
>> 
>> At the moment this cache can be configured by the application using the following two properties:
>>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
>>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups
>> 
>> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".
>> 
>> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.
>> 
>> Possible solutions:
>>   1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
>>   2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
>>   3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.
>> 
>> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.
>> 
>> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.
>> 
>> 
>> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
>> https://www.rfc-editor.org/rfc/rfc8767
>> 
>> Comments about current and other possible implementations:
>>  * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
>>  * The refr...
>
> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

patch and the CSR are updated as requested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1568691635

From serb at openjdk.org  Tue May 30 16:03:02 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 May 2023 16:03:02 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v11]
In-Reply-To: <jPRRhl_eE0vP2G81IAyk6h3Ov5phpLJIKUcOO4kX1Jo=.ca1d04dc-aead-4858-bc14-8e839059e0fe@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <lUCyEJk_BJzBJvhDYgHPyuvuhGFp0YKC-uvhrZOlmVk=.944bc613-1df5-41ff-89e9-e0592a1c0259@github.com>
 <0nGTt5JIwhPP8i5pQTAhcc6cOIU7_8m6T3dRKxuAUtc=.482bdd55-b000-4827-9489-8826da9360fe@github.com>
 <NcBOtilRYbOj1BhqwN00W1M0QO2w1AQQizy3IWPFbAg=.f17c3b43-8d00-4079-9151-d198af39440b@github.com>
 <jPRRhl_eE0vP2G81IAyk6h3Ov5phpLJIKUcOO4kX1Jo=.ca1d04dc-aead-4858-bc14-8e839059e0fe@github.com>
Message-ID: <Wg9yUkJUPXZLWVncdL_OaRChrp5cFmf3-GhlszADIuU=.3ecbd897-80df-4f56-bba7-21cbe02f81f1@github.com>

On Mon, 29 May 2023 16:16:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> In the "java.security" file we documented the default value of the property in that file but it is commented out. Right now the new property specified in the same way as the old "networkaddress.cache.ttl", see [net-properties.html](https://github.com/openjdk/jdk/pull/13285/files/ce595f74f511553274c9da254d53b368abe44408#diff-21ffe1f9a665c0f70cc9888d2da937a2a77fadfdacc23d0bd59506595e668c5fR267) and [InetAddress.java](https://github.com/openjdk/jdk/pull/13285/files/a856cd36eba1efacbc0f95918ac6aa2712cab870#diff-55d4acc64110543896bf6c289d6247cded986edfe9ccce3a9bca88a197711d58R204)
>
> In the [InetAddress.java](https://github.com/openjdk/jdk/pull/13285/files/a856cd36eba1efacbc0f95918ac6aa2712cab870#diff-55d4acc64110543896bf6c289d6247cded986edfe9ccce3a9bca88a197711d58R204)
> 
>  * <dt><b>networkaddress.cache.ttl</b></dt>
>  * <dd>Indicates the caching policy for successful name lookups from
>  * the name service. The value is specified as an integer to indicate
>  * the number of seconds to cache the successful lookup. The default
>  * setting is to cache for an implementation specific period of time.
> 
> In the [java.security](https://github.com/openjdk/jdk/pull/13285/files/ce595f74f511553274c9da254d53b368abe44408#diff-)
> 
> # default value is forever (FOREVER). For security reasons, this
> # caching is made forever when a security manager is set. When a security
> # manager is not set, the default behavior in this implementation
> # is to cache for 30 seconds.

Such specification allows changing the default property in JDK bundle w/o changing the doc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1209450987

From dfuchs at openjdk.org  Tue May 30 16:05:04 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 May 2023 16:05:04 GMT
Subject: RFR: 8309120: java/net/httpclient/AsyncShutdownNow.java fails
 intermittently
Message-ID: <vOH_ds1zf_OB5LrIdgHDoPlcg0oyIer5UqyyixdoDVI=.04663cdc-c9a4-4e6f-9d86-8e2acc4c08ff@github.com>

Please find below a fix for a regression observed in the HttpClient AsyncShutdownNow test, after [JDK-8308310](https://bugs.openjdk.org/browse/JDK-8308310)

The PlainHttpConnection should have been modified to use a ReentrantLock instead of trying to perform potentially blocking actions outside of the synchronized block.

I also took this opportunity to fix the regex in the code that validate the exception message. The IOException thrown in that case has "Stream" with a capital "S".

-------------

Commit messages:
 - 8309120

Changes: https://git.openjdk.org/jdk/pull/14223/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14223&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309120
  Stats: 29 lines in 3 files changed: 16 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14223/head:pull/14223

PR: https://git.openjdk.org/jdk/pull/14223

From djelinski at openjdk.org  Tue May 30 16:19:58 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 30 May 2023 16:19:58 GMT
Subject: RFR: 8307648: java/net/httpclient/ExpectContinueTest.java timed
 out [v3]
In-Reply-To: <4vR72zceom9BrqKCGfe3noVagiTzG1g5aFv_qidd3XE=.5ddc8441-afc0-43a3-b92f-f1d264a459d2@github.com>
References: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
 <4vR72zceom9BrqKCGfe3noVagiTzG1g5aFv_qidd3XE=.5ddc8441-afc0-43a3-b92f-f1d264a459d2@github.com>
Message-ID: <GGHD4jWWMa-6dKnFXutqQ8AOHAi1VvJVEGTlp7Mz4dk=.02037d3e-907a-4707-b12a-080ea0cd95d4@github.com>

On Tue, 30 May 2023 14:17:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a fix for the java/net/httpclient/ExpectContinueTest.java which was failing intermittently.
>> 
>> It turns out there was two bugs here:
>> 
>> - on on the server side, which added the END_STREAM flag to the HeaderFrame containing the 100 response.
>>   This can obviously never be right since 100 is an intermediary response, which should be followed by a final response.
>>   
>> - on the client side, because this was interpreted as "there will be no body" - but it didn't prevent the client from waiting for the final response.
>> 
>> With this fix a 100 response carrying the END_STREAM flag will cause the exchange to be cancelled. I manually verified that this worked before fixing the server side.
>> 
>> The logic on server side is fixed to ignore whatever length is passed to sendResponseHeaders() if 100 is supplied, and to not add the END_STREAM flag to the HeaderFrame that carries the 100 response (which is a side effect of setting the expected length parameter to 0 in that case).
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   If RESET is received before the final response has been received the request should be cancelled too

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14207#pullrequestreview-1451337442

From dfuchs at openjdk.org  Tue May 30 16:35:04 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 May 2023 16:35:04 GMT
Subject: Integrated: 8307648: java/net/httpclient/ExpectContinueTest.java timed
 out
In-Reply-To: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
References: <tNI90fpocrkcPbyTQQ3rusRNSKOoMyHCv3qwXmZtRM8=.b5ac5088-a59b-4af4-b802-a4f94975e41e@github.com>
Message-ID: <mWDLjWBd7C7rkddR8hsEsE2FGxcZysILU75maHPE7iU=.8822e5ee-10d9-4120-979c-c0d52b699fb8@github.com>

On Mon, 29 May 2023 17:10:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a fix for the java/net/httpclient/ExpectContinueTest.java which was failing intermittently.
> 
> It turns out there was two bugs here:
> 
> - on on the server side, which added the END_STREAM flag to the HeaderFrame containing the 100 response.
>   This can obviously never be right since 100 is an intermediary response, which should be followed by a final response.
>   
> - on the client side, because this was interpreted as "there will be no body" - but it didn't prevent the client from waiting for the final response.
> 
> With this fix a 100 response carrying the END_STREAM flag will cause the exchange to be cancelled. I manually verified that this worked before fixing the server side.
> 
> The logic on server side is fixed to ignore whatever length is passed to sendResponseHeaders() if 100 is supplied, and to not add the END_STREAM flag to the HeaderFrame that carries the 100 response (which is a side effect of setting the expected length parameter to 0 in that case).

This pull request has now been integrated.

Changeset: 04b0e785
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04b0e785f6b9b4629b77bb19f2b072434be4951c
Stats:     68 lines in 3 files changed: 58 ins; 0 del; 10 mod

8307648: java/net/httpclient/ExpectContinueTest.java timed out

Reviewed-by: djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/14207

From dfuchs at openjdk.org  Tue May 30 16:40:09 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 May 2023 16:40:09 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance [v4]
In-Reply-To: <egcPdIfbnxpmtJXYGQQrkbhExiC7PPtaOxhgD8wuPNA=.93590282-2958-4bca-93f7-a9162e2b11fe@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
 <egcPdIfbnxpmtJXYGQQrkbhExiC7PPtaOxhgD8wuPNA=.93590282-2958-4bca-93f7-a9162e2b11fe@github.com>
Message-ID: <uVuFAtr_DfgWqVHwAS0zUS4pUWRz0V1vNt2lXo4i82M=.914412ff-a710-450a-8bf7-1690918ae96b@github.com>

On Thu, 25 May 2023 19:34:35 GMT, Dhamoder Nalla <duke at openjdk.org> wrote:

>> Issue 8305763 : Using underscores in the name for a URI triggers a silent exception in the java standard library, which consumes 5% of the CPU.
>> 
>> Exception:
>> java.net.URISyntaxException: Illegal character in hostname at index N: xyz1_abcd.com
>>     at java.base/java.net.URI$Parser.fail(URI.java:2943)
>>     at java.base/java.net.URI$Parser.parseHostname(URI.java:3487)
>>     at java.base/java.net.URI$Parser.parseServer(URI.java:3329)
>>     
>>     This exception is silent and does not produce any messages, except for ODP profiler, there is no other evidence that it?s happening (the stack trace above was printed after changes to Java library). The reason for this is because of how the URI creation is implemented in the java.net.URI class. There are two paths for creating a valid URI, and one of them goes through an exception.
>> 
>> We can see that if parseServer fails, there is still a way the authority gets assigned and we don?t throw an exception from the method. This means, not being able to parse the server is ok and the exception is silenced. In our case, the server parsing fails because we find an illegal character, as only alphanumeric and dash characters are allowed.
>
> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address CR comments

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13430#pullrequestreview-1451370843

From jpai at openjdk.org  Wed May 31 09:32:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 May 2023 09:32:58 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <KKyXuNgZPg0cGzCh1XcPcKuhSJ1fAm2WWdFlDscbNGA=.a7871386-5374-481d-b4f5-345e1b5cb7f7@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
 <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
 <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>
 <RCvm4JC-fpoR7bqrLdf2biktwyxX-5O9g81vRt0xy-c=.294b8c10-8634-4ea3-8fdb-71c6d918fdd0@github.com>
 <sz1ARwkmgyKicdVlKsVG2sXOCBFZYDxshlAEBd0LbKs=.f224ac95-b35b-4f1d-964c-af1ed565fbf0@github.com>
 <V69l5WRMZbFoOlnOBDAFHmHGc7x1Q_Htci4keiJPAig=.486d53f5-0ed9-4f60-a4ee-04457df74ac6@github.com>
 <Ff9qI39JwumYL0xlRRg_uQwbxMvsg6vx8HpxM6s1udU=.715b610d-5602-4c5f-9923-e2bbc4d62bb1@github.com>
 <cndcfh4TKzQCHXLTvxv5UZBnDNU59cSAfuXGlQ1bRhU=.6dba72c0-a0dd-47b9-a72f-d760df24d572@github.com>
 <qrrwzWfec6ldPPGIT-J_L1hKygXgAPil2bY
 uLO4HXoc=.afcf135f-7e20-4697-b9d0-9b7943dc5ecc@github.com>
 <KKyXuNgZPg0cGzCh1XcPcKuhSJ1fAm2WWdFlDscbNGA=.a7871386-5374-481d-b4f5-345e1b5cb7f7@github.com>
Message-ID: <hpMN_lrHExbMW3H_9ZQOnwWn0_-YsQGbPfn__WwDIt4=.a6caf09a-2292-48db-b8a4-027309ed03cd@github.com>

On Mon, 22 May 2023 18:01:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Ah! It's true only if the first time connect is called, it's implicitly by `initializeHeaders()` (sigh)...
>
> @Michael-Mc-Mahon what do you think?

Hello Jesse, Daniel, I had a look at the existing code in `sun.net.www.protocol.file.FileURLConnection` its super class `sun.net.www.URLConnection` and then its superclass `java.net.URLConnection`.

The various header related methods in `sun.net.www.URLConnection` first call the `getInputStream()` (and ignore that stream completely) and then check the `properties` field to get the header value. The call to `getInputStream()` is an internal implementation detail (since the `java.net.URLConnection` public APIs make no mention that it's required or will be called) and it seems to me that it's being called to make sure that the underlying resource is "connectable/available". The returned `InputStream` itself never gets used.

For the `FileURLConnection` class, the `InputStream` plays no role to populate these header fields. Yet, before the changes in this PR, it does end up creating an `InputStream` when trying to populate these header fields. I think the cleanest fix would be to not create this `InputStream` when populating these header fields (i.e. from `initializeHeaders()` method). That would mean that the `initializeHeaders()` wouldn't need to call the `connect()` method, like what's being proposed in this discussion thread. I think not calling `connect()` from `initializeHeaders()` (which gets called from various getHeader... methods) will still satisfy the specification because `java.net.URLConnection#connect()` method states:

>
>...
> Operations that depend on being connected, like getContentLength, will implicitly perform the connection, if necessary.

The "if necessary" in that sentence I think allows us to not "connect()" when populating and returning header fields.

I think the only place we should call connect() internally in this `FileURLConnection` is when `getInputStream()` method gets called on this class.

P.S: The current implementation in `initializeHeaders()` has some oddities. For example, if the `File` was a directory then in `connect()` we set `isDirectory()` as `true`. Then at some later point, when someone calls a getHeader... method and `initializeHeaders()` gets called, if the directory was deleted from the filesystem, then `initializeHeaders()` `exists` will be false, so it will go into the `if (!initializedHeaders || !exists) {` block but will still end up using the old outdated `isDirectory` flag to populate the `properties`. That's a different unrelated issue though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1211366626

From dfuchs at openjdk.org  Wed May 31 10:07:01 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 31 May 2023 10:07:01 GMT
Subject: RFR: JDK-6956385: URLConnection.getLastModified() leaks file
 handles for jar:file and file: URLs [v3]
In-Reply-To: <hpMN_lrHExbMW3H_9ZQOnwWn0_-YsQGbPfn__WwDIt4=.a6caf09a-2292-48db-b8a4-027309ed03cd@github.com>
References: <-EBiBT8IMzEF1Of8fZwlNIx68VHqJn0qdJFmoZbNN5w=.8009a74a-455d-40cf-88a1-7c52e8eab81e@github.com>
 <7SozQmhzyt-jWfREPcumfc9sIy9QUG11Fpel56IV8-s=.4d0bf074-9e22-40b1-a148-e8471bd6cf41@github.com>
 <ohiv_3fVJYwt5cEK6sgfHLKj6X_I-HoEn8Up6wH8yeA=.eb160338-a838-4ae8-a179-73ece0713597@github.com>
 <GTmqwrxIsYcxnthg5esn_uqwqKA0PEx7nTGZQPZlfGg=.70c0b96c-5147-4653-ab18-5da820db6bf7@github.com>
 <ynJNXIL0F1_OkkVlmHb6NCeXGmY4NxIl8WhZ-3eOAK0=.0713f019-097c-4f75-97b6-375728a0b6cb@github.com>
 <RCvm4JC-fpoR7bqrLdf2biktwyxX-5O9g81vRt0xy-c=.294b8c10-8634-4ea3-8fdb-71c6d918fdd0@github.com>
 <sz1ARwkmgyKicdVlKsVG2sXOCBFZYDxshlAEBd0LbKs=.f224ac95-b35b-4f1d-964c-af1ed565fbf0@github.com>
 <V69l5WRMZbFoOlnOBDAFHmHGc7x1Q_Htci4keiJPAig=.486d53f5-0ed9-4f60-a4ee-04457df74ac6@github.com>
 <Ff9qI39JwumYL0xlRRg_uQwbxMvsg6vx8HpxM6s1udU=.715b610d-5602-4c5f-9923-e2bbc4d62bb1@github.com>
 <cndcfh4TKzQCHXLTvxv5UZBnDNU59cSAfuXGlQ1bRhU=.6dba72c0-a0dd-47b9-a72f-d760df24d572@github.com>
 <qrrwzWfec6ldPPGIT-J_L1hKygXgAPil2bY
 uLO4HXoc=.afcf135f-7e20-4697-b9d0-9b7943dc5ecc@github.com>
 <KKyXuNgZPg0cGzCh1XcPcKuhSJ1fAm2WWdFlDscbNGA=.a7871386-5374-481d-b4f5-345e1b5cb7f7@github.com>
 <hpMN_lrHExbMW3H_9ZQOnwWn0_-YsQGbPfn__WwDIt4=.a6caf09a-2292-48db-b8a4-027309ed03cd@github.com>
Message-ID: <nATE7azCw8pUxsdyscMAPCPLq2D20zJf_TTPhBkzpKc=.bccc841f-2195-4269-8684-e236d8790616@github.com>

On Wed, 31 May 2023 09:29:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @Michael-Mc-Mahon what do you think?
>
> Hello Jesse, Daniel, I had a look at the existing code in `sun.net.www.protocol.file.FileURLConnection` its super class `sun.net.www.URLConnection` and then its superclass `java.net.URLConnection`.
> 
> The various header related methods in `sun.net.www.URLConnection` first call the `getInputStream()` (and ignore that stream completely) and then check the `properties` field to get the header value. The call to `getInputStream()` is an internal implementation detail (since the `java.net.URLConnection` public APIs make no mention that it's required or will be called) and it seems to me that it's being called to make sure that the underlying resource is "connectable/available". The returned `InputStream` itself never gets used.
> 
> For the `FileURLConnection` class, the `InputStream` plays no role to populate these header fields. Yet, before the changes in this PR, it does end up creating an `InputStream` when trying to populate these header fields. I think the cleanest fix would be to not create this `InputStream` when populating these header fields (i.e. from `initializeHeaders()` method). That would mean that the `initializeHeaders()` wouldn't need to call the `connect()` method, like what's being proposed in this discussion thread. I think not calling `connect()` from `initializeHeaders()` (which gets called from various getHeader... methods) will still satisfy the specification because `java.net.URLConnection#connect()` method states:
> 
>>
>>...
>> Operations that depend on being connected, like getContentLength, will implicitly perform the connection, if necessary.
> 
> The "if necessary" in that sentence I think allows us to not "connect()" when populating and returning header fields.
> 
> I think the only place we should call connect() internally in this `FileURLConnection` is when `getInputStream()` method gets called on this class.
> 
> P.S: The current implementation in `initializeHeaders()` has some oddities. For example, if the `File` was a directory then in `connect()` we set `isDirectory()` as `true`. Then at some later point, when someone calls a getHeader... method and `initializeHeaders()` gets called, if the directory was deleted from the filesystem, then `initializeHeaders()` `exists` will be false, so it will go into the `if (!initializedHeaders || !exists) {` block but will still end up using the old outdated `isDirectory` flag to populate the `properties`. That's a different unrelated issue though.

I believe we should wait for @Michael-Mc-Mahon input before reworking these methods to not call `connect()`. There seems to be an assumption that `connect()` would/should be called.
What I like with the current fix is that it's a very narrow fix which is unlikely to cause too much backward compatibility issues.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12871#discussion_r1211437025

From jpai at openjdk.org  Wed May 31 10:48:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 May 2023 10:48:54 GMT
Subject: RFR: 8309120: java/net/httpclient/AsyncShutdownNow.java fails
 intermittently
In-Reply-To: <vOH_ds1zf_OB5LrIdgHDoPlcg0oyIer5UqyyixdoDVI=.04663cdc-c9a4-4e6f-9d86-8e2acc4c08ff@github.com>
References: <vOH_ds1zf_OB5LrIdgHDoPlcg0oyIer5UqyyixdoDVI=.04663cdc-c9a4-4e6f-9d86-8e2acc4c08ff@github.com>
Message-ID: <zpyBrFNjAfNf1EbRSBq3exDdoAw46-zL1kV65XcxtEk=.13ac2921-92e3-4c21-833d-e77b270256da@github.com>

On Tue, 30 May 2023 15:57:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find below a fix for a regression observed in the HttpClient AsyncShutdownNow test, after [JDK-8308310](https://bugs.openjdk.org/browse/JDK-8308310)
> 
> The PlainHttpConnection should have been modified to use a ReentrantLock instead of trying to perform potentially blocking actions outside of the synchronized block.
> 
> I also took this opportunity to fix the regex in the code that validate the exception message. The IOException thrown in that case has "Stream" with a capital "S".

The change looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14223#pullrequestreview-1452862037

From dfuchs at openjdk.org  Wed May 31 10:52:04 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 31 May 2023 10:52:04 GMT
Subject: Integrated: 8309120: java/net/httpclient/AsyncShutdownNow.java fails
 intermittently
In-Reply-To: <vOH_ds1zf_OB5LrIdgHDoPlcg0oyIer5UqyyixdoDVI=.04663cdc-c9a4-4e6f-9d86-8e2acc4c08ff@github.com>
References: <vOH_ds1zf_OB5LrIdgHDoPlcg0oyIer5UqyyixdoDVI=.04663cdc-c9a4-4e6f-9d86-8e2acc4c08ff@github.com>
Message-ID: <nW7_Xz1xpEn3cLnyZZ4UGK8Z7ao750OL0yj87XccnTg=.586163f0-3a9d-4aab-b845-48b7c74c2cdf@github.com>

On Tue, 30 May 2023 15:57:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find below a fix for a regression observed in the HttpClient AsyncShutdownNow test, after [JDK-8308310](https://bugs.openjdk.org/browse/JDK-8308310)
> 
> The PlainHttpConnection should have been modified to use a ReentrantLock instead of trying to perform potentially blocking actions outside of the synchronized block.
> 
> I also took this opportunity to fix the regex in the code that validate the exception message. The IOException thrown in that case has "Stream" with a capital "S".

This pull request has now been integrated.

Changeset: 4aea7dab
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4aea7dab152de4c61724eec9a40024c990f8dabc
Stats:     29 lines in 3 files changed: 16 ins; 3 del; 10 mod

8309120: java/net/httpclient/AsyncShutdownNow.java fails intermittently

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14223

From dfuchs at openjdk.org  Wed May 31 17:00:23 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 31 May 2023 17:00:23 GMT
Subject: RFR: 8309200: java/net/httpclient/ExecutorShutdown fais
 intermittently, if connection closed during upgrade
Message-ID: <SozmQ7RvMCAlwxzR5KZpU75OhkHB3QzxiYvKK6rDgMw=.162e2cf7-f6b7-40ca-935c-b30128ed1f2e@github.com>

The ExecutorShutdown test has been observed failing intermittently, notably if by misfortune the shutdown sequence causes a connection to get aborted while upgrading. The issue is that the `ConnectionAborter` class that allows to mark the connection as being scheduled for closing before a handle to the connection is actually available isn't forwarding the original exception for which closing the connection was requested. When the connection is eventually closed, a generic `IOException: connection closed locally` is raised at the `SocketTube` level, which unfortunately can race with the original cause. 

The fix makes it possible to relay the original cause to the place where the IOException is raised, in order to set it as the cause of the new exception.

-------------

Commit messages:
 - 8309200

Changes: https://git.openjdk.org/jdk/pull/14251/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14251&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309200
  Stats: 61 lines in 7 files changed: 43 ins; 3 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/14251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14251/head:pull/14251

PR: https://git.openjdk.org/jdk/pull/14251

From duke at openjdk.org  Wed May 31 18:34:13 2023
From: duke at openjdk.org (Terry Chow)
Date: Wed, 31 May 2023 18:34:13 GMT
Subject: RFR: 8308593: Add Keepalive Extended Socket Options Support for
 Windows
Message-ID: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com>

The PR adds support for setting the keepalive extended socket options on Windows. The implemented native code uses the SIO_KEEPALIVE_VALS control code, which is how keepalive values are set on Windows and so there are a few caveats.

1. The keepalive time and keepalive interval must both be set at the same time. In the implementation, a new SioKeepAlive class and ExtendedSocketOptions is created to capture this behaviour for Windows only. Keepalive enablement must also be configured when using SIO_KEEPALIVE_VALS, and so by default when setting keepalive time and keepalive interval,
keepalive will automatically be enabled.

[SIO_KEEPALIVE_VALS doc](https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals)

2. It doesn't seem possible to acquire the Keepalive time and keepalive interval values on Windows. So, the implementation doesn't support acquiring the values.

https://stackoverflow.com/questions/14197347/how-to-query-socket-keep-alive-values-using-winsock/14198462#14198462
https://stackoverflow.com/questions/18391341/reading-sio-keepalive-vals-fields-on-a-windows-socket-for-keepalive-idle-and-in

3. Keepalive probes are not supported. On Windows Vista and later, the number of keep-alive probes is set to 10 and cannot be changed.

[SIO_KEEPALIVE_VALS Remarks](https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals#remarks)

For testing, I've updated the existing keepalive tests. But, since it's not possible to acquire the keepalive values on Windows to verify, I've indirectly tested setting the keepalive values by confirming keepalive is enabled where possible (since keepalive is enabled also when keepalive values are set).

-------------

Commit messages:
 - Corrected CRLF to LF for file
 - Windows keepAlive extended socket options

Changes: https://git.openjdk.org/jdk/pull/14232/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14232&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308593
  Stats: 176 lines in 11 files changed: 170 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14232/head:pull/14232

PR: https://git.openjdk.org/jdk/pull/14232

From aturbanov at openjdk.org  Wed May 31 19:01:43 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 31 May 2023 19:01:43 GMT
Subject: RFR: 8309200: java/net/httpclient/ExecutorShutdown fais
 intermittently, if connection closed during upgrade
In-Reply-To: <SozmQ7RvMCAlwxzR5KZpU75OhkHB3QzxiYvKK6rDgMw=.162e2cf7-f6b7-40ca-935c-b30128ed1f2e@github.com>
References: <SozmQ7RvMCAlwxzR5KZpU75OhkHB3QzxiYvKK6rDgMw=.162e2cf7-f6b7-40ca-935c-b30128ed1f2e@github.com>
Message-ID: <GLZhcWlZ645voNT5d6Yc_w7AAykQZv-DelW3QemKoQ8=.537121d5-ad42-4735-bfdf-0ea34014da0e@github.com>

On Wed, 31 May 2023 16:52:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The ExecutorShutdown test has been observed failing intermittently, notably if by misfortune the shutdown sequence causes a connection to get aborted while upgrading. The issue is that the `ConnectionAborter` class that allows to mark the connection as being scheduled for closing before a handle to the connection is actually available isn't forwarding the original exception for which closing the connection was requested. When the connection is eventually closed, a generic `IOException: connection closed locally` is raised at the `SocketTube` level, which unfortunately can race with the original cause. 
> 
> The fix makes it possible to relay the original cause to the place where the IOException is raised, in order to set it as the cause of the new exception.

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 167:

> 165:             Throwable cause;
> 166:             synchronized (this) {
> 167:                 if ((cause = this.cause) == null) {

let's extract the assignment to a separate statement. Code is a bit hard to read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14251#discussion_r1212154837

From alanb at openjdk.org  Wed May 31 19:03:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 May 2023 19:03:30 GMT
Subject: RFR: 8308593: Add Keepalive Extended Socket Options Support for
 Windows
In-Reply-To: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com>
References: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com>
Message-ID: <ZAQEzmLJuL_gpXtT9PzV9Uy7_9oKS9kXlfFtYa7eIDU=.0d71bdf9-77dc-4352-9460-f7607362f621@github.com>

On Tue, 30 May 2023 22:46:05 GMT, Terry Chow <duke at openjdk.org> wrote:

> The PR adds support for setting the keepalive extended socket options on Windows. The implemented native code uses the SIO_KEEPALIVE_VALS control code, which is how keepalive values are set on Windows and so there are a few caveats.
> 
> 1. The keepalive time and keepalive interval must both be set at the same time. In the implementation, a new SioKeepAlive class and ExtendedSocketOptions is created to capture this behaviour for Windows only. Keepalive enablement must also be configured when using SIO_KEEPALIVE_VALS, and so by default when setting keepalive time and keepalive interval,
> keepalive will automatically be enabled.
> 
> [SIO_KEEPALIVE_VALS doc](https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals)
> 
> 2. It doesn't seem possible to acquire the Keepalive time and keepalive interval values on Windows. So, the implementation doesn't support acquiring the values.
> 
> https://stackoverflow.com/questions/14197347/how-to-query-socket-keep-alive-values-using-winsock/14198462#14198462
> https://stackoverflow.com/questions/18391341/reading-sio-keepalive-vals-fields-on-a-windows-socket-for-keepalive-idle-and-in
> 
> 3. Keepalive probes are not supported. On Windows Vista and later, the number of keep-alive probes is set to 10 and cannot be changed.
> 
> [SIO_KEEPALIVE_VALS Remarks](https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals#remarks)
> 
> For testing, I've updated the existing keepalive tests. But, since it's not possible to acquire the keepalive values on Windows to verify, I've indirectly tested setting the keepalive values by confirming keepalive is enabled where possible (since keepalive is enabled also when keepalive values are set).

I think you may have missed my comment in the JBS issue where I asked about the semantics of SIO_KEEPALIVE_VALS and whether we could implement TCP_KEEPIDLE and TCP_KEEPINTERVAL on Windows by knowing what the defaults are. The proposal that you have here is a new Windows specific and JDK-specific socket option that requires a lot of thinking about before going that route.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14232#issuecomment-1570766242