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:
<9nvO7MHtyoB0Svr_CKsuiofe3hsNI2K9FAuIQBiRDc0=.0f95ab64-70b1-4879-a081-c58066c1f448@github.com>
Message-ID:
On Thu, 27 Apr 2023 12:08:53 GMT, Darragh Clarke 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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Wed, 3 May 2023 11:47:13 GMT, Darragh Clarke 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:
References:
Message-ID:
On Fri, 28 Apr 2023 15:13:35 GMT, Sergey Bylokhov 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:
References:
Message-ID:
On Wed, 3 May 2023 13:57:25 GMT, Michael McMahon 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:
References:
Message-ID:
> 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:
References:
Message-ID:
> ### 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
> Using git
>
> 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`
>
>
> Using Skara CLI tools
>
> Checkout this PR locally: \
> `$ git pr checkout 12694`
>
> View PR using the GUI difftool: \
> `$ git pr show -t 12694`
>
>
> Using diff file
>
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/12694.diff
>
>
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:
<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 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:
References:
Message-ID: <_CRXBAQc0nFB8BVKCpRZa_XMfR7yFakeQ-XKzeZTI6M=.26553ff2-4aa0-4915-857c-263b600e272d@github.com>
On Thu, 4 May 2023 15:07:12 GMT, Conor Cleary 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
>> Using git
>>
>> 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`
>>
>>
>> Using Skara CLI tools
>>
>> Checkout this PR locally: \
>> `$ git pr checkout 12694`
>>
>> View PR using the GUI difftool: \
>> `$ git pr show -t 12694`
>>
>>
>> Using diff file
>>
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/12694.diff
>>
>>
>
> 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:
<_CRXBAQc0nFB8BVKCpRZa_XMfR7yFakeQ-XKzeZTI6M=.26553ff2-4aa0-4915-857c-263b600e272d@github.com>
Message-ID:
On Thu, 4 May 2023 15:24:06 GMT, Daniel Fuchs 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:
References:
Message-ID:
On Thu, 4 May 2023 15:07:12 GMT, Conor Cleary 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
>> Using git
>>
>> 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`
>>
>>
>> Using Skara CLI tools
>>
>> Checkout this PR locally: \
>> `$ git pr checkout 12694`
>>
>> View PR using the GUI difftool: \
>> `$ git pr show -t 12694`
>>
>>
>> Using diff file
>>
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/12694.diff
>>
>>
>
> 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:
References:
Message-ID:
> 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:
References:
Message-ID:
> ### 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
> Using git
>
> 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`
>
>
> Using Skara CLI tools
>
> Checkout this PR locally: \
> `$ git pr checkout 12694`
>
> View PR using the GUI difftool: \
> `$ git pr show -t 12694`
>
>
> Using diff file
>
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/12694.diff
>
>
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:
References:
Message-ID:
On Wed, 3 May 2023 11:47:13 GMT, Darragh Clarke 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:
<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 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:
References:
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 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
>> Using git
>>
>> 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`
>>
>>
>> Using Skara CLI tools
>>
>> Checkout this PR locally: \
>> `$ git pr checkout 12694`
>>
>> View PR using the GUI difftool: \
>> `$ git pr show -t 12694`
>>
>>
>> Using diff file
>>
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/12694.diff
>>
>>
>
> 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:
<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 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:
`@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:
References:
Message-ID:
On Fri, 5 May 2023 08:54:26 GMT, Conor Cleary 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
>> Using git
>>
>> 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`
>>
>>
>> Using Skara CLI tools
>>
>> Checkout this PR locally: \
>> `$ git pr checkout 12694`
>>
>> View PR using the GUI difftool: \
>> `$ git pr show -t 12694`
>>
>>
>> Using diff file
>>
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/12694.diff
>>
>>
>
> 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:
References:
Message-ID:
On Fri, 5 May 2023 08:54:26 GMT, Conor Cleary 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
>> Using git
>>
>> 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`
>>
>>
>> Using Skara CLI tools
>>
>> Checkout this PR locally: \
>> `$ git pr checkout 12694`
>>
>> View PR using the GUI difftool: \
>> `$ git pr show -t 12694`
>>
>>
>> Using diff file
>>
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/12694.diff
>>
>>
>
> 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:
References:
Message-ID:
On Tue, 4 Apr 2023 17:02:08 GMT, Darragh Clarke 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
Committer: Daniel Jeli?ski
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:
References:
Message-ID:
On Tue, 21 Feb 2023 17:31:29 GMT, Conor Cleary 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
> Using git
>
> 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`
>
>
> Using Skara CLI tools
>
> Checkout this PR locally: \
> `$ git pr checkout 12694`
>
> View PR using the GUI difftool: \
> `$ git pr show -t 12694`
>
>
> Using diff file
>
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/12694.diff
>
>
This pull request has now been integrated.
Changeset: ad90fb6d
Author: Conor Cleary
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:
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:
References:
Message-ID:
On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger 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:
References:
Message-ID:
On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger 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:
References:
Message-ID:
On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger 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:
References:
Message-ID: <96PPtoUC3C26Ox6ABVtF9S64fZYi0HFRcHI8o_L4iAs=.950cfee3-ddb5-41ef-b2ca-6802c731a8a5@github.com>
On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger 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:
References:
Message-ID:
On Thu, 4 May 2023 06:05:20 GMT, Sergey Bylokhov 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: *
> 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: *
> 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:
References:
Message-ID:
On Thu, 4 May 2023 06:05:20 GMT, Sergey Bylokhov 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.
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.
-------------
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:
References:
Message-ID: <7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>
On Tue, 9 May 2023 13:53:53 GMT, Michael McMahon 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.
>
> 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.
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:
References:
Message-ID:
On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger 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:
References:
Message-ID:
On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger 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:
References:
Message-ID: <-ks9idC-Yt78xRIjwDfEfe2TEo6WCG96_HP16peuqwM=.638f9539-d827-4851-beb3-f2dfd013300e@github.com>
On Tue, 9 May 2023 10:38:54 GMT, Johannes Bechberger 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
Committer: Daniel Jeli?ski
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:
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:
References:
Message-ID:
On Wed, 10 May 2023 16:19:00 GMT, Daniel Fuchs 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:
References:
Message-ID:
> 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:
<7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>
Message-ID:
On Tue, 9 May 2023 13:56:34 GMT, Michael McMahon 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.
>>
>> 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.
>
> 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:
References:
<7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>
Message-ID: <0dVXh91AhVTmtCLu_oJygSKc5M9KjmYXgCgHfFDcEO8=.ec5c485e-f7cc-41af-82e2-537141871c40@github.com>
On Wed, 10 May 2023 22:05:37 GMT, Sergey Bylokhov 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:
References:
Message-ID:
On Wed, 10 May 2023 16:19:00 GMT, Daniel Fuchs 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:
References:
Message-ID:
On Wed, 10 May 2023 16:19:00 GMT, Daniel Fuchs 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:
References:
Message-ID:
On Wed, 10 May 2023 16:19:00 GMT, Daniel Fuchs 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
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:
> 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:
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID:
On Thu, 11 May 2023 20:21:57 GMT, Justin Lu 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:
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com>
On Thu, 11 May 2023 20:21:57 GMT, Justin Lu 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:
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:
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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Fri, 12 May 2023 17:57:43 GMT, Xue-Lei Andrew Fan 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:
References:
Message-ID:
On Mon, 15 May 2023 16:31:54 GMT, Daniel Fuchs 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:
References:
Message-ID: <5gmranDThlQlFLXa2i6t9E-z5tQrClncgNOErGSrfT8=.679ad5b9-ac56-418d-896f-1052fc6c4020@github.com>
On Fri, 12 May 2023 17:57:43 GMT, Xue-Lei Andrew Fan 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:
References:
Message-ID:
On Mon, 15 May 2023 16:31:54 GMT, Daniel Fuchs 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:
References:
Message-ID:
On Wed, 10 May 2023 21:58:52 GMT, Sergey Bylokhov 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:
References:
Message-ID: <44K4G3GthmHPWXC_5gFoh9hbZsMZwa5IgY2MUVh1Mwo=.e0eecfa0-269a-4332-a331-fb84342cf0a3@github.com>
On Mon, 15 May 2023 14:21:57 GMT, Daniel Fuchs 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
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:
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:
References:
Message-ID:
On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke 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:
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:
References:
Message-ID:
On Tue, 16 May 2023 13:36:15 GMT, Jaikiran Pai 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:
References:
Message-ID:
On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke 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:
References:
Message-ID:
On Wed, 10 May 2023 21:58:52 GMT, Sergey Bylokhov 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:
References:
Message-ID:
On Tue, 25 Apr 2023 18:20:16 GMT, Daniel Fuchs 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:
References:
Message-ID:
On Tue, 16 May 2023 13:36:15 GMT, Jaikiran Pai 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:
References:
Message-ID:
On Tue, 16 May 2023 13:36:15 GMT, Jaikiran Pai 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
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:
References:
Message-ID:
On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke 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:
References:
Message-ID:
> 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
- 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:
References:
Message-ID:
On Wed, 17 May 2023 10:41:57 GMT, Daniel Jeli?ski 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
>> - 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:
References:
Message-ID:
On Wed, 10 May 2023 21:58:52 GMT, Sergey Bylokhov 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 {
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:
<7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>
<0dVXh91AhVTmtCLu_oJygSKc5M9KjmYXgCgHfFDcEO8=.ec5c485e-f7cc-41af-82e2-537141871c40@github.com>
Message-ID:
On Wed, 10 May 2023 22:08:20 GMT, Sergey Bylokhov 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:
References:
Message-ID:
On Wed, 17 May 2023 13:51:23 GMT, Daniel Fuchs 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 {
>
> 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:
References:
<7syAx7uLWGyX-GdRZe8WIlymXQ_gIBUzLc02qKsDUT0=.d1efe224-4bbc-4c9f-886d-2dad15f55955@github.com>
<0dVXh91AhVTmtCLu_oJygSKc5M9KjmYXgCgHfFDcEO8=.ec5c485e-f7cc-41af-82e2-537141871c40@github.com>
Message-ID: <8HlyoqNh0_WszGqT9Y3OIvFhDOSE0zK6uflD5JewqcY=.35826ac8-e61e-496c-b545-01a4de78a987@github.com>
On Wed, 17 May 2023 14:08:18 GMT, Daniel Fuchs 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:
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:
References:
Message-ID:
On Wed, 17 May 2023 18:46:35 GMT, Daniel Fuchs 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:
References:
Message-ID:
On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke 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
> - 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:
References:
Message-ID:
> 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:
References:
Message-ID:
> 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:
References:
Message-ID:
> 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
- Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
Co-authored-by: Andrey Turbanov
- Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
Co-authored-by: Andrey Turbanov
-------------
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:
References:
Message-ID: <0GxhPfV9kjdGq_66qtf-4bnWOhVwd5wZKr4HVDbBvkE=.fd5017df-882c-48a8-b373-34d6204664a1@github.com>
On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke 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
> - 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:
References:
Message-ID:
On Thu, 18 May 2023 10:04:10 GMT, Daniel Fuchs 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
> - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>
> Co-authored-by: Andrey Turbanov
> - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>
> Co-authored-by: Andrey Turbanov
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:
References:
Message-ID:
On Thu, 18 May 2023 10:04:10 GMT, Daniel Fuchs 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
> - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>
> Co-authored-by: Andrey Turbanov
> - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>
> Co-authored-by: Andrey Turbanov
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 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:
References:
Message-ID:
On Thu, 18 May 2023 12:32:40 GMT, Andrey Turbanov 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
>> - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>>
>> Co-authored-by: Andrey Turbanov
>> - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>>
>> Co-authored-by: Andrey Turbanov
>
> 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 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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Thu, 18 May 2023 13:53:01 GMT, Daniel Fuchs 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 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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Thu, 18 May 2023 13:58:08 GMT, Andrey Turbanov 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:
References:
Message-ID:
> 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:
References:
Message-ID:
On Thu, 18 May 2023 15:07:04 GMT, Daniel Fuchs 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:
References:
Message-ID:
> 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:
References: