From jpai at openjdk.org  Mon Apr  1 07:33:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 1 Apr 2024 07:33:32 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally
In-Reply-To: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
Message-ID: <OqYsqiyGeI9P9X7YuevPoHd4CNTnqDjAavo4Lrin_Lo=.53b46a62-7a3c-4c2a-9916-a5558c2d2ecd@github.com>

On Wed, 27 Mar 2024 14:58:48 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
> 
> Changes:
> - Use try-with-resources to ensure streams close.
> - Use try-finally to make sure the server stops before the test exits.
> 
> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes

test/jdk/com/sun/net/httpserver/bugs/B6431193.java line 61:

> 59:                     os.write(response.getBytes());
> 60:                     os.close();
> 61:                     error = Thread.currentThread().isDaemon();

Hello Darragh, since we are updating this test, perhaps we should rename that variable to be a bit more precise? Looking at the history of this test, it was introduced to verify that the HTTP request was handled on the server side in a non-daemon thread. So perhaps rename that field to `handlerIsDaemon`? Then, the place where we assert this value, perhaps change it to:



if (handlerIsDaemon) {
    throw new RuntimeException ("request was handled by a daemon thread");
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18514#discussion_r1546050907

From serge.chernyshev at bell-sw.com  Mon Apr  1 08:49:50 2024
From: serge.chernyshev at bell-sw.com (Sergey Chernyshev)
Date: Mon, 1 Apr 2024 10:49:50 +0200
Subject: InetAddress API extension
In-Reply-To: <c72741ed-bc06-40c8-8002-677114266c5a@oracle.com>
References: <0078e435-2d23-4803-8828-fc5976544181@bell-sw.com>
 <c72741ed-bc06-40c8-8002-677114266c5a@oracle.com>
Message-ID: <51080508-49d1-462e-88b8-5345101ab5a5@bell-sw.com>

Hi Michael,

Thank you for your feeedback! The apidoc will clearly explain the 
difference in parsing methods and the set of ambiguous arguments.

Am 29.03.24 um 12:35 schrieb Michael McMahon:
>
> Hi,
>
> I think this could be a useful addition. The apidoc would need to be 
> clear about the differences from the existing literal parsing method 
> and any implications for ambiguity between octal and decimal formats 
> spelled out.
>
> On 28/03/2024 19:09, Sergey Chernyshev wrote:
>> It is suggested to add a new factory method such as 
>> |.ofPosixLiteral()| to |Inet4Address| class to fill this gap. This 
>> won't introduce ambiguity into the API and won't break the long 
>> standing behavior. As a new method, it will not affect Java utilities 
>> such as HttpClient, nor the existing Java applications. At the same 
>> time, the new method will help dealing with confusion between BSD and 
>> Java standards. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240401/e6863e76/attachment.htm>

From dclarke at openjdk.org  Tue Apr  2 11:55:12 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 2 Apr 2024 11:55:12 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally [v2]
In-Reply-To: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
Message-ID: <RoIxw1OZHcc9Prnb7FQtQIlKujcn30uqsfVaDGAZF6A=.46918bc3-dade-4bae-af41-cf909a18633c@github.com>

> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
> 
> Changes:
> - Use try-with-resources to ensure streams close.
> - Use try-finally to make sure the server stops before the test exits.
> 
> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes

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

  implemented feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18514/files
  - new: https://git.openjdk.org/jdk/pull/18514/files/8e0374e0..1294dbc0

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

  Stats: 12 lines in 1 file changed: 1 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18514/head:pull/18514

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

From dclarke at openjdk.org  Tue Apr  2 11:55:12 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 2 Apr 2024 11:55:12 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally
In-Reply-To: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
Message-ID: <3pldQ2hcOMERuudXun8U9mSW826hPP3VLTkM03AqzQY=.b16c5ba9-4fe7-4e7b-9cff-9441f757e58c@github.com>

On Wed, 27 Mar 2024 14:58:48 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
> 
> Changes:
> - Use try-with-resources to ensure streams close.
> - Use try-finally to make sure the server stops before the test exits.
> 
> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes

Thanks for the suggestions, I've implemented those changes and reran tests to make sure everything is still stable.

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

PR Comment: https://git.openjdk.org/jdk/pull/18514#issuecomment-2031838939

From dfuchs at openjdk.org  Tue Apr  2 13:30:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 2 Apr 2024 13:30:12 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally [v2]
In-Reply-To: <RoIxw1OZHcc9Prnb7FQtQIlKujcn30uqsfVaDGAZF6A=.46918bc3-dade-4bae-af41-cf909a18633c@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
 <RoIxw1OZHcc9Prnb7FQtQIlKujcn30uqsfVaDGAZF6A=.46918bc3-dade-4bae-af41-cf909a18633c@github.com>
Message-ID: <7987MrssE_she0cm6-nryQtj36RFE21-_eEVpmr9c5M=.7a6483da-a002-4c3a-aed4-d0d507f7ca39@github.com>

On Tue, 2 Apr 2024 11:55:12 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
>> 
>> Changes:
>> - Use try-with-resources to ensure streams close.
>> - Use try-finally to make sure the server stops before the test exits.
>> 
>> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implemented feedback

Changes requested by dfuchs (Reviewer).

test/jdk/com/sun/net/httpserver/bugs/B6431193.java line 67:

> 65:             server.setExecutor(null);
> 66:             // creates a default executor
> 67:             server.start();

server.start() (and what preceeds) should be called before entering the try block

test/jdk/com/sun/net/httpserver/bugs/B6431193.java line 77:

> 75:             InputStream is = url.openConnection(Proxy.NO_PROXY).getInputStream();
> 76:             is.readAllBytes();
> 77:             is.close();

you should use try-with-resource here

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

PR Review: https://git.openjdk.org/jdk/pull/18514#pullrequestreview-1973805927
PR Review Comment: https://git.openjdk.org/jdk/pull/18514#discussion_r1547878491
PR Review Comment: https://git.openjdk.org/jdk/pull/18514#discussion_r1547882135

From dfuchs at openjdk.org  Tue Apr  2 13:30:13 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 2 Apr 2024 13:30:13 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally [v2]
In-Reply-To: <MShDgKgSVpwggNPhfCyu9Ja39hGkdY8Yi5c2bZIH4DA=.ddc68a8f-8e8e-4b30-b54b-6145af8065f0@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
 <MShDgKgSVpwggNPhfCyu9Ja39hGkdY8Yi5c2bZIH4DA=.ddc68a8f-8e8e-4b30-b54b-6145af8065f0@github.com>
Message-ID: <jnnK4pR4m8JRzW22HBg-IA8VgIZTegg4rVsXne5Qs0s=.071e8532-3f81-43ed-8e45-1a0fad80353b@github.com>

On Wed, 27 Mar 2024 15:11:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   implemented feedback
>
> test/jdk/com/sun/net/httpserver/bugs/B6431193.java line 60:
> 
>> 58:                     t.sendResponseHeaders(200, response.length());
>> 59:                     os.write(response.getBytes());
>> 60:                     os.close();
> 
> no need to call `os.close()` here since it will be called by the `try ( ) { }` block.

line with `os.close()` should be removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18514#discussion_r1547882399

From dclarke at openjdk.org  Tue Apr  2 13:59:09 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 2 Apr 2024 13:59:09 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally [v2]
In-Reply-To: <jnnK4pR4m8JRzW22HBg-IA8VgIZTegg4rVsXne5Qs0s=.071e8532-3f81-43ed-8e45-1a0fad80353b@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
 <MShDgKgSVpwggNPhfCyu9Ja39hGkdY8Yi5c2bZIH4DA=.ddc68a8f-8e8e-4b30-b54b-6145af8065f0@github.com>
 <jnnK4pR4m8JRzW22HBg-IA8VgIZTegg4rVsXne5Qs0s=.071e8532-3f81-43ed-8e45-1a0fad80353b@github.com>
Message-ID: <QKeAPbKvivXePniwR_3uau_r4XmWjAdhSKtcoiPZqcs=.a21d876d-54e4-411c-b2f8-7dafbc569a58@github.com>

On Tue, 2 Apr 2024 13:25:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/bugs/B6431193.java line 60:
>> 
>>> 58:                     t.sendResponseHeaders(200, response.length());
>>> 59:                     os.write(response.getBytes());
>>> 60:                     os.close();
>> 
>> no need to call `os.close()` here since it will be called by the `try ( ) { }` block.
>
> line with `os.close()` should be removed

Sorry for missing that one on the last PR, removing it now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18514#discussion_r1547944596

From jpai at openjdk.org  Tue Apr  2 15:04:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 15:04:13 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally [v2]
In-Reply-To: <RoIxw1OZHcc9Prnb7FQtQIlKujcn30uqsfVaDGAZF6A=.46918bc3-dade-4bae-af41-cf909a18633c@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
 <RoIxw1OZHcc9Prnb7FQtQIlKujcn30uqsfVaDGAZF6A=.46918bc3-dade-4bae-af41-cf909a18633c@github.com>
Message-ID: <w1Ll8i1vnn7pOXF51CX--v7rGm1MC6467TJMMNtD3so=.8794f9b8-b28a-465c-a52a-949c68f3cb13@github.com>

On Tue, 2 Apr 2024 11:55:12 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
>> 
>> Changes:
>> - Use try-with-resources to ensure streams close.
>> - Use try-finally to make sure the server stops before the test exits.
>> 
>> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implemented feedback

Darragh, one other thing - I haven't paid close attention to this test, so can't say for certain - are we sure that when the test code reaches the place where we assert on `handlerIsDaemon` field, the `MyHandler.handle()` was indeed invoked? A quick look at that test didn't convince me that this code:


InputStream is = url.openConnection(Proxy.NO_PROXY).getInputStream();
            read (is);

is enough to guarantee that the handler was invoked.

I would have looked at the test code and the HttpURLConnection implementation myself, but I need to head out now.

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

PR Comment: https://git.openjdk.org/jdk/pull/18514#issuecomment-2032290965

From dclarke at openjdk.org  Tue Apr  2 16:01:13 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 2 Apr 2024 16:01:13 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally [v2]
In-Reply-To: <RoIxw1OZHcc9Prnb7FQtQIlKujcn30uqsfVaDGAZF6A=.46918bc3-dade-4bae-af41-cf909a18633c@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
 <RoIxw1OZHcc9Prnb7FQtQIlKujcn30uqsfVaDGAZF6A=.46918bc3-dade-4bae-af41-cf909a18633c@github.com>
Message-ID: <mie4yvy7SAk9j0etBsnb20Ydcodkehz8z5DIteQKris=.039e0649-1683-40b5-b8dc-edaf2c85842b@github.com>

On Tue, 2 Apr 2024 11:55:12 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
>> 
>> Changes:
>> - Use try-with-resources to ensure streams close.
>> - Use try-finally to make sure the server stops before the test exits.
>> 
>> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implemented feedback

> Darragh, one other thing - I haven't paid close attention to this test, so can't say for certain - are we sure that when the test code reaches the place where we assert on `handlerIsDaemon` field, the `MyHandler.handle()` was indeed invoked? A quick look at that test didn't convince me that this code:
> 
> ```java
> InputStream is = url.openConnection(Proxy.NO_PROXY).getInputStream();
>             read (is);
> ```
> 
> is enough to guarantee that the handler was invoked.
> 
> I would have looked at the test code and the HttpURLConnection implementation myself, but I need to head out now.

That's a good point, from my testing it seems to consistently be reached but I'm not sure if it's 100% guaranteed. Would a `CountDownLatch` be useful here maybe, something like this?


} finally {
     handlerIsDaemon = Thread.currentThread().isDaemon();
     latch.countDown();
} 
 ```

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

PR Comment: https://git.openjdk.org/jdk/pull/18514#issuecomment-2032446404

From jpai at openjdk.org  Thu Apr  4 11:05:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 4 Apr 2024 11:05:59 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally [v2]
In-Reply-To: <RoIxw1OZHcc9Prnb7FQtQIlKujcn30uqsfVaDGAZF6A=.46918bc3-dade-4bae-af41-cf909a18633c@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
 <RoIxw1OZHcc9Prnb7FQtQIlKujcn30uqsfVaDGAZF6A=.46918bc3-dade-4bae-af41-cf909a18633c@github.com>
Message-ID: <4_RhIY4lzbfFKW2QBWboXAHS0py74hnVv6YWxHg3ces=.a50d61f7-52b9-46d0-9bca-ab90944530b1@github.com>

On Tue, 2 Apr 2024 11:55:12 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
>> 
>> Changes:
>> - Use try-with-resources to ensure streams close.
>> - Use try-finally to make sure the server stops before the test exits.
>> 
>> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implemented feedback

Hello Darragh,

> That's a good point, from my testing it seems to consistently be reached but I'm not sure if it's 100% guaranteed. Would a CountDownLatch be useful here maybe, something like this?

I ran some experiments with this test and it appears that if the handler isn't invoked then we won't reach the place where we assert the `handlerIsDaemon` field. So I think the current form is OK (of course, the PR needs a couple of updates suggested by Daniel). 

Just as an extra precaution, what you could perhaps do is initialize `handlerIsDaemon` to `true` instead of the current `false`. That way it will only be set to `false` (the expected value) only when the handler is invoked in a non daemon thread.

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

PR Comment: https://git.openjdk.org/jdk/pull/18514#issuecomment-2036858656

From jpai at openjdk.org  Thu Apr  4 11:54:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 4 Apr 2024 11:54:19 GMT
Subject: RFR: 8329662: Add a test to verify the behaviour of the default HEAD()
 method on HttpRequest.Builder
Message-ID: <cLVOH8A6CABA_4vQ49YZqeKdjjEBYy9f7qU6CVmphDc=.22878b72-8448-4cfa-92bf-49454e4cdca8@github.com>

Can I please get a review of this test-only change which updates an existing test case to verify the behaviour of `HttpRequest.Builder.HEAD()` method?

As noted in https://bugs.openjdk.org/browse/JDK-8329662, this test now verifies the default implementation specified for `HttpRequest.Builder.HEAD()`. The existing tests were only verifing the behaviour of the `HEAD()` method implementation in the class of the instance returned from `HttpRequest.newBuilder()`. 

I have run this test in our CI with these changes and the test continues to pass.

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

Commit messages:
 - 8329662: Add a test to verify the behaviour of the default HEAD() method on HttpRequest.Builder

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

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

From rengels at ix.netcom.com  Thu Apr  4 12:54:58 2024
From: rengels at ix.netcom.com (Robert Engels)
Date: Thu, 4 Apr 2024 07:54:58 -0500
Subject: HttpServer performance issue / improvement
Message-ID: <083E4B9D-DBC5-4C31-A91A-CE9CBEE5AFCD@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240404/8a804bfc/attachment.htm>

From rengels at ix.netcom.com  Thu Apr  4 12:54:44 2024
From: rengels at ix.netcom.com (Robert Engels)
Date: Thu, 4 Apr 2024 07:54:44 -0500
Subject: HttpServer performance issue / improvement
Message-ID: <44ACA812-9680-4180-BE84-6D2E33F6CF71@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240404/8e9caa64/attachment-0001.htm>

From djelinski1 at gmail.com  Thu Apr  4 14:44:54 2024
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Thu, 4 Apr 2024 16:44:54 +0200
Subject: HttpServer performance issue / improvement
In-Reply-To: <083E4B9D-DBC5-4C31-A91A-CE9CBEE5AFCD@ix.netcom.com>
References: <083E4B9D-DBC5-4C31-A91A-CE9CBEE5AFCD@ix.netcom.com>
Message-ID: <CAMrH03J6bL_LWjjJi7aMROzovAhEgKErM-yWLabpQVXAzxNx=g@mail.gmail.com>

Hi Robert,
Thanks for bringing this up! We are aware of the issue, it's tracked under
https://bugs.openjdk.org/browse/JDK-6968351.

If you have an idea for a proper fix that doesn't add too much complexity,
please open a PR, and we'll be happy to help.
Cheers,
Daniel

czw., 4 kwi 2024, 14:55 u?ytkownik Robert Engels <rengels at ix.netcom.com>
napisa?:

> ?
> ?When doing some testing on github.com/robaho/httpserver - which is a
> fork of the jdk http server, I discovered a significant performance issue.
>
> When an http connection is in ?keep-alive? - the default for http 1.1 -
> the headers are ?flushed? here
> https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L281
>
> This means that after the handler runs and it sends data - e.g. /hello
> sends ?hello? on the connection, the connection will stall due to the Nagel
> algorithm - usually incurring a 50 ms delay. The stall occurs since the
> client will not see the expected data until after the delay, so it is
> unable to send the next (when reusing the same connection/HttpClient).
>
> You can set the TCP_NODELAY on the server to work-around this, but a
> better solution would be to override the flush() on the
> BufferedOutputStream to not flush() the underlying connection - i.e. only
> write the buffered bytes, or rework it a bit to only flush when there is no
> content to send.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240404/c6b78a91/attachment.htm>

From dfuchs at openjdk.org  Thu Apr  4 16:34:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 4 Apr 2024 16:34:11 GMT
Subject: RFR: 8329662: Add a test to verify the behaviour of the default
 HEAD() method on HttpRequest.Builder
In-Reply-To: <cLVOH8A6CABA_4vQ49YZqeKdjjEBYy9f7qU6CVmphDc=.22878b72-8448-4cfa-92bf-49454e4cdca8@github.com>
References: <cLVOH8A6CABA_4vQ49YZqeKdjjEBYy9f7qU6CVmphDc=.22878b72-8448-4cfa-92bf-49454e4cdca8@github.com>
Message-ID: <mz-LN-UxjnZx3gW-SBoSV1KhjyM4Y31oEPfNdknzXF0=.a787ab99-76e3-451a-b059-4b6d0a66dafb@github.com>

On Thu, 4 Apr 2024 11:50:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which updates an existing test case to verify the behaviour of `HttpRequest.Builder.HEAD()` method?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329662, this test now verifies the default implementation specified for `HttpRequest.Builder.HEAD()`. The existing tests were only verifing the behaviour of the `HEAD()` method implementation in the class of the instance returned from `HttpRequest.newBuilder()`. 
> 
> I have run this test in our CI with these changes and the test continues to pass.

LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/18622#pullrequestreview-1980502348

From jpai at openjdk.org  Fri Apr  5 07:01:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 07:01:20 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions to
 direct to java.net.StandardSocketOptions
Message-ID: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>

Can I please get a review of this doc-only change which proposes to clean up the documentation of `java.net.SocketOptions` interface?

As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing documentation in this legacy interface isn't accurate. The commit in this PR, updates the documentation on several of the fields to point to the newer java.net.StandardSocketOptions class. While at it, I also did a general update of this documentation to use snippets and also reword some of it to be a bit more clear.

I have run `make docs-image` on this change and the updated doc looks fine to me.

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

Commit messages:
 - 8329733: Update the documentation in java.net.SocketOptions to direct to java.net.StandardSocketOptions

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

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

From jpai at openjdk.org  Fri Apr  5 07:36:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 07:36:31 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket to
 refer to StandardSocketOptions instead of legacy SocketOptions
Message-ID: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>

Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?

As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).

I ran `make docs-image` locally with this change and the generated doc looks OK to me.

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

Commit messages:
 - 8329745: Update the documentation of ServerSocket and Socket to refer to StandardSocketOptions instead of legacy SocketOptions

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

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

From djelinski at openjdk.org  Fri Apr  5 10:19:13 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 5 Apr 2024 10:19:13 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions
In-Reply-To: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
Message-ID: <GpAigQBbDFturO4O-54nBtOU819ddzcQJ1QFcvA5hWM=.69c88df5-5129-4e57-a72c-e723938257c9@github.com>

On Fri, 5 Apr 2024 06:56:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to clean up the documentation of `java.net.SocketOptions` interface?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing documentation in this legacy interface isn't accurate. The commit in this PR, updates the documentation on several of the fields to point to the newer java.net.StandardSocketOptions class. While at it, I also did a general update of this documentation to use snippets and also reword some of it to be a bit more clear.
> 
> I have run `make docs-image` on this change and the updated doc looks fine to me.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18645#pullrequestreview-1982603976

From alanb at openjdk.org  Fri Apr  5 10:32:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Apr 2024 10:32:00 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions
In-Reply-To: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
Message-ID: <xDvJkdBlBpxIA2dD-UwI_SJxYV8aBZDdYAHWK4jk--A=.9fdfc1c4-3e37-413c-ae3b-e5ea39d2ca9f@github.com>

On Fri, 5 Apr 2024 06:56:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to clean up the documentation of `java.net.SocketOptions` interface?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing documentation in this legacy interface isn't accurate. The commit in this PR, updates the documentation on several of the fields to point to the newer java.net.StandardSocketOptions class. While at it, I also did a general update of this documentation to use snippets and also reword some of it to be a bit more clear.
> 
> I have run `make docs-image` on this change and the updated doc looks fine to me.

src/java.base/share/classes/java/net/SocketOptions.java line 37:

> 35:  * <P>
> 36:  * The methods and constants defined in this interface are
> 37:  * for internal implementation use only. If you're not subclassing {@code SocketImpl} or

I don't think we can insert the word "internal" here it's part of the exposed interface for this legacy mechanism.

src/java.base/share/classes/java/net/SocketOptions.java line 168:

> 166: 
> 167:     /**
> 168:      * Set the outgoing interface on which to send multicast packets. Useful on hosts with

This option is used to both set and get the outgoing network interface.

src/java.base/share/classes/java/net/SocketOptions.java line 199:

> 197: 
> 198:     /**
> 199:      * Set a timeout on blocking {@code Socket} operations:

This option is also used to set and get the timeout value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18645#discussion_r1553347140
PR Review Comment: https://git.openjdk.org/jdk/pull/18645#discussion_r1553354819
PR Review Comment: https://git.openjdk.org/jdk/pull/18645#discussion_r1553355367

From alanb at openjdk.org  Fri Apr  5 10:41:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Apr 2024 10:41:09 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions
In-Reply-To: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
Message-ID: <h4yF_lppgbgW5uAESp1CMqSY-qeNJQJNF8fgLeb0bcU=.b2a0af04-62bb-4b3b-ac90-99f5e01fb53d@github.com>

On Fri, 5 Apr 2024 07:31:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
> 
> I ran `make docs-image` locally with this change and the generated doc looks OK to me.

src/java.base/share/classes/java/net/ServerSocket.java line 867:

> 865:      * setting of {@link StandardSocketOptions#SO_REUSEADDR SO_REUSEADDR}.
> 866:      * <p>
> 867:      * The behaviour when {@link StandardSocketOptions#SO_REUSEADDR SO_REUSEADDR} is

I suppose the main question here is whether the description really needs to link to SO_REUSEADDR five times, it seems a bit excessive. In cases like this I tend to just have the first usage link, others do it differently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18646#discussion_r1553379147

From jpai at openjdk.org  Fri Apr  5 11:32:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 11:32:10 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions
In-Reply-To: <h4yF_lppgbgW5uAESp1CMqSY-qeNJQJNF8fgLeb0bcU=.b2a0af04-62bb-4b3b-ac90-99f5e01fb53d@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <h4yF_lppgbgW5uAESp1CMqSY-qeNJQJNF8fgLeb0bcU=.b2a0af04-62bb-4b3b-ac90-99f5e01fb53d@github.com>
Message-ID: <QlrRWJngbAU-_i4woZisJv-hdupVMvwouYrwo152kCA=.600d9317-f59c-4ebe-80a9-2903784da1f5@github.com>

On Fri, 5 Apr 2024 10:38:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
>> 
>> I ran `make docs-image` locally with this change and the generated doc looks OK to me.
>
> src/java.base/share/classes/java/net/ServerSocket.java line 867:
> 
>> 865:      * setting of {@link StandardSocketOptions#SO_REUSEADDR SO_REUSEADDR}.
>> 866:      * <p>
>> 867:      * The behaviour when {@link StandardSocketOptions#SO_REUSEADDR SO_REUSEADDR} is
> 
> I suppose the main question here is whether the description really needs to link to SO_REUSEADDR five times, it seems a bit excessive. In cases like this I tend to just have the first usage link, others do it differently.

Hello Alan, I too typically follow the process of linking once and then using `{@code SO_REUSEADDR}`. I let it stay in this form since it was already that way. I'll go ahead and update it to link only once.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18646#discussion_r1553462959

From jpai at openjdk.org  Fri Apr  5 11:49:25 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 11:49:25 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions [v2]
In-Reply-To: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
Message-ID: <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>

> Can I please get a review of this doc-only change which proposes to clean up the documentation of `java.net.SocketOptions` interface?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing documentation in this legacy interface isn't accurate. The commit in this PR, updates the documentation on several of the fields to point to the newer java.net.StandardSocketOptions class. While at it, I also did a general update of this documentation to use snippets and also reword some of it to be a bit more clear.
> 
> I have run `make docs-image` on this change and the updated doc looks fine to me.

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - "timeout value" instead of "timeout"
 - missed SO_TIMEOUT review suggestion in previous commit
 - Alan's review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18645/files
  - new: https://git.openjdk.org/jdk/pull/18645/files/2280b10f..0e6772ec

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

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

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

From jpai at openjdk.org  Fri Apr  5 11:49:25 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 11:49:25 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions [v2]
In-Reply-To: <xDvJkdBlBpxIA2dD-UwI_SJxYV8aBZDdYAHWK4jk--A=.9fdfc1c4-3e37-413c-ae3b-e5ea39d2ca9f@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
 <xDvJkdBlBpxIA2dD-UwI_SJxYV8aBZDdYAHWK4jk--A=.9fdfc1c4-3e37-413c-ae3b-e5ea39d2ca9f@github.com>
Message-ID: <D6Vv-m03MTX3ag8fOCcDYqfc1X9YJWbQ1AZGFSqQToo=.c74ffd94-3938-4d41-b683-23ab69e8d2c0@github.com>

On Fri, 5 Apr 2024 10:22:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - "timeout value" instead of "timeout"
>>  - missed SO_TIMEOUT review suggestion in previous commit
>>  - Alan's review suggestions
>
> src/java.base/share/classes/java/net/SocketOptions.java line 37:
> 
>> 35:  * <P>
>> 36:  * The methods and constants defined in this interface are
>> 37:  * for internal implementation use only. If you're not subclassing {@code SocketImpl} or
> 
> I don't think we can insert the word "internal" here it's part of the exposed interface for this legacy mechanism.

I've now updated the PR to remove the "internal" word that was introduced as part of this change.

> src/java.base/share/classes/java/net/SocketOptions.java line 168:
> 
>> 166: 
>> 167:     /**
>> 168:      * Set the outgoing interface on which to send multicast packets. Useful on hosts with
> 
> This option is used to both set and get the outgoing network interface.

Updated the PR to state it can be used to both set and get the interface.

> src/java.base/share/classes/java/net/SocketOptions.java line 199:
> 
>> 197: 
>> 198:     /**
>> 199:      * Set a timeout on blocking {@code Socket} operations:
> 
> This option is also used to set and get the timeout value.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18645#discussion_r1553480930
PR Review Comment: https://git.openjdk.org/jdk/pull/18645#discussion_r1553481472
PR Review Comment: https://git.openjdk.org/jdk/pull/18645#discussion_r1553487255

From jpai at openjdk.org  Fri Apr  5 12:06:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 12:06:21 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v2]
In-Reply-To: <QlrRWJngbAU-_i4woZisJv-hdupVMvwouYrwo152kCA=.600d9317-f59c-4ebe-80a9-2903784da1f5@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <h4yF_lppgbgW5uAESp1CMqSY-qeNJQJNF8fgLeb0bcU=.b2a0af04-62bb-4b3b-ac90-99f5e01fb53d@github.com>
 <QlrRWJngbAU-_i4woZisJv-hdupVMvwouYrwo152kCA=.600d9317-f59c-4ebe-80a9-2903784da1f5@github.com>
Message-ID: <LzbwfW--j4bp3vdAcdw492OJbH3d9s-2Cqnmr9KHL7Y=.b49dd357-52b7-41c2-8b0a-2f7c85e77840@github.com>

On Fri, 5 Apr 2024 11:29:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/ServerSocket.java line 867:
>> 
>>> 865:      * setting of {@link StandardSocketOptions#SO_REUSEADDR SO_REUSEADDR}.
>>> 866:      * <p>
>>> 867:      * The behaviour when {@link StandardSocketOptions#SO_REUSEADDR SO_REUSEADDR} is
>> 
>> I suppose the main question here is whether the description really needs to link to SO_REUSEADDR five times, it seems a bit excessive. In cases like this I tend to just have the first usage link, others do it differently.
>
> Hello Alan, I too typically follow the process of linking once and then using `{@code SO_REUSEADDR}`. I let it stay in this form since it was already that way. I'll go ahead and update it to link only once.

Done - I've updated the PR to remove the repeated links.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18646#discussion_r1553507116

From jpai at openjdk.org  Fri Apr  5 12:06:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 12:06:21 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v2]
In-Reply-To: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
Message-ID: <js_7lfD5tDghamBAiLqKBXbGe1ufEw-Impq4i1IH12k=.aa89fb37-36f3-411f-a381-fe52df32c3b9@github.com>

> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
> 
> I ran `make docs-image` locally with this change and the generated doc looks OK to me.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove repeated usages of {@link}

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18646/files
  - new: https://git.openjdk.org/jdk/pull/18646/files/0e393c88..46ece095

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

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

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

From alanb at openjdk.org  Fri Apr  5 12:22:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Apr 2024 12:22:02 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v2]
In-Reply-To: <js_7lfD5tDghamBAiLqKBXbGe1ufEw-Impq4i1IH12k=.aa89fb37-36f3-411f-a381-fe52df32c3b9@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <js_7lfD5tDghamBAiLqKBXbGe1ufEw-Impq4i1IH12k=.aa89fb37-36f3-411f-a381-fe52df32c3b9@github.com>
Message-ID: <fYIM3NI_ItxRM_42u2J4eThLl-B4fajk1rDWmrQtYac=.ee86ed01-ebeb-43cb-ae90-ef7ac61ebdac@github.com>

On Fri, 5 Apr 2024 12:06:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
>> 
>> I ran `make docs-image` locally with this change and the generated doc looks OK to me.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove repeated usages of {@link}

src/java.base/share/classes/java/net/ServerSocket.java line 264:

> 262:      *             0 and 65535, inclusive.
> 263:      *
> 264:      * @see StandardSocketOptions

What would you think about dropping this link, and the link to SocketImpl from all the constructors, they aren't relevant for anyone reading this part of the docs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18646#discussion_r1553527158

From jpai at openjdk.org  Fri Apr  5 12:45:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 12:45:09 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v2]
In-Reply-To: <fYIM3NI_ItxRM_42u2J4eThLl-B4fajk1rDWmrQtYac=.ee86ed01-ebeb-43cb-ae90-ef7ac61ebdac@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <js_7lfD5tDghamBAiLqKBXbGe1ufEw-Impq4i1IH12k=.aa89fb37-36f3-411f-a381-fe52df32c3b9@github.com>
 <fYIM3NI_ItxRM_42u2J4eThLl-B4fajk1rDWmrQtYac=.ee86ed01-ebeb-43cb-ae90-ef7ac61ebdac@github.com>
Message-ID: <guyv75SgNwIl7O28zvcgUa1CxdaKr-fwuMCH6Ni4pmg=.4ee224eb-bd51-490e-a747-c06668847f5b@github.com>

On Fri, 5 Apr 2024 12:19:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove repeated usages of {@link}
>
> src/java.base/share/classes/java/net/ServerSocket.java line 264:
> 
>> 262:      *             0 and 65535, inclusive.
>> 263:      *
>> 264:      * @see StandardSocketOptions
> 
> What would you think about dropping this link, and the link to SocketImpl from all the constructors, they aren't relevant for anyone reading this part of the docs.

These constructors talk about the `{@code createSocketImpl} method`, so I'm guessing the `@see java.net.SocketImpl` was meant to provide reference to the `SocketImpl`. But I think we should just change the `{@code createSocketImpl} method` to `{@link SocketImplFactory#createSocketImpl()} method` and remove these `@see java.net.SocketImpl`.

I guess we could do the same and remove the `@see java.net.SocketImpl` from the constructors of `java.net.Socket` too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18646#discussion_r1553562060

From jpai at openjdk.org  Fri Apr  5 13:03:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 13:03:14 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v2]
In-Reply-To: <guyv75SgNwIl7O28zvcgUa1CxdaKr-fwuMCH6Ni4pmg=.4ee224eb-bd51-490e-a747-c06668847f5b@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <js_7lfD5tDghamBAiLqKBXbGe1ufEw-Impq4i1IH12k=.aa89fb37-36f3-411f-a381-fe52df32c3b9@github.com>
 <fYIM3NI_ItxRM_42u2J4eThLl-B4fajk1rDWmrQtYac=.ee86ed01-ebeb-43cb-ae90-ef7ac61ebdac@github.com>
 <guyv75SgNwIl7O28zvcgUa1CxdaKr-fwuMCH6Ni4pmg=.4ee224eb-bd51-490e-a747-c06668847f5b@github.com>
Message-ID: <rs0Q-l4SG6_NrVmk9Q7aPOHHNmHb2HqoZJezTQPTd1w=.e9094494-01f2-48ec-8348-439c82e6a062@github.com>

On Fri, 5 Apr 2024 12:42:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/ServerSocket.java line 264:
>> 
>>> 262:      *             0 and 65535, inclusive.
>>> 263:      *
>>> 264:      * @see StandardSocketOptions
>> 
>> What would you think about dropping this link, and the link to SocketImpl from all the constructors, they aren't relevant for anyone reading this part of the docs.
>
> These constructors talk about the `{@code createSocketImpl} method`, so I'm guessing the `@see java.net.SocketImpl` was meant to provide reference to the `SocketImpl`. But I think we should just change the `{@code createSocketImpl} method` to `{@link SocketImplFactory#createSocketImpl()} method` and remove these `@see java.net.SocketImpl`.
> 
> I guess we could do the same and remove the `@see java.net.SocketImpl` from the constructors of `java.net.Socket` too?

I've now updated the PR with what I had in mind for this proposed change to these constructors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18646#discussion_r1553592558

From jpai at openjdk.org  Fri Apr  5 13:03:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 13:03:13 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v3]
In-Reply-To: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
Message-ID: <aA7ADDu8qXJ1WkcDz3bLw3Kd7Us1Cp2jQY11tU3S1vI=.b76839b6-328a-4539-bed2-ba363ef4c4df@github.com>

> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
> 
> I ran `make docs-image` locally with this change and the generated doc looks OK to me.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove some @see from constructors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18646/files
  - new: https://git.openjdk.org/jdk/pull/18646/files/46ece095..34f919b5

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

  Stats: 23 lines in 2 files changed: 7 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18646/head:pull/18646

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

From dfuchs at openjdk.org  Fri Apr  5 13:15:08 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 5 Apr 2024 13:15:08 GMT
Subject: RFR: 8329662: Add a test to verify the behaviour of the default
 HEAD() method on HttpRequest.Builder
In-Reply-To: <cLVOH8A6CABA_4vQ49YZqeKdjjEBYy9f7qU6CVmphDc=.22878b72-8448-4cfa-92bf-49454e4cdca8@github.com>
References: <cLVOH8A6CABA_4vQ49YZqeKdjjEBYy9f7qU6CVmphDc=.22878b72-8448-4cfa-92bf-49454e4cdca8@github.com>
Message-ID: <69JWBpyyzO3EihV66TtXLte7Qh6AYammTXYkeUyHhY4=.e215349a-7fd0-44f8-b4fa-dbc3255bcd62@github.com>

On Thu, 4 Apr 2024 11:50:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which updates an existing test case to verify the behaviour of `HttpRequest.Builder.HEAD()` method?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329662, this test now verifies the default implementation specified for `HttpRequest.Builder.HEAD()`. The existing tests were only verifing the behaviour of the `HEAD()` method implementation in the class of the instance returned from `HttpRequest.newBuilder()`. 
> 
> I have run this test in our CI with these changes and the test continues to pass.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18622#pullrequestreview-1983142880

From jpai at openjdk.org  Fri Apr  5 13:33:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 13:33:03 GMT
Subject: RFR: 8329662: Add a test to verify the behaviour of the default
 HEAD() method on HttpRequest.Builder
In-Reply-To: <cLVOH8A6CABA_4vQ49YZqeKdjjEBYy9f7qU6CVmphDc=.22878b72-8448-4cfa-92bf-49454e4cdca8@github.com>
References: <cLVOH8A6CABA_4vQ49YZqeKdjjEBYy9f7qU6CVmphDc=.22878b72-8448-4cfa-92bf-49454e4cdca8@github.com>
Message-ID: <mLql4W4jlCsocgXQv_OFaxqjeNDB-kQslHUuXwdV_w8=.66ddc6ec-da2f-482e-9156-a343a817960e@github.com>

On Thu, 4 Apr 2024 11:50:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which updates an existing test case to verify the behaviour of `HttpRequest.Builder.HEAD()` method?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329662, this test now verifies the default implementation specified for `HttpRequest.Builder.HEAD()`. The existing tests were only verifing the behaviour of the `HEAD()` method implementation in the class of the instance returned from `HttpRequest.newBuilder()`. 
> 
> I have run this test in our CI with these changes and the test continues to pass.

Thank you Daniel for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18622#issuecomment-2039810460

From jpai at openjdk.org  Fri Apr  5 13:33:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Apr 2024 13:33:04 GMT
Subject: Integrated: 8329662: Add a test to verify the behaviour of the default
 HEAD() method on HttpRequest.Builder
In-Reply-To: <cLVOH8A6CABA_4vQ49YZqeKdjjEBYy9f7qU6CVmphDc=.22878b72-8448-4cfa-92bf-49454e4cdca8@github.com>
References: <cLVOH8A6CABA_4vQ49YZqeKdjjEBYy9f7qU6CVmphDc=.22878b72-8448-4cfa-92bf-49454e4cdca8@github.com>
Message-ID: <e3NubMqHP8Vn09u_ZanZyBc7u12m-3Kva5mNiAnsAtA=.51e366dc-48ae-4c3f-8986-df218a4b30b5@github.com>

On Thu, 4 Apr 2024 11:50:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which updates an existing test case to verify the behaviour of `HttpRequest.Builder.HEAD()` method?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329662, this test now verifies the default implementation specified for `HttpRequest.Builder.HEAD()`. The existing tests were only verifing the behaviour of the `HEAD()` method implementation in the class of the instance returned from `HttpRequest.newBuilder()`. 
> 
> I have run this test in our CI with these changes and the test continues to pass.

This pull request has now been integrated.

Changeset: 4a11db8b
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a11db8b606f2b10f48f0b45335b661fe3095fc4
Stats:     86 lines in 1 file changed: 85 ins; 0 del; 1 mod

8329662: Add a test to verify the behaviour of the default HEAD() method on HttpRequest.Builder

Reviewed-by: dfuchs

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

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

From rengels at ix.netcom.com  Fri Apr  5 22:37:21 2024
From: rengels at ix.netcom.com (robert engels)
Date: Fri, 5 Apr 2024 17:37:21 -0500
Subject: HttpServer performance issue / improvement
In-Reply-To: <CAMrH03J6bL_LWjjJi7aMROzovAhEgKErM-yWLabpQVXAzxNx=g@mail.gmail.com>
References: <083E4B9D-DBC5-4C31-A91A-CE9CBEE5AFCD@ix.netcom.com>
 <CAMrH03J6bL_LWjjJi7aMROzovAhEgKErM-yWLabpQVXAzxNx=g@mail.gmail.com>
Message-ID: <D01DA959-44A8-48F9-A435-6EF7D6ADF966@ix.netcom.com>

Hi Daniel,

I think I have a solution that would work. I will try to get a PR together. Do you know if there is an existing test case the demonstrates the issue? - if not, I will start with that.

Robert

> On Apr 4, 2024, at 9:44?AM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
> 
> Hi Robert,
> Thanks for bringing this up! We are aware of the issue, it's tracked under https://bugs.openjdk.org/browse/JDK-6968351.
> 
> If you have an idea for a proper fix that doesn't add too much complexity, please open a PR, and we'll be happy to help.
> Cheers,
> Daniel
> 
> czw., 4 kwi 2024, 14:55 u?ytkownik Robert Engels <rengels at ix.netcom.com <mailto:rengels at ix.netcom.com>> napisa?:
>> ?
>> ?When doing some testing on github.com/robaho/httpserver <http://github.com/robaho/httpserver> - which is a fork of the jdk http server, I discovered a significant performance issue.
>> 
>> When an http connection is in ?keep-alive? - the default for http 1.1 - the headers are ?flushed? here https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L281
>> 
>> This means that after the handler runs and it sends data - e.g. /hello sends ?hello? on the connection, the connection will stall due to the Nagel algorithm - usually incurring a 50 ms delay. The stall occurs since the client will not see the expected data until after the delay, so it is unable to send the next (when reusing the same connection/HttpClient).
>> 
>> You can set the TCP_NODELAY on the server to work-around this, but a better solution would be to override the flush() on the BufferedOutputStream to not flush() the underlying connection - i.e. only write the buffered bytes, or rework it a bit to only flush when there is no content to send.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240405/f380ee2d/attachment-0001.htm>

From jpai at openjdk.org  Sat Apr  6 08:44:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 6 Apr 2024 08:44:09 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions [v2]
In-Reply-To: <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
 <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
Message-ID: <PLD7TlTSJGP9jwoRuWsTev0nWWbiPaVdzgb6gmlf5W4=.56b73148-108e-4270-b43e-ad6691ccb4b2@github.com>

On Fri, 5 Apr 2024 11:49:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clean up the documentation of `java.net.SocketOptions` interface?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing documentation in this legacy interface isn't accurate. The commit in this PR, updates the documentation on several of the fields to point to the newer java.net.StandardSocketOptions class. While at it, I also did a general update of this documentation to use snippets and also reword some of it to be a bit more clear.
>> 
>> I have run `make docs-image` on this change and the updated doc looks fine to me.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - "timeout value" instead of "timeout"
>  - missed SO_TIMEOUT review suggestion in previous commit
>  - Alan's review suggestions

Alan, in context of another old issue https://bugs.openjdk.org/browse/JDK-6431396 would you want anything more to be added/updated for the `SO_BINDADDR` field's javadoc as part of this PR? The current update in PR already takes into account that a Socket instance can be created unbounded.

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

PR Comment: https://git.openjdk.org/jdk/pull/18645#issuecomment-2041019163

From alanb at openjdk.org  Sat Apr  6 08:55:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 6 Apr 2024 08:55:11 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions [v2]
In-Reply-To: <PLD7TlTSJGP9jwoRuWsTev0nWWbiPaVdzgb6gmlf5W4=.56b73148-108e-4270-b43e-ad6691ccb4b2@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
 <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
 <PLD7TlTSJGP9jwoRuWsTev0nWWbiPaVdzgb6gmlf5W4=.56b73148-108e-4270-b43e-ad6691ccb4b2@github.com>
Message-ID: <Iux7RMOHAhFtWj-qPXongMi8h9PqQ0cKMRuVeL8NtxE=.a7b69ed9-7e1e-4550-b529-416b662d9c3c@github.com>

On Sat, 6 Apr 2024 08:41:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Alan, in context of another old issue https://bugs.openjdk.org/browse/JDK-6431396 would you want anything more to be added/updated for the `SO_BINDADDR` field's javadoc as part of this PR? The current update in PR already takes into account that a Socket instance can be created unbounded.

I think what you have is okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/18645#issuecomment-2041021361

From alanb at openjdk.org  Sat Apr  6 08:55:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 6 Apr 2024 08:55:11 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions [v2]
In-Reply-To: <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
 <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
Message-ID: <k8byOzhwXEgVfUL-zw9IGZ0FIjpWSKKD6BGa3PJ2iH4=.5fc59223-136c-4f67-86aa-e8b4e0ad800e@github.com>

On Fri, 5 Apr 2024 11:49:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clean up the documentation of `java.net.SocketOptions` interface?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing documentation in this legacy interface isn't accurate. The commit in this PR, updates the documentation on several of the fields to point to the newer java.net.StandardSocketOptions class. While at it, I also did a general update of this documentation to use snippets and also reword some of it to be a bit more clear.
>> 
>> I have run `make docs-image` on this change and the updated doc looks fine to me.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - "timeout value" instead of "timeout"
>  - missed SO_TIMEOUT review suggestion in previous commit
>  - Alan's review suggestions

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18645#pullrequestreview-1984466385

From alanb at openjdk.org  Sat Apr  6 09:13:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 6 Apr 2024 09:13:11 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v3]
In-Reply-To: <aA7ADDu8qXJ1WkcDz3bLw3Kd7Us1Cp2jQY11tU3S1vI=.b76839b6-328a-4539-bed2-ba363ef4c4df@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <aA7ADDu8qXJ1WkcDz3bLw3Kd7Us1Cp2jQY11tU3S1vI=.b76839b6-328a-4539-bed2-ba363ef4c4df@github.com>
Message-ID: <iAehicnKlZCWakiEwoqooAA0xX5MAJX7m9VCSidxzf0=.482469a7-e8b7-4fc5-beaa-221136a8a420@github.com>

On Fri, 5 Apr 2024 13:03:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
>> 
>> I ran `make docs-image` locally with this change and the generated doc looks OK to me.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove some @see from constructors

src/java.base/share/classes/java/net/ServerSocket.java line 189:

> 187:      * factory, that {@linkplain SocketImplFactory#createSocketImpl()
> 188:      * factory's createSocketImpl method} is called to create
> 189:      * the actual socket implementation. Otherwise a system-default

I think this would be better if you link  "server socket implementation factory" to SocketImplFactory, and link "createSocketImpl" to the createSocketImpl method.

src/java.base/share/classes/java/net/Socket.java line 177:

> 175:      * If the application has specified a client socket implementation
> 176:      * factory, that {@linkplain SocketImplFactory#createSocketImpl()
> 177:      * factory's createSocketImpl method} is called to

Same comment as ServerSocket.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18646#discussion_r1554553566
PR Review Comment: https://git.openjdk.org/jdk/pull/18646#discussion_r1554553597

From jpai at openjdk.org  Sat Apr  6 14:25:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 6 Apr 2024 14:25:18 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions [v2]
In-Reply-To: <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
 <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
Message-ID: <reCjBf4X55g3CN-AUYYe77BEnIKyA4RTRV3B1VWOTH4=.ac459c35-645a-4488-97eb-a6d32f87c6cc@github.com>

On Fri, 5 Apr 2024 11:49:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clean up the documentation of `java.net.SocketOptions` interface?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing documentation in this legacy interface isn't accurate. The commit in this PR, updates the documentation on several of the fields to point to the newer java.net.StandardSocketOptions class. While at it, I also did a general update of this documentation to use snippets and also reword some of it to be a bit more clear.
>> 
>> I have run `make docs-image` on this change and the updated doc looks fine to me.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - "timeout value" instead of "timeout"
>  - missed SO_TIMEOUT review suggestion in previous commit
>  - Alan's review suggestions

Thank you Alan and Daniel for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/18645#issuecomment-2041103111

From jpai at openjdk.org  Sat Apr  6 14:25:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 6 Apr 2024 14:25:18 GMT
Subject: Integrated: 8329733: Update the documentation in
 java.net.SocketOptions to direct to java.net.StandardSocketOptions
In-Reply-To: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
Message-ID: <7oZim5jgMjp-68YH3svR4GAZhIb42oatAFatGFWZ8bk=.adca4b60-77f2-408a-a9a5-a49b8462a555@github.com>

On Fri, 5 Apr 2024 06:56:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to clean up the documentation of `java.net.SocketOptions` interface?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing documentation in this legacy interface isn't accurate. The commit in this PR, updates the documentation on several of the fields to point to the newer java.net.StandardSocketOptions class. While at it, I also did a general update of this documentation to use snippets and also reword some of it to be a bit more clear.
> 
> I have run `make docs-image` on this change and the updated doc looks fine to me.

This pull request has now been integrated.

Changeset: d771ec62
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d771ec6296bd3bb17ac2dd79671fdb6f154b4ea5
Stats:     171 lines in 1 file changed: 5 ins; 91 del; 75 mod

8329733: Update the documentation in java.net.SocketOptions to direct to java.net.StandardSocketOptions
6431396: Spec for SocketOptions.SO_BINDADDR incorrect

Reviewed-by: djelinski, alanb

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

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

From rengels at ix.netcom.com  Sat Apr  6 23:37:56 2024
From: rengels at ix.netcom.com (robert engels)
Date: Sat, 6 Apr 2024 18:37:56 -0500
Subject: HttpServer performance issue / improvement
In-Reply-To: <D01DA959-44A8-48F9-A435-6EF7D6ADF966@ix.netcom.com>
References: <083E4B9D-DBC5-4C31-A91A-CE9CBEE5AFCD@ix.netcom.com>
 <CAMrH03J6bL_LWjjJi7aMROzovAhEgKErM-yWLabpQVXAzxNx=g@mail.gmail.com>
 <D01DA959-44A8-48F9-A435-6EF7D6ADF966@ix.netcom.com>
Message-ID: <2C82953A-5DB0-4F3A-9813-13ABD3A4310F@ix.netcom.com>

Hi Daniel,

Here is a PR which fixes it. All tests pass.

https://github.com/openjdk/jdk/pull/18667?
fix for small messages with tcp_nodelay off by robaho ? Pull Request #18667 ? openjdk/jdk
github.com


> On Apr 5, 2024, at 5:37?PM, robert engels <rengels at ix.netcom.com> wrote:
> 
> Hi Daniel,
> 
> I think I have a solution that would work. I will try to get a PR together. Do you know if there is an existing test case the demonstrates the issue? - if not, I will start with that.
> 
> Robert
> 
>> On Apr 4, 2024, at 9:44?AM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
>> 
>> Hi Robert,
>> Thanks for bringing this up! We are aware of the issue, it's tracked under https://bugs.openjdk.org/browse/JDK-6968351.
>> 
>> If you have an idea for a proper fix that doesn't add too much complexity, please open a PR, and we'll be happy to help.
>> Cheers,
>> Daniel
>> 
>> czw., 4 kwi 2024, 14:55 u?ytkownik Robert Engels <rengels at ix.netcom.com <mailto:rengels at ix.netcom.com>> napisa?:
>>> ?
>>> ?When doing some testing on github.com/robaho/httpserver <http://github.com/robaho/httpserver> - which is a fork of the jdk http server, I discovered a significant performance issue.
>>> 
>>> When an http connection is in ?keep-alive? - the default for http 1.1 - the headers are ?flushed? here https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L281
>>> 
>>> This means that after the handler runs and it sends data - e.g. /hello sends ?hello? on the connection, the connection will stall due to the Nagel algorithm - usually incurring a 50 ms delay. The stall occurs since the client will not see the expected data until after the delay, so it is unable to send the next (when reusing the same connection/HttpClient).
>>> 
>>> You can set the TCP_NODELAY on the server to work-around this, but a better solution would be to override the flush() on the BufferedOutputStream to not flush() the underlying connection - i.e. only write the buffered bytes, or rework it a bit to only flush when there is no content to send.
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240406/02c0a149/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 18667.png
Type: image/png
Size: 133518 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240406/02c0a149/18667-0001.png>

From jpai at openjdk.org  Sun Apr  7 01:43:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 7 Apr 2024 01:43:31 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v4]
In-Reply-To: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
Message-ID: <64FWJ2iLzjUTiQjV8h-D-MK6iCUcX65fNlfwgqJmmpw=.b4847338-0fc6-41aa-912f-a7b76f563edd@github.com>

> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
> 
> I ran `make docs-image` locally with this change and the generated doc looks OK to me.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  separate links for SocketImplFactory and createSocketImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18646/files
  - new: https://git.openjdk.org/jdk/pull/18646/files/34f919b5..70fc7fc5

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

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

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

From jpai at openjdk.org  Sun Apr  7 01:43:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 7 Apr 2024 01:43:31 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v3]
In-Reply-To: <iAehicnKlZCWakiEwoqooAA0xX5MAJX7m9VCSidxzf0=.482469a7-e8b7-4fc5-beaa-221136a8a420@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <aA7ADDu8qXJ1WkcDz3bLw3Kd7Us1Cp2jQY11tU3S1vI=.b76839b6-328a-4539-bed2-ba363ef4c4df@github.com>
 <iAehicnKlZCWakiEwoqooAA0xX5MAJX7m9VCSidxzf0=.482469a7-e8b7-4fc5-beaa-221136a8a420@github.com>
Message-ID: <dRRHUEMrDiCheJ0C2FdtqXw0bCDyU7NdgQ6NLeBckMc=.d7cffca2-e54d-4877-a567-44197438a3bc@github.com>

On Sat, 6 Apr 2024 09:10:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove some @see from constructors
>
> src/java.base/share/classes/java/net/ServerSocket.java line 189:
> 
>> 187:      * factory, that {@linkplain SocketImplFactory#createSocketImpl()
>> 188:      * factory's createSocketImpl method} is called to create
>> 189:      * the actual socket implementation. Otherwise a system-default
> 
> I think this would be better if you link  "server socket implementation factory" to SocketImplFactory, and link "createSocketImpl" to the createSocketImpl method.

Done - I've updated the PR with these changes to both ServerSocket and Socket class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18646#discussion_r1554793874

From Alan.Bateman at oracle.com  Sun Apr  7 06:37:53 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 7 Apr 2024 07:37:53 +0100
Subject: HttpServer performance issue / improvement
In-Reply-To: <2C82953A-5DB0-4F3A-9813-13ABD3A4310F@ix.netcom.com>
References: <083E4B9D-DBC5-4C31-A91A-CE9CBEE5AFCD@ix.netcom.com>
 <CAMrH03J6bL_LWjjJi7aMROzovAhEgKErM-yWLabpQVXAzxNx=g@mail.gmail.com>
 <D01DA959-44A8-48F9-A435-6EF7D6ADF966@ix.netcom.com>
 <2C82953A-5DB0-4F3A-9813-13ABD3A4310F@ix.netcom.com>
Message-ID: <34839918-2873-43f6-8362-234126b4eaf1@oracle.com>



On 07/04/2024 00:37, robert engels wrote:
> Hi Daniel,
>
> Here is a PR which fixes it.

I don't think anyone will be able to look at this PR until the "oca" 
label is removed. Look for the comment that the bot added about signing 
the OCA for instructions.

-Alan

From alanb at openjdk.org  Sun Apr  7 07:17:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 7 Apr 2024 07:17:11 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions [v2]
In-Reply-To: <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
 <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
Message-ID: <V0_mGJ17EsLkVQ5zAxBt8OSazwnlGYa9lCA-eDRpsrw=.ae089aac-abf4-4b5f-aa22-119778145fd9@github.com>

On Fri, 5 Apr 2024 11:49:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clean up the documentation of `java.net.SocketOptions` interface?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing documentation in this legacy interface isn't accurate. The commit in this PR, updates the documentation on several of the fields to point to the newer java.net.StandardSocketOptions class. While at it, I also did a general update of this documentation to use snippets and also reword some of it to be a bit more clear.
>> 
>> I have run `make docs-image` on this change and the updated doc looks fine to me.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - "timeout value" instead of "timeout"
>  - missed SO_TIMEOUT review suggestion in previous commit
>  - Alan's review suggestions

src/java.base/share/classes/java/net/SocketOptions.java line 192:

> 190: 
> 191:     /**
> 192:      * See {@link StandardSocketOptions#SO_LINGER} for description of this socket option.

One thing to mention about SO_LINGER is that the value of this socket option is an Integer when enabling and a Boolean when disabling. The getter works the same way. AFAIK, this was never correctly specified in SocketOptions.SO_LINGER but the examples in the setOption/getOption API docs include disabling. To notice this would require something to use a custom SocketImpl of course. So I think we need a follow-up to the change here to say that the value is Boolean.FALSE to disable (or disabled), otherwise an Integer with the linger timeout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18645#discussion_r1554833351

From alanb at openjdk.org  Sun Apr  7 07:19:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 7 Apr 2024 07:19:09 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v4]
In-Reply-To: <64FWJ2iLzjUTiQjV8h-D-MK6iCUcX65fNlfwgqJmmpw=.b4847338-0fc6-41aa-912f-a7b76f563edd@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <64FWJ2iLzjUTiQjV8h-D-MK6iCUcX65fNlfwgqJmmpw=.b4847338-0fc6-41aa-912f-a7b76f563edd@github.com>
Message-ID: <6HixjY8fN8IbCSQB9q-NoCnjnThsvnb5nyS_-W6E3u8=.0b4f7738-e93d-4915-9f7a-cad0dd3e254a@github.com>

On Sun, 7 Apr 2024 01:43:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
>> 
>> I ran `make docs-image` locally with this change and the generated doc looks OK to me.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separate links for SocketImplFactory and createSocketImpl

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18646#pullrequestreview-1984864850

From jpai at openjdk.org  Sun Apr  7 08:20:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 7 Apr 2024 08:20:14 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions [v2]
In-Reply-To: <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
 <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
Message-ID: <NjyA53zb0Ine_5ZQ0wNh9-ixnjmx3sO08Wrws84Phk8=.dca2162a-751b-4be2-92d1-7af662fd597f@github.com>

On Fri, 5 Apr 2024 11:49:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to clean up the documentation of `java.net.SocketOptions` interface?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the existing documentation in this legacy interface isn't accurate. The commit in this PR, updates the documentation on several of the fields to point to the newer java.net.StandardSocketOptions class. While at it, I also did a general update of this documentation to use snippets and also reword some of it to be a bit more clear.
>> 
>> I have run `make docs-image` on this change and the updated doc looks fine to me.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - "timeout value" instead of "timeout"
>  - missed SO_TIMEOUT review suggestion in previous commit
>  - Alan's review suggestions

> So I think we need a follow-up to the change here to say that the value is Boolean.FALSE to disable (or disabled), otherwise an Integer with the linger timeout.

I've opened https://bugs.openjdk.org/browse/JDK-8329825 to track this.

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

PR Comment: https://git.openjdk.org/jdk/pull/18645#issuecomment-2041363132

From rengels at ix.netcom.com  Sun Apr  7 10:45:47 2024
From: rengels at ix.netcom.com (Robert Engels)
Date: Sun, 7 Apr 2024 05:45:47 -0500
Subject: HttpServer performance issue / improvement
In-Reply-To: <34839918-2873-43f6-8362-234126b4eaf1@oracle.com>
References: <34839918-2873-43f6-8362-234126b4eaf1@oracle.com>
Message-ID: <94233C49-443A-4459-98F2-6ECB62118A4D@ix.netcom.com>

I filled out the OCA. It may be in a pending review status?


> On Apr 7, 2024, at 1:38?AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> ?
> 
>> On 07/04/2024 00:37, robert engels wrote:
>> Hi Daniel,
>> 
>> Here is a PR which fixes it.
> 
> I don't think anyone will be able to look at this PR until the "oca" label is removed. Look for the comment that the bot added about signing the OCA for instructions.
> 
> -Alan

From rengels at ix.netcom.com  Sun Apr  7 14:40:33 2024
From: rengels at ix.netcom.com (robert engels)
Date: Sun, 7 Apr 2024 09:40:33 -0500
Subject: HttpServer performance issue / improvement
In-Reply-To: <94233C49-443A-4459-98F2-6ECB62118A4D@ix.netcom.com>
References: <34839918-2873-43f6-8362-234126b4eaf1@oracle.com>
 <94233C49-443A-4459-98F2-6ECB62118A4D@ix.netcom.com>
Message-ID: <160CFC8B-3599-47AF-905C-F8B396DBB98C@ix.netcom.com>

I proceeding now. I guess when/if the OCA is approved someone will check it out.

> On Apr 7, 2024, at 5:45?AM, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> I filled out the OCA. It may be in a pending review status?
> 
> 
>> On Apr 7, 2024, at 1:38?AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> ?
>> 
>>> On 07/04/2024 00:37, robert engels wrote:
>>> Hi Daniel,
>>> 
>>> Here is a PR which fixes it.
>> 
>> I don't think anyone will be able to look at this PR until the "oca" label is removed. Look for the comment that the bot added about signing the OCA for instructions.
>> 
>> -Alan


From rengels at ix.netcom.com  Sun Apr  7 14:45:41 2024
From: rengels at ix.netcom.com (robert engels)
Date: Sun, 7 Apr 2024 09:45:41 -0500
Subject: HttpServer performance issue / improvement
In-Reply-To: <160CFC8B-3599-47AF-905C-F8B396DBB98C@ix.netcom.com>
References: <34839918-2873-43f6-8362-234126b4eaf1@oracle.com>
 <94233C49-443A-4459-98F2-6ECB62118A4D@ix.netcom.com>
 <160CFC8B-3599-47AF-905C-F8B396DBB98C@ix.netcom.com>
Message-ID: <DFE83895-A29B-49E0-8D0B-9C985129D9D1@ix.netcom.com>

Sorry, ?it?s? proceeding now. Says could be 1-2 weeks but usually 1-2 business days.

> On Apr 7, 2024, at 9:40?AM, robert engels <rengels at ix.netcom.com> wrote:
> 
> I proceeding now. I guess when/if the OCA is approved someone will check it out.
> 
>> On Apr 7, 2024, at 5:45?AM, Robert Engels <rengels at ix.netcom.com> wrote:
>> 
>> I filled out the OCA. It may be in a pending review status?
>> 
>> 
>>> On Apr 7, 2024, at 1:38?AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> ?
>>> 
>>>> On 07/04/2024 00:37, robert engels wrote:
>>>> Hi Daniel,
>>>> 
>>>> Here is a PR which fixes it.
>>> 
>>> I don't think anyone will be able to look at this PR until the "oca" label is removed. Look for the comment that the bot added about signing the OCA for instructions.
>>> 
>>> -Alan
> 


From alanb at openjdk.org  Sun Apr  7 15:26:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 7 Apr 2024 15:26:14 GMT
Subject: RFR: 8329733: Update the documentation in java.net.SocketOptions
 to direct to java.net.StandardSocketOptions [v2]
In-Reply-To: <NjyA53zb0Ine_5ZQ0wNh9-ixnjmx3sO08Wrws84Phk8=.dca2162a-751b-4be2-92d1-7af662fd597f@github.com>
References: <TVSR0cosJ6nDpKS-GIdUcYyApRK_jNns3FMcymrjOo0=.63c100f1-3bf7-4f2c-84d5-a0ff6e6d3b77@github.com>
 <VqKNqV_xjj6ziHv-eLRMVRBF--nrW2AiTRfvK2p3Dz8=.a0bcfb97-205e-4fbe-a05f-b0263f2c7a90@github.com>
 <NjyA53zb0Ine_5ZQ0wNh9-ixnjmx3sO08Wrws84Phk8=.dca2162a-751b-4be2-92d1-7af662fd597f@github.com>
Message-ID: <XioxreJ_xavW0XnxhLKQwANm7z1Nn7dL8PNS-XReU1o=.e6fca81c-5fa0-4ceb-868d-79e2bc12ea2b@github.com>

On Sun, 7 Apr 2024 08:16:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > So I think we need a follow-up to the change here to say that the value is Boolean.FALSE to disable (or disabled), otherwise an Integer with the linger timeout.
> 
> I've opened https://bugs.openjdk.org/browse/JDK-8329825 to track this.

Thanks, very low priority, everything SocketImpl is legacy and under-specified. It should have been deprecated a long time ago.

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

PR Comment: https://git.openjdk.org/jdk/pull/18645#issuecomment-2041504448

From djelinski1 at gmail.com  Mon Apr  8 08:20:42 2024
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Mon, 8 Apr 2024 10:20:42 +0200
Subject: HttpServer performance issue / improvement
In-Reply-To: <D01DA959-44A8-48F9-A435-6EF7D6ADF966@ix.netcom.com>
References: <083E4B9D-DBC5-4C31-A91A-CE9CBEE5AFCD@ix.netcom.com>
 <CAMrH03J6bL_LWjjJi7aMROzovAhEgKErM-yWLabpQVXAzxNx=g@mail.gmail.com>
 <D01DA959-44A8-48F9-A435-6EF7D6ADF966@ix.netcom.com>
Message-ID: <CAMrH03K_qODKVhKLrsh8O8fbuxhjEUKUQh5+F8rFUHA2ZVP2aw@mail.gmail.com>

Hi Robert,
If you are on Linux, see test/jdk/java/net/vthread/HttpALot.java. That
test was recently modified to add -Dsun.net.httpserver.nodelay=true
[1], because it took forever to complete on LInux machines. On other
OSes the problem is not visible in existing tests.
Cheers,
Daniel

[1] https://github.com/openjdk/jdk/pull/10504

sob., 6 kwi 2024 o 00:37 robert engels <rengels at ix.netcom.com> napisa?(a):
>
> Hi Daniel,
>
> I think I have a solution that would work. I will try to get a PR together. Do you know if there is an existing test case the demonstrates the issue? - if not, I will start with that.
>
> Robert
>
> On Apr 4, 2024, at 9:44?AM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
>
> Hi Robert,
> Thanks for bringing this up! We are aware of the issue, it's tracked under https://bugs.openjdk.org/browse/JDK-6968351.
>
> If you have an idea for a proper fix that doesn't add too much complexity, please open a PR, and we'll be happy to help.
> Cheers,
> Daniel
>
> czw., 4 kwi 2024, 14:55 u?ytkownik Robert Engels <rengels at ix.netcom.com> napisa?:
>>
>> ?
>> ?When doing some testing on github.com/robaho/httpserver - which is a fork of the jdk http server, I discovered a significant performance issue.
>>
>> When an http connection is in ?keep-alive? - the default for http 1.1 - the headers are ?flushed? here https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L281
>>
>> This means that after the handler runs and it sends data - e.g. /hello sends ?hello? on the connection, the connection will stall due to the Nagel algorithm - usually incurring a 50 ms delay. The stall occurs since the client will not see the expected data until after the delay, so it is unable to send the next (when reusing the same connection/HttpClient).
>>
>> You can set the TCP_NODELAY on the server to work-around this, but a better solution would be to override the flush() on the BufferedOutputStream to not flush() the underlying connection - i.e. only write the buffered bytes, or rework it a bit to only flush when there is no content to send.
>>
>

From jai.forums2013 at gmail.com  Mon Apr  8 09:01:09 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 8 Apr 2024 14:31:09 +0530
Subject: HttpServer performance issue / improvement
In-Reply-To: <CAMrH03K_qODKVhKLrsh8O8fbuxhjEUKUQh5+F8rFUHA2ZVP2aw@mail.gmail.com>
References: <083E4B9D-DBC5-4C31-A91A-CE9CBEE5AFCD@ix.netcom.com>
 <CAMrH03J6bL_LWjjJi7aMROzovAhEgKErM-yWLabpQVXAzxNx=g@mail.gmail.com>
 <D01DA959-44A8-48F9-A435-6EF7D6ADF966@ix.netcom.com>
 <CAMrH03K_qODKVhKLrsh8O8fbuxhjEUKUQh5+F8rFUHA2ZVP2aw@mail.gmail.com>
Message-ID: <944f7df6-70f8-44b4-9ca7-24261b8a4189@gmail.com>

Recently on AIX the same change was needed to address the test time outs 
in the 
test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java test 
- https://github.com/openjdk/jdk/pull/17363

-Jaikiran

On 08/04/24 1:50 pm, Daniel Jeli?ski wrote:
> Hi Robert,
> If you are on Linux, see test/jdk/java/net/vthread/HttpALot.java. That
> test was recently modified to add -Dsun.net.httpserver.nodelay=true
> [1], because it took forever to complete on LInux machines. On other
> OSes the problem is not visible in existing tests.
> Cheers,
> Daniel
>
> [1] https://github.com/openjdk/jdk/pull/10504
>
> sob., 6 kwi 2024 o 00:37 robert engels <rengels at ix.netcom.com> napisa?(a):
>> Hi Daniel,
>>
>> I think I have a solution that would work. I will try to get a PR together. Do you know if there is an existing test case the demonstrates the issue? - if not, I will start with that.
>>
>> Robert
>>
>> On Apr 4, 2024, at 9:44?AM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
>>
>> Hi Robert,
>> Thanks for bringing this up! We are aware of the issue, it's tracked under https://bugs.openjdk.org/browse/JDK-6968351.
>>
>> If you have an idea for a proper fix that doesn't add too much complexity, please open a PR, and we'll be happy to help.
>> Cheers,
>> Daniel
>>
>> czw., 4 kwi 2024, 14:55 u?ytkownik Robert Engels <rengels at ix.netcom.com> napisa?:
>>> ?
>>> ?When doing some testing on github.com/robaho/httpserver - which is a fork of the jdk http server, I discovered a significant performance issue.
>>>
>>> When an http connection is in ?keep-alive? - the default for http 1.1 - the headers are ?flushed? here https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L281
>>>
>>> This means that after the handler runs and it sends data - e.g. /hello sends ?hello? on the connection, the connection will stall due to the Nagel algorithm - usually incurring a 50 ms delay. The stall occurs since the client will not see the expected data until after the delay, so it is unable to send the next (when reusing the same connection/HttpClient).
>>>
>>> You can set the TCP_NODELAY on the server to work-around this, but a better solution would be to override the flush() on the BufferedOutputStream to not flush() the underlying connection - i.e. only write the buffered bytes, or rework it a bit to only flush when there is no content to send.
>>>

From rengels at ix.netcom.com  Mon Apr  8 12:10:19 2024
From: rengels at ix.netcom.com (Robert Engels)
Date: Mon, 8 Apr 2024 07:10:19 -0500
Subject: HttpServer performance issue / improvement
In-Reply-To: <944f7df6-70f8-44b4-9ca7-24261b8a4189@gmail.com>
References: <944f7df6-70f8-44b4-9ca7-24261b8a4189@gmail.com>
Message-ID: <3172328A-64EC-4262-8131-4BF0E429023F@ix.netcom.com>

I added a new test specifically to address this issue. Ran fine on osx without changes - long duration (failure) on Linux without the fix. 

> On Apr 8, 2024, at 4:01?AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
> ?Recently on AIX the same change was needed to address the test time outs in the test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java test - https://github.com/openjdk/jdk/pull/17363
> 
> -Jaikiran
> 
>> On 08/04/24 1:50 pm, Daniel Jeli?ski wrote:
>> Hi Robert,
>> If you are on Linux, see test/jdk/java/net/vthread/HttpALot.java. That
>> test was recently modified to add -Dsun.net.httpserver.nodelay=true
>> [1], because it took forever to complete on LInux machines. On other
>> OSes the problem is not visible in existing tests.
>> Cheers,
>> Daniel
>> 
>> [1] https://github.com/openjdk/jdk/pull/10504
>> 
>> sob., 6 kwi 2024 o 00:37 robert engels <rengels at ix.netcom.com> napisa?(a):
>>> Hi Daniel,
>>> 
>>> I think I have a solution that would work. I will try to get a PR together. Do you know if there is an existing test case the demonstrates the issue? - if not, I will start with that.
>>> 
>>> Robert
>>> 
>>>> On Apr 4, 2024, at 9:44?AM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
>>> 
>>> Hi Robert,
>>> Thanks for bringing this up! We are aware of the issue, it's tracked under https://bugs.openjdk.org/browse/JDK-6968351.
>>> 
>>> If you have an idea for a proper fix that doesn't add too much complexity, please open a PR, and we'll be happy to help.
>>> Cheers,
>>> Daniel
>>> 
>>> czw., 4 kwi 2024, 14:55 u?ytkownik Robert Engels <rengels at ix.netcom.com> napisa?:
>>>> ?
>>>> ?When doing some testing on github.com/robaho/httpserver - which is a fork of the jdk http server, I discovered a significant performance issue.
>>>> 
>>>> When an http connection is in ?keep-alive? - the default for http 1.1 - the headers are ?flushed? here https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L281
>>>> 
>>>> This means that after the handler runs and it sends data - e.g. /hello sends ?hello? on the connection, the connection will stall due to the Nagel algorithm - usually incurring a 50 ms delay. The stall occurs since the client will not see the expected data until after the delay, so it is unable to send the next (when reusing the same connection/HttpClient).
>>>> 
>>>> You can set the TCP_NODELAY on the server to work-around this, but a better solution would be to override the flush() on the BufferedOutputStream to not flush() the underlying connection - i.e. only write the buffered bytes, or rework it a bit to only flush when there is no content to send.
>>>> 

From rengels at ix.netcom.com  Mon Apr  8 13:23:19 2024
From: rengels at ix.netcom.com (Robert Engels)
Date: Mon, 8 Apr 2024 08:23:19 -0500
Subject: HttpServer performance issue / improvement
In-Reply-To: <3172328A-64EC-4262-8131-4BF0E429023F@ix.netcom.com>
References: <3172328A-64EC-4262-8131-4BF0E429023F@ix.netcom.com>
Message-ID: <FF0B92A3-3F75-4555-A5EF-7F710A8C83C8@ix.netcom.com>

I?ll update my PR to remove the nodelay setting from those tests. I am going to change the PR to use UrlConnection rather than HttpClient as well.  

> On Apr 8, 2024, at 7:10?AM, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> ?I added a new test specifically to address this issue. Ran fine on osx without changes - long duration (failure) on Linux without the fix.
> 
>> On Apr 8, 2024, at 4:01?AM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>> 
>> ?Recently on AIX the same change was needed to address the test time outs in the test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java test - https://github.com/openjdk/jdk/pull/17363
>> 
>> -Jaikiran
>> 
>>>> On 08/04/24 1:50 pm, Daniel Jeli?ski wrote:
>>> Hi Robert,
>>> If you are on Linux, see test/jdk/java/net/vthread/HttpALot.java. That
>>> test was recently modified to add -Dsun.net.httpserver.nodelay=true
>>> [1], because it took forever to complete on LInux machines. On other
>>> OSes the problem is not visible in existing tests.
>>> Cheers,
>>> Daniel
>>> 
>>> [1] https://github.com/openjdk/jdk/pull/10504
>>> 
>>> sob., 6 kwi 2024 o 00:37 robert engels <rengels at ix.netcom.com> napisa?(a):
>>>> Hi Daniel,
>>>> 
>>>> I think I have a solution that would work. I will try to get a PR together. Do you know if there is an existing test case the demonstrates the issue? - if not, I will start with that.
>>>> 
>>>> Robert
>>>> 
>>>>> On Apr 4, 2024, at 9:44?AM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
>>>> 
>>>> Hi Robert,
>>>> Thanks for bringing this up! We are aware of the issue, it's tracked under https://bugs.openjdk.org/browse/JDK-6968351.
>>>> 
>>>> If you have an idea for a proper fix that doesn't add too much complexity, please open a PR, and we'll be happy to help.
>>>> Cheers,
>>>> Daniel
>>>> 
>>>> czw., 4 kwi 2024, 14:55 u?ytkownik Robert Engels <rengels at ix.netcom.com> napisa?:
>>>>> ?
>>>>> ?When doing some testing on github.com/robaho/httpserver - which is a fork of the jdk http server, I discovered a significant performance issue.
>>>>> 
>>>>> When an http connection is in ?keep-alive? - the default for http 1.1 - the headers are ?flushed? here https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java#L281
>>>>> 
>>>>> This means that after the handler runs and it sends data - e.g. /hello sends ?hello? on the connection, the connection will stall due to the Nagel algorithm - usually incurring a 50 ms delay. The stall occurs since the client will not see the expected data until after the delay, so it is unable to send the next (when reusing the same connection/HttpClient).
>>>>> 
>>>>> You can set the TCP_NODELAY on the server to work-around this, but a better solution would be to override the flush() on the BufferedOutputStream to not flush() the underlying connection - i.e. only write the buffered bytes, or rework it a bit to only flush when there is no content to send.
>>>>> 

From daniel.fuchs at oracle.com  Mon Apr  8 14:02:47 2024
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 8 Apr 2024 15:02:47 +0100
Subject: HttpServer performance issue / improvement
In-Reply-To: <FF0B92A3-3F75-4555-A5EF-7F710A8C83C8@ix.netcom.com>
References: <3172328A-64EC-4262-8131-4BF0E429023F@ix.netcom.com>
 <FF0B92A3-3F75-4555-A5EF-7F710A8C83C8@ix.netcom.com>
Message-ID: <107747db-f50c-4250-9815-aea93bf81d1f@oracle.com>

Hi Robert,

I am waiting for the OCA to be processed before looking
at your PR.

FWIW some of the recent tests we have added for the HttpServer
already use the HttpClient - so unless your test/fix does
require HttpURLConnection it is fine to use HttpClient.

Were you planning to later propose to backport this change
back to JDK 8?

best regards,

-- daniel

On 08/04/2024 14:23, Robert Engels wrote:
> I?ll update my PR to remove the nodelay setting from those tests. I am going to change the PR to use UrlConnection rather than HttpClient as well.



From rengels at ix.netcom.com  Mon Apr  8 14:06:13 2024
From: rengels at ix.netcom.com (Robert Engels)
Date: Mon, 8 Apr 2024 09:06:13 -0500
Subject: HttpServer performance issue / improvement
In-Reply-To: <107747db-f50c-4250-9815-aea93bf81d1f@oracle.com>
References: <107747db-f50c-4250-9815-aea93bf81d1f@oracle.com>
Message-ID: <4A1B63E4-36A4-4813-AA05-A1CA087B7327@ix.netcom.com>

It?s fairly isolated but I haven?t checked to see how the JDK differs in jdk8 - but I?m guessing not very much so it should be a trivial port. 

> On Apr 8, 2024, at 9:03?AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> ?Hi Robert,
> 
> I am waiting for the OCA to be processed before looking
> at your PR.
> 
> FWIW some of the recent tests we have added for the HttpServer
> already use the HttpClient - so unless your test/fix does
> require HttpURLConnection it is fine to use HttpClient.
> 
> Were you planning to later propose to backport this change
> back to JDK 8?
> 
> best regards,
> 
> -- daniel
> 
>> On 08/04/2024 14:23, Robert Engels wrote:
>> I?ll update my PR to remove the nodelay setting from those tests. I am going to change the PR to use UrlConnection rather than HttpClient as well.
> 
> 

From rengels at ix.netcom.com  Mon Apr  8 14:09:08 2024
From: rengels at ix.netcom.com (Robert Engels)
Date: Mon, 8 Apr 2024 09:09:08 -0500
Subject: HttpServer performance issue / improvement
In-Reply-To: <4A1B63E4-36A4-4813-AA05-A1CA087B7327@ix.netcom.com>
References: <4A1B63E4-36A4-4813-AA05-A1CA087B7327@ix.netcom.com>
Message-ID: <5106D7E3-6482-42C9-B342-B69275DEFE2D@ix.netcom.com>

And thanks for the note about HttpClient - ill leave that as is then. 

> On Apr 8, 2024, at 9:06?AM, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> ?It?s fairly isolated but I haven?t checked to see how the JDK differs in jdk8 - but I?m guessing not very much so it should be a trivial port.
> 
>> On Apr 8, 2024, at 9:03?AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>> 
>> ?Hi Robert,
>> 
>> I am waiting for the OCA to be processed before looking
>> at your PR.
>> 
>> FWIW some of the recent tests we have added for the HttpServer
>> already use the HttpClient - so unless your test/fix does
>> require HttpURLConnection it is fine to use HttpClient.
>> 
>> Were you planning to later propose to backport this change
>> back to JDK 8?
>> 
>> best regards,
>> 
>> -- daniel
>> 
>>>> On 08/04/2024 14:23, Robert Engels wrote:
>>> I?ll update my PR to remove the nodelay setting from those tests. I am going to change the PR to use UrlConnection rather than HttpClient as well.
>> 
>> 

From dclarke at openjdk.org  Mon Apr  8 15:34:11 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Mon, 8 Apr 2024 15:34:11 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally [v3]
In-Reply-To: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
Message-ID: <Gf4KmNyMVDIqqJ9Jsib386hW0aPfbHgicxjerzsqHT8=.fce3a713-61f6-4f8b-951a-8233fd94b6b0@github.com>

> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
> 
> Changes:
> - Use try-with-resources to ensure streams close.
> - Use try-finally to make sure the server stops before the test exits.
> 
> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes

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

  implementing feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18514/files
  - new: https://git.openjdk.org/jdk/pull/18514/files/1294dbc0..c540dd58

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

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

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

From schernyshev at openjdk.org  Tue Apr  9 00:47:20 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 9 Apr 2024 00:47:20 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses
Message-ID: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>

There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.

Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).

The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that

"If a literal IP address is supplied, only the validity of the address format is checked."

@AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.

It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:

- `IPAddressUtil#parseBsdLiteralV4()` method is extracted from `.isBsdParsableV4()`
- an additional check is added, whether an input string is empty
- `null` is returned whenever the original algorithm fails
- a condition was added to the parser loop, that stores the IPv4 address segment value when it fits in 1 byte (0 <= x < 256)
- an additional check was added to verify that the last field value is non-negative
- when the last field value is multi-byte (the number of fields is less than 4), it is written to the last (4-(fieldNumber-1)) octets

The new method hasn't been added to InetAddress superclass because the change is only related to IPv4 addressing. This reduces the chance that client code will call the wrong factory method.

`test/jdk/java/net/InetAddress/OfLiteralTest.java` was updated to include `.ofPosixLiteral()` tests

Javadocs in `Inet4Address` were updated accordingly

The new method can be used as follows

import java.net.InetAddress;
import java.net.Inet4Address;

public class Test {
    public static void main(String[] args) throws Throwable {
        if (args.length < 1) {
            System.err.println("USAGE: java Test <host>");
            return;
        }
        InetAddress ia = Inet4Address.ofPosixLiteral(args[0]);
        System.out.println(ia.toString());
    }
}

The output would be

$ ./build/images/jdk/bin/java Test 2130706433
/127.0.0.1
$ ./build/images/jdk/bin/java Test 02130706433
/17.99.141.27
$ ./build/images/jdk/bin/java Test 2130706438
/127.0.0.6
$ ./build/images/jdk/bin/java Test 02130706438
Exception in thread "main" java.lang.IllegalArgumentException: Invalid IP address literal: 02130706438
        at java.base/sun.net.util.IPAddressUtil.invalidIpAddressLiteral(IPAddressUtil.java:169)
        at java.base/java.net.Inet4Address.parseAddressStringPosix(Inet4Address.java:302)
        at java.base/java.net.Inet4Address.ofPosixLiteral(Inet4Address.java:239)
        at Test.main(Test.java:10)


[1] https://www.ietf.org/rfc/rfc6943.html#section-3.1.1
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html
[3] https://bugs.openjdk.org/browse/JDK-8272215
[4] https://github.com/openjdk/jdk/commit/cdc1582d1d7629c2077f6cd19786d23323111018

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

Commit messages:
 - updated specification for java.net.Inet4Address, javadoc for sun.net.util.IPAddressUtil
 - removed trailing whitespace
 - updated javadocs, added apinotes, tests for corner cases
 - handle empty strings
 - 8315767: InetAddress.getByName() accepts ambiguous addresses

Changes: https://git.openjdk.org/jdk/pull/18493/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18493&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315767
  Stats: 256 lines in 3 files changed: 241 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/18493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18493/head:pull/18493

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

From dfuchs at openjdk.org  Tue Apr  9 07:57:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 9 Apr 2024 07:57:10 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v4]
In-Reply-To: <64FWJ2iLzjUTiQjV8h-D-MK6iCUcX65fNlfwgqJmmpw=.b4847338-0fc6-41aa-912f-a7b76f563edd@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <64FWJ2iLzjUTiQjV8h-D-MK6iCUcX65fNlfwgqJmmpw=.b4847338-0fc6-41aa-912f-a7b76f563edd@github.com>
Message-ID: <z3bcWkmDJNwbMMZIDvTa3FpU6qBQnkda5d-DX435Nag=.048a846b-9baa-4efd-a7c5-80532ce3afb9@github.com>

On Sun, 7 Apr 2024 01:43:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
>> 
>> I ran `make docs-image` locally with this change and the generated doc looks OK to me.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separate links for SocketImplFactory and createSocketImpl

@jaikiran the only reservation I have is that the new wording makes it look like the default implementation of `ServerSocket` methods is going to call `SocketImpl::getOption(SocketOption<>)` while in fact it still calls `SocketImpl::getOption(SocketOptions)`. But if @AlanBateman is good with that I am good as well. Maybe the fact that the two SocketImpl methods have equivalent results and that the implementation still call the legacy one should be spelled out in a public comment in the JBS issue? I am worrying about possible implication with JCK.

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

PR Comment: https://git.openjdk.org/jdk/pull/18646#issuecomment-2044371733

From alanb at openjdk.org  Tue Apr  9 10:24:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 10:24:09 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v4]
In-Reply-To: <z3bcWkmDJNwbMMZIDvTa3FpU6qBQnkda5d-DX435Nag=.048a846b-9baa-4efd-a7c5-80532ce3afb9@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <64FWJ2iLzjUTiQjV8h-D-MK6iCUcX65fNlfwgqJmmpw=.b4847338-0fc6-41aa-912f-a7b76f563edd@github.com>
 <z3bcWkmDJNwbMMZIDvTa3FpU6qBQnkda5d-DX435Nag=.048a846b-9baa-4efd-a7c5-80532ce3afb9@github.com>
Message-ID: <3lnlJSfMbOXIS2LszgwT91snFe_EX44tEd_WI7Gzx7A=.d7f09013-cdd2-4414-add6-d96011b3d431@github.com>

On Tue, 9 Apr 2024 07:54:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> @jaikiran the only reservation I have is that the new wording makes it look like the default implementation of `ServerSocket` methods is going to call `SocketImpl::getOption(SocketOption<>)` while in fact it still calls `SocketImpl::getOption(SocketOptions)`. 

I think the proposal is okay. It just specifies that set/gets the socket options, it doesn't specify whether it calls the SocketImpl's setOption(int, Object) or setOption(SocketOption, Object) methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/18646#issuecomment-2044655847

From dfuchs at openjdk.org  Tue Apr  9 11:40:02 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 9 Apr 2024 11:40:02 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v4]
In-Reply-To: <64FWJ2iLzjUTiQjV8h-D-MK6iCUcX65fNlfwgqJmmpw=.b4847338-0fc6-41aa-912f-a7b76f563edd@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <64FWJ2iLzjUTiQjV8h-D-MK6iCUcX65fNlfwgqJmmpw=.b4847338-0fc6-41aa-912f-a7b76f563edd@github.com>
Message-ID: <PlBmKLmFgh4QtuajFQgyl0qnTUQx1A2u_pn8bqIHMq0=.9138ec06-6d0f-42c2-9b4d-eaeb1569b7ac@github.com>

On Sun, 7 Apr 2024 01:43:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
>> 
>> I ran `make docs-image` locally with this change and the generated doc looks OK to me.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separate links for SocketImplFactory and createSocketImpl

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18646#pullrequestreview-1988817614

From jpai at openjdk.org  Tue Apr  9 13:07:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 13:07:12 GMT
Subject: RFR: 8329745: Update the documentation of ServerSocket and Socket
 to refer to StandardSocketOptions instead of legacy SocketOptions [v4]
In-Reply-To: <64FWJ2iLzjUTiQjV8h-D-MK6iCUcX65fNlfwgqJmmpw=.b4847338-0fc6-41aa-912f-a7b76f563edd@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
 <64FWJ2iLzjUTiQjV8h-D-MK6iCUcX65fNlfwgqJmmpw=.b4847338-0fc6-41aa-912f-a7b76f563edd@github.com>
Message-ID: <Q4BYmC_5wZuBVgfpBc5qkdotcxZpk5SIUNRuUU3AXVk=.837b3ee4-ab1d-4675-90fa-f1c684cb3a97@github.com>

On Sun, 7 Apr 2024 01:43:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
>> 
>> I ran `make docs-image` locally with this change and the generated doc looks OK to me.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separate links for SocketImplFactory and createSocketImpl

Thank you Alan and Daniel for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/18646#issuecomment-2045132536

From jpai at openjdk.org  Tue Apr  9 13:07:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 13:07:12 GMT
Subject: Integrated: 8329745: Update the documentation of ServerSocket and
 Socket to refer to StandardSocketOptions instead of legacy SocketOptions
In-Reply-To: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
References: <yHUd_QkxvEMIWPBckko2p6HFzDVneBu5QXU2_S_ZUQE=.c9ee13b0-8cfb-46f9-8705-f2653f97065f@github.com>
Message-ID: <jfNqv65ryZzlnCIus4vFg8-FmO3278tQeAygkvHLhxA=.56a203a8-b6a6-4c08-b77b-45d5bf4b63a3@github.com>

On Fri, 5 Apr 2024 07:31:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only changes to java.net.ServerSocket and java.net.Socket classes?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes currently refer to the legacy `java.net.SocketOptions` interface and instead should be refering to the newer `java.net.StandardSocketOptions` class. The commit in this PR updates such references. This change intentionally doesn't do any code changes to use the `StandardSocketOptions` class - that can be done separately if desired at a later point (after testing for any compatibility issues). Finally, there are a few places in ServerSocket and Socket documentation which will continue to refer to java.net.SocketOptions legacy interface because few of the options aren't available in StandardSocketOptions class (for example, `SO_TIMEOUT`).
> 
> I ran `make docs-image` locally with this change and the generated doc looks OK to me.

This pull request has now been integrated.

Changeset: 635cb3c9
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/635cb3c9762aeaec6c8dd2c21b8323d187236b4f
Stats:     112 lines in 2 files changed: 7 ins; 18 del; 87 mod

8329745: Update the documentation of ServerSocket and Socket to refer to StandardSocketOptions instead of legacy SocketOptions

Reviewed-by: alanb, dfuchs

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

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

From dfuchs at openjdk.org  Tue Apr  9 13:12:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 9 Apr 2024 13:12:11 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally [v3]
In-Reply-To: <Gf4KmNyMVDIqqJ9Jsib386hW0aPfbHgicxjerzsqHT8=.fce3a713-61f6-4f8b-951a-8233fd94b6b0@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
 <Gf4KmNyMVDIqqJ9Jsib386hW0aPfbHgicxjerzsqHT8=.fce3a713-61f6-4f8b-951a-8233fd94b6b0@github.com>
Message-ID: <HEIdnks_fe96rD5T-8aggx4Qh_pISL4Kytu59H2WCUI=.e8071caf-ec77-4ada-a8cf-79f4da826911@github.com>

On Mon, 8 Apr 2024 15:34:11 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
>> 
>> Changes:
>> - Use try-with-resources to ensure streams close.
>> - Use try-finally to make sure the server stops before the test exits.
>> 
>> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implementing feedback

Thanks! LGTM now.

Thanks. LGTM now.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18514#pullrequestreview-1988987958
PR Review: https://git.openjdk.org/jdk/pull/18514#pullrequestreview-1988990606

From jpai at openjdk.org  Tue Apr  9 13:12:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 13:12:11 GMT
Subject: RFR: 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java
 should use try-with-resource and try-finally [v3]
In-Reply-To: <Gf4KmNyMVDIqqJ9Jsib386hW0aPfbHgicxjerzsqHT8=.fce3a713-61f6-4f8b-951a-8233fd94b6b0@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
 <Gf4KmNyMVDIqqJ9Jsib386hW0aPfbHgicxjerzsqHT8=.fce3a713-61f6-4f8b-951a-8233fd94b6b0@github.com>
Message-ID: <isPOpKjgyFBz5dC5K_6H5tzeTFlrW6beLkgxp8gOKYA=.75c3003c-563d-4b21-a66c-fc0fe4d4904c@github.com>

On Mon, 8 Apr 2024 15:34:11 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
>> 
>> Changes:
>> - Use try-with-resources to ensure streams close.
>> - Use try-finally to make sure the server stops before the test exits.
>> 
>> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implementing feedback

Thank you Darragh for the updates. This now looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18514#pullrequestreview-1988996486

From dfuchs at openjdk.org  Tue Apr  9 14:01:14 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 9 Apr 2024 14:01:14 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses
In-Reply-To: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
Message-ID: <dZ8YcwRRRo9b0C3v3wO4Mqb4oNLD5uD3k7kaQdoajAg=.e3dc5b0a-8c58-4d62-a931-1a9d41a690da@github.com>

On Tue, 26 Mar 2024 17:25:54 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
> 
> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
> 
> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
> 
> "If a literal IP address is supplied, only the validity of the address format is checked."
> 
> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
> 
> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
> 
> - `IPAddressUtil#parseBsdLiteralV4()` method is e...

src/java.base/share/classes/java/net/Inet4Address.java line 103:

> 101:  * octal and hexadecimal address segments. Please refer to
> 102:  * <a href="https://www.ietf.org/rfc/rfc6943.html#section-3.1.1"> <i>RFC&nbsp;
> 103:  * 6943: Issues in Identifier Comparison for Security Purposes</i></a>.

Suggestion:

 * <p> The above forms adhere "strict" decimal-only syntax.
 * Additionally, the
 * {@link Inet4Address#ofPosixLiteral(String)} method implements a
 * <a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html">
 * POSIX {@code inet_addr}</a> compatible "loose" parsing algorithm, allowing
 * octal and hexadecimal address segments. Please refer to
 * <a href="https://www.ietf.org/rfc/rfc6943.html#section-3.1.1"> <i>RFC&nbsp;
 * 6943: Issues in Identifier Comparison for Security Purposes</i></a>.

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

> 222:      * Inet4Address##format valid IPv4 address} an {@code IllegalArgumentException} is thrown.
> 223:      * <p> This method doesn't block, i.e. no hostname lookup is performed.
> 224:      *

Please desrcibe the syntax this metod accepts here, in the normative part of the specification.

src/java.base/share/classes/java/net/Inet4Address.java line 232:

> 230:      * {@code 255} for {@code "0255"}, {@linkplain Inet4Address#ofPosixLiteral this}
> 231:      * method interprets the numbers based on their prefix (hexadecimal {@code "0x"},
> 232:      * octal {@code "0"}) and returns {@code 173} for {@code "0255"}.

Suggestion:

     * when {@code posixIPAddressLiteral} parameter contains address segments with
     * leading zeroes. An address segment with a leading zero is always parsed as an octal
     * number by {@code  ofPosixLiteral()}, therefore {@code 0255} (octal) will be parsed as
     * {@code 173} (decimal) by this method. On the other hand, {@link Inet4Address#ofLiteral
     * Inet4Address.ofLiteral} ignores leading zeros, parses all numbers as decimal and produces
     * {@code 255}. Where this method would parse {@code 0256.0256.0256.0256} (octal) and 
     * produce {@code 174.174.174.174} (decimal) in four dotted quad notation, 
     * {@code Inet4Address.ofLiteral} will throw {@code IllegalArgumentException}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1557642992
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1557678859
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1557675986

From dfuchs at openjdk.org  Tue Apr  9 14:45:00 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 9 Apr 2024 14:45:00 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses
In-Reply-To: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
Message-ID: <7-78H17YouqXZIRhdgPU_q2R7hQ-RAmKOVNJSHNupVk=.508b0f4d-100f-41f6-89a6-fdc11fa8ac1f@github.com>

On Tue, 26 Mar 2024 17:25:54 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
> 
> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
> 
> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
> 
> "If a literal IP address is supplied, only the validity of the address format is checked."
> 
> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
> 
> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
> 
> - `IPAddressUtil#parseBsdLiteralV4()` method is e...

src/java.base/share/classes/java/net/Inet4Address.java line 124:

> 122:  *  // the constructed address bytes without any rearrangement
> 123:  *  Inet4Address.ofPosixLiteral("017700000001"); // ==> /127.0.0.1
> 124:  * }

Please move this part into the normative part of the `ofPosixLiteral` method description

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1557767839

From acobbs at openjdk.org  Tue Apr  9 15:36:27 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 9 Apr 2024 15:36:27 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v4]
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <qtjsShzhgQEKyiwIbZ4ihv1xT7wIwZsWJ6bpqsVbjwg=.305c91fe-5b83-426c-ac82-ca6c34a8cb61@github.com>

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Javadoc++
 - Merge branch 'master' into JDK-8317376
 - Several improvements to the 'this' escape analyzer.
   
   - Track direct, indirect, and outer references for all Ref types.
   - Keep type information about all references to improve tracking precision.
   - Track enhanced for() invocations of iterator(), hasNext(), and next().
   - Don't report an escape of a non-public outer instances as a leak.
   - Fix omitted tracking of references from newly instantiated instances.
   - Fix omitted tracking of leaks via lambda return values.
   - Remove unneccesary suppressions of this-escape lint warning.

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

Changes: https://git.openjdk.org/jdk/pull/16208/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16208&range=03
  Stats: 869 lines in 19 files changed: 513 ins; 146 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/16208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16208/head:pull/16208

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

From dclarke at openjdk.org  Wed Apr 10 11:15:13 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Wed, 10 Apr 2024 11:15:13 GMT
Subject: Integrated: 8326568:
 jdk/test/com/sun/net/httpserver/bugs/B6431193.java should use
 try-with-resource and try-finally
In-Reply-To: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
References: <FQMRWw2o0T5KSJ79FU5_aPDXAH1Iky4ZXjT2bC0AQug=.180e6cff-fc6b-4558-80a0-26eb7a0d3fa3@github.com>
Message-ID: <SuiSR2n9llAjNEWecqImGIInKhP8aaXl0Ma1z5aG3AY=.249670b5-4bfc-4c32-b28c-13b66f1575d1@github.com>

On Wed, 27 Mar 2024 14:58:48 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently this test occasionally doesn't cleanup between runs, sometimes not stopping the server or leaving Streams open
> 
> Changes:
> - Use try-with-resources to ensure streams close.
> - Use try-finally to make sure the server stops before the test exits.
> 
> I ran tiers 1-3 and ran this specific test on repeat and everything seems stable after the changes

This pull request has now been integrated.

Changeset: 86cb7672
Author:    Darragh Clarke <dclarke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86cb76728dd164faa8fe69cd07db85977e79be29
Stats:     50 lines in 1 file changed: 9 ins; 20 del; 21 mod

8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java should use try-with-resource and try-finally

Reviewed-by: dfuchs, jpai

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

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

From schernyshev at openjdk.org  Wed Apr 10 15:34:22 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 10 Apr 2024 15:34:22 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v2]
In-Reply-To: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
Message-ID: <Dh_ubSa03PrKi0SE1zkxvSyt5-wgs6qSTA9Wu7HZsOE=.ce7adb24-69d6-4354-be9f-612fe18e686f@github.com>

> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
> 
> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
> 
> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
> 
> "If a literal IP address is supplied, only the validity of the address format is checked."
> 
> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
> 
> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
> 
> - `IPAddressUtil#parseBsdLiteralV4()` method is e...

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

  addressed review comments in Javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18493/files
  - new: https://git.openjdk.org/jdk/pull/18493/files/99ba4544..4230f0f2

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

  Stats: 30 lines in 1 file changed: 6 ins; 6 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/18493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18493/head:pull/18493

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

From dclarke at openjdk.org  Wed Apr 10 15:49:16 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Wed, 10 Apr 2024 15:49:16 GMT
Subject: RFR: 8330033: com/sun/net/httpserver/bugs/B6431193.java fails in
 AssertionError after JDK-8326568
Message-ID: <ZnTA9X5tU3lSO6KgGgFds4d4n4rh-zLFGVdzaVVmbXA=.a8d6115e-ed39-491a-b6de-509847e46fba@github.com>

After integrating [JDK-8326568](https://bugs.openjdk.org/browse/JDK-8326568), B6431193 has been failing due to a suspected race condition on whether the `handlerIsDaemon` is set.

- Moved setting `handlerIsDaemon` from the finally block to before the response is sent

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

Commit messages:
 - moved setting boolean to inside try statement to avoid race condition

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

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

From jpai at openjdk.org  Wed Apr 10 15:53:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 10 Apr 2024 15:53:08 GMT
Subject: RFR: 8330033: com/sun/net/httpserver/bugs/B6431193.java fails in
 AssertionError after JDK-8326568
In-Reply-To: <ZnTA9X5tU3lSO6KgGgFds4d4n4rh-zLFGVdzaVVmbXA=.a8d6115e-ed39-491a-b6de-509847e46fba@github.com>
References: <ZnTA9X5tU3lSO6KgGgFds4d4n4rh-zLFGVdzaVVmbXA=.a8d6115e-ed39-491a-b6de-509847e46fba@github.com>
Message-ID: <z2bL2PS2qT-sCWEFe0vKBwagNFUR2mVFJhvgVXz7cyU=.1d4a5a5b-56c5-4582-b291-5e4addc26f28@github.com>

On Wed, 10 Apr 2024 15:39:54 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> After integrating [JDK-8326568](https://bugs.openjdk.org/browse/JDK-8326568), B6431193 has been failing due to a suspected race condition on whether the `handlerIsDaemon` is set.
> 
> - Moved setting `handlerIsDaemon` from the finally block to before the response is sent

Looks reasonable. Please see if you can run a successful test-repeat of 50 before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18727#pullrequestreview-1992100464

From dfuchs at openjdk.org  Wed Apr 10 16:06:09 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Apr 2024 16:06:09 GMT
Subject: RFR: 8330033: com/sun/net/httpserver/bugs/B6431193.java fails in
 AssertionError after JDK-8326568
In-Reply-To: <ZnTA9X5tU3lSO6KgGgFds4d4n4rh-zLFGVdzaVVmbXA=.a8d6115e-ed39-491a-b6de-509847e46fba@github.com>
References: <ZnTA9X5tU3lSO6KgGgFds4d4n4rh-zLFGVdzaVVmbXA=.a8d6115e-ed39-491a-b6de-509847e46fba@github.com>
Message-ID: <bLXjXAXQ0snBQoaSDExCf3frMEuDt2b0RsWUcsyCWhc=.90300f31-b1b5-4941-b5c9-3b61c2f09b23@github.com>

On Wed, 10 Apr 2024 15:39:54 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> After integrating [JDK-8326568](https://bugs.openjdk.org/browse/JDK-8326568), B6431193 has been failing due to a suspected race condition on whether the `handlerIsDaemon` is set.
> 
> - Moved setting `handlerIsDaemon` from the finally block to before the response is sent

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18727#pullrequestreview-1992126965

From dclarke at openjdk.org  Wed Apr 10 16:06:10 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Wed, 10 Apr 2024 16:06:10 GMT
Subject: RFR: 8330033: com/sun/net/httpserver/bugs/B6431193.java fails in
 AssertionError after JDK-8326568
In-Reply-To: <z2bL2PS2qT-sCWEFe0vKBwagNFUR2mVFJhvgVXz7cyU=.1d4a5a5b-56c5-4582-b291-5e4addc26f28@github.com>
References: <ZnTA9X5tU3lSO6KgGgFds4d4n4rh-zLFGVdzaVVmbXA=.a8d6115e-ed39-491a-b6de-509847e46fba@github.com>
 <z2bL2PS2qT-sCWEFe0vKBwagNFUR2mVFJhvgVXz7cyU=.1d4a5a5b-56c5-4582-b291-5e4addc26f28@github.com>
Message-ID: <o16FxK1jB6mv74WcY0pYxXKOX-xrvpfdH8mZUZ3ZhkE=.7d5b7c92-19a9-495e-b3e1-ecd23b9e10a0@github.com>

On Wed, 10 Apr 2024 15:50:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Looks reasonable. Please see if you can run a successful test-repeat of 50 before integrating.

Thanks for the review, the test is passing though the original PR also passed until after it was merged so I'm not 100% certain

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

PR Comment: https://git.openjdk.org/jdk/pull/18727#issuecomment-2047930377

From dclarke at openjdk.org  Wed Apr 10 16:14:11 2024
From: dclarke at openjdk.org (Darragh Clarke)
Date: Wed, 10 Apr 2024 16:14:11 GMT
Subject: Integrated: 8330033: com/sun/net/httpserver/bugs/B6431193.java fails
 in AssertionError after JDK-8326568
In-Reply-To: <ZnTA9X5tU3lSO6KgGgFds4d4n4rh-zLFGVdzaVVmbXA=.a8d6115e-ed39-491a-b6de-509847e46fba@github.com>
References: <ZnTA9X5tU3lSO6KgGgFds4d4n4rh-zLFGVdzaVVmbXA=.a8d6115e-ed39-491a-b6de-509847e46fba@github.com>
Message-ID: <29C1MSMibSxZ_Kf4u8vXsGTSoT1F_rk0xpji2hkGfWc=.2b5b2c27-97bd-4e07-939b-9f90cb46d3a7@github.com>

On Wed, 10 Apr 2024 15:39:54 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> After integrating [JDK-8326568](https://bugs.openjdk.org/browse/JDK-8326568), B6431193 has been failing due to a suspected race condition on whether the `handlerIsDaemon` is set.
> 
> - Moved setting `handlerIsDaemon` from the finally block to before the response is sent

This pull request has now been integrated.

Changeset: 70944ca5
Author:    Darragh Clarke <dclarke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70944ca54ad0090c734bb5b3082beb33450c4877
Stats:     3 lines in 1 file changed: 1 ins; 2 del; 0 mod

8330033: com/sun/net/httpserver/bugs/B6431193.java fails in AssertionError after JDK-8326568

Reviewed-by: jpai, dfuchs

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

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

From schernyshev at openjdk.org  Thu Apr 11 09:08:45 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 11 Apr 2024 09:08:45 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v2]
In-Reply-To: <dZ8YcwRRRo9b0C3v3wO4Mqb4oNLD5uD3k7kaQdoajAg=.e3dc5b0a-8c58-4d62-a931-1a9d41a690da@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <dZ8YcwRRRo9b0C3v3wO4Mqb4oNLD5uD3k7kaQdoajAg=.e3dc5b0a-8c58-4d62-a931-1a9d41a690da@github.com>
Message-ID: <Wxs1ShNxsZnbqG0uUokrqM8iHPfBBkbIKGl-A7XXbjI=.e964ab89-7e41-4a78-8e0e-58a6574f0281@github.com>

On Tue, 9 Apr 2024 13:35:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressed review comments in Javadoc
>
> src/java.base/share/classes/java/net/Inet4Address.java line 103:
> 
>> 101:  * octal and hexadecimal address segments. Please refer to
>> 102:  * <a href="https://www.ietf.org/rfc/rfc6943.html#section-3.1.1"> <i>RFC&nbsp;
>> 103:  * 6943: Issues in Identifier Comparison for Security Purposes</i></a>.
> 
> Suggestion:
> 
>  * <p> The above forms adhere "strict" decimal-only syntax.
>  * Additionally, the
>  * {@link Inet4Address#ofPosixLiteral(String)} method implements a
>  * <a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html">
>  * POSIX {@code inet_addr}</a> compatible "loose" parsing algorithm, allowing
>  * octal and hexadecimal address segments. Please refer to
>  * <a href="https://www.ietf.org/rfc/rfc6943.html#section-3.1.1"> <i>RFC&nbsp;
>  * 6943: Issues in Identifier Comparison for Security Purposes</i></a>.

This removes the reference of loose syntax that was opposed to strict syntax. Would you think to also remove the word "strict"?

> src/java.base/share/classes/java/net/Inet4Address.java line 124:
> 
>> 122:  *  // the constructed address bytes without any rearrangement
>> 123:  *  Inet4Address.ofPosixLiteral("017700000001"); // ==> /127.0.0.1
>> 124:  * }
> 
> Please move this part into the normative part of the `ofPosixLiteral` method description

Hi Daniel, thank you for your notes. This part is logical continuation of the sample fragment starting at line 76 of the class spec. I'd rather leave it as is, otherwise it would be the same problem with the previous fragment with `ofLiteral()` and `getByName()` examples. I avoided in-depth syntax description in the method header, preferred adding a link instead. Please have a look at the compiled HTML docs.

> src/java.base/share/classes/java/net/Inet4Address.java line 224:
> 
>> 222:      * Inet4Address##format valid IPv4 address} an {@code IllegalArgumentException} is thrown.
>> 223:      * <p> This method doesn't block, i.e. no hostname lookup is performed.
>> 224:      *
> 
> Please describe the syntax this metod accepts here, in the normative part of the specification.

I updated the docs to link to the class specification, also added an anchor in the spec.

> src/java.base/share/classes/java/net/Inet4Address.java line 232:
> 
>> 230:      * {@code 255} for {@code "0255"}, {@linkplain Inet4Address#ofPosixLiteral this}
>> 231:      * method interprets the numbers based on their prefix (hexadecimal {@code "0x"},
>> 232:      * octal {@code "0"}) and returns {@code 173} for {@code "0255"}.
> 
> Suggestion:
> 
>      * when {@code posixIPAddressLiteral} parameter contains address segments with
>      * leading zeroes. An address segment with a leading zero is always parsed as an octal
>      * number by {@code  ofPosixLiteral()}, therefore {@code 0255} (octal) will be parsed as
>      * {@code 173} (decimal) by this method. On the other hand, {@link Inet4Address#ofLiteral
>      * Inet4Address.ofLiteral} ignores leading zeros, parses all numbers as decimal and produces
>      * {@code 255}. Where this method would parse {@code 0256.0256.0256.0256} (octal) and 
>      * produce {@code 174.174.174.174} (decimal) in four dotted quad notation, 
>      * {@code Inet4Address.ofLiteral} will throw {@code IllegalArgumentException}.

Ok, accepted. I will put this together with other suggestions in a separate commit (this exact text above had some minor whitespace issues).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1559668820
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1559668110
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1559670713
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1559669723

From dfuchs at openjdk.org  Thu Apr 11 09:31:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Apr 2024 09:31:44 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v2]
In-Reply-To: <Dh_ubSa03PrKi0SE1zkxvSyt5-wgs6qSTA9Wu7HZsOE=.ce7adb24-69d6-4354-be9f-612fe18e686f@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <Dh_ubSa03PrKi0SE1zkxvSyt5-wgs6qSTA9Wu7HZsOE=.ce7adb24-69d6-4354-be9f-612fe18e686f@github.com>
Message-ID: <vhbTJl5vHAKHCxbAfGGsgVD5gbDhz_NTb1SCxqxpFCI=.5cbd7009-7af5-4295-a4fc-818e1a4640aa@github.com>

On Wed, 10 Apr 2024 15:34:22 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
>> 
>> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
>> 
>> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
>> 
>> "If a literal IP address is supplied, only the validity of the address format is checked."
>> 
>> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
>> 
>> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
>> 
>> - `IPAddressUtil#parseB...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review comments in Javadoc

Changes requested by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18493#pullrequestreview-1993681171

From dfuchs at openjdk.org  Thu Apr 11 09:31:45 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Apr 2024 09:31:45 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v2]
In-Reply-To: <Wxs1ShNxsZnbqG0uUokrqM8iHPfBBkbIKGl-A7XXbjI=.e964ab89-7e41-4a78-8e0e-58a6574f0281@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <dZ8YcwRRRo9b0C3v3wO4Mqb4oNLD5uD3k7kaQdoajAg=.e3dc5b0a-8c58-4d62-a931-1a9d41a690da@github.com>
 <Wxs1ShNxsZnbqG0uUokrqM8iHPfBBkbIKGl-A7XXbjI=.e964ab89-7e41-4a78-8e0e-58a6574f0281@github.com>
Message-ID: <uw6Rh6kRNDgzWWVy2nCLHF2rw82aNKxds5OPzy_v8P8=.3f2fbe23-cac1-4a39-b2ca-0948aaf75db5@github.com>

On Wed, 10 Apr 2024 15:30:52 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Inet4Address.java line 103:
>> 
>>> 101:  * octal and hexadecimal address segments. Please refer to
>>> 102:  * <a href="https://www.ietf.org/rfc/rfc6943.html#section-3.1.1"> <i>RFC&nbsp;
>>> 103:  * 6943: Issues in Identifier Comparison for Security Purposes</i></a>.
>> 
>> Suggestion:
>> 
>>  * <p> The above forms adhere "strict" decimal-only syntax.
>>  * Additionally, the
>>  * {@link Inet4Address#ofPosixLiteral(String)} method implements a
>>  * <a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html">
>>  * POSIX {@code inet_addr}</a> compatible "loose" parsing algorithm, allowing
>>  * octal and hexadecimal address segments. Please refer to
>>  * <a href="https://www.ietf.org/rfc/rfc6943.html#section-3.1.1"> <i>RFC&nbsp;
>>  * 6943: Issues in Identifier Comparison for Security Purposes</i></a>.
>
> This removes the reference of loose syntax that was opposed to strict syntax. Would you think to also remove the word "strict"?

@sercher the word "loose" is still there - it's not removed?

>> src/java.base/share/classes/java/net/Inet4Address.java line 224:
>> 
>>> 222:      * Inet4Address##format valid IPv4 address} an {@code IllegalArgumentException} is thrown.
>>> 223:      * <p> This method doesn't block, i.e. no hostname lookup is performed.
>>> 224:      *
>> 
>> Please describe the syntax this metod accepts here, in the normative part of the specification.
>
> I updated the docs to link to the class specification, also added an anchor in the spec.

I would rather move the description of the loose syntax fully here, since the only method that accepts it is `Inet4Address.ofPosixLiteral`. We need to be absolutely clear that this is the only method that accepts it. Also, I feel that a link to an external document is not sufficient in this case. It's good to have it, but since we actually implement the parsing in java we should describe clearly the accepted syntax and how we parse it here. We have no control over external documents, they can move, their content can change, etc... I believe that the anchor `Inet4Address##format-posix` should lead to this method here, not to the class-level documentation. Having a short paragraph in the class level documentation that explains that an alternative loose syntax is accepted by a specific method is fine. However I don't feel that describing this loose syntax in the class level API documentation is a good idea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1560697697
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1560705046

From schernyshev at openjdk.org  Thu Apr 11 10:01:12 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 11 Apr 2024 10:01:12 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v3]
In-Reply-To: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
Message-ID: <fSYwRuXvhDeZfQCNVg0yWhxPp82IfHxLeykR1wZYWLs=.55195dc7-2aab-4e4f-9eec-e3f6efc95b57@github.com>

> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
> 
> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
> 
> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
> 
> "If a literal IP address is supplied, only the validity of the address format is checked."
> 
> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
> 
> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
> 
> - `IPAddressUtil#parseBsdLiteralV4()` method is e...

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

  Update src/java.base/share/classes/java/net/Inet4Address.java
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18493/files
  - new: https://git.openjdk.org/jdk/pull/18493/files/4230f0f2..ebcbef43

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

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

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

From duke at openjdk.org  Thu Apr 11 10:01:13 2024
From: duke at openjdk.org (Florent Guillaume)
Date: Thu, 11 Apr 2024 10:01:13 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v2]
In-Reply-To: <Dh_ubSa03PrKi0SE1zkxvSyt5-wgs6qSTA9Wu7HZsOE=.ce7adb24-69d6-4354-be9f-612fe18e686f@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <Dh_ubSa03PrKi0SE1zkxvSyt5-wgs6qSTA9Wu7HZsOE=.ce7adb24-69d6-4354-be9f-612fe18e686f@github.com>
Message-ID: <68f9khA_oujuJiFycNyhbJA45kppiRXl9gMLK3G5avk=.1ad9a193-517d-48d2-a575-d9cf2507ddd6@github.com>

On Wed, 10 Apr 2024 15:34:22 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
>> 
>> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
>> 
>> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
>> 
>> "If a literal IP address is supplied, only the validity of the address format is checked."
>> 
>> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
>> 
>> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
>> 
>> - `IPAddressUtil#parseB...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review comments in Javadoc

test/jdk/java/net/InetAddress/OfLiteralTest.java line 232:

> 230:                 //      with leading 0s treated as octal segment prefixes
> 231:                 Arguments.of(InetAddressClass.INET4_ADDRESS_POSIX,
> 232:                         "0177.0200401", ipv4_127_1_1_1),

Instead of 127.0.1.1 and 127.1.1.1 I would suggest instead testing 127.0.1.2 and 127.1.2.3 so that endianness is demonstrated (i.e. which of 0x102 vs 0x201 gives that result, similarly for octal).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1560761102

From schernyshev at openjdk.org  Thu Apr 11 10:01:12 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 11 Apr 2024 10:01:12 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v3]
In-Reply-To: <uw6Rh6kRNDgzWWVy2nCLHF2rw82aNKxds5OPzy_v8P8=.3f2fbe23-cac1-4a39-b2ca-0948aaf75db5@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <dZ8YcwRRRo9b0C3v3wO4Mqb4oNLD5uD3k7kaQdoajAg=.e3dc5b0a-8c58-4d62-a931-1a9d41a690da@github.com>
 <Wxs1ShNxsZnbqG0uUokrqM8iHPfBBkbIKGl-A7XXbjI=.e964ab89-7e41-4a78-8e0e-58a6574f0281@github.com>
 <uw6Rh6kRNDgzWWVy2nCLHF2rw82aNKxds5OPzy_v8P8=.3f2fbe23-cac1-4a39-b2ca-0948aaf75db5@github.com>
Message-ID: <4BF--FmeFWT_4A734bEaonTPTzoDfE64n81AntBqyws=.c606279f-25b7-42b8-9599-627a58e37db5@github.com>

On Thu, 11 Apr 2024 09:15:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This removes the reference of loose syntax that was opposed to strict syntax. Would you think to also remove the word "strict"?
>
> @sercher the word "loose" is still there - it's not removed?

Right. Apologies, i didn't notice it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1560758608

From schernyshev at openjdk.org  Thu Apr 11 12:58:07 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 11 Apr 2024 12:58:07 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v4]
In-Reply-To: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
Message-ID: <n2-WX6p9QKWr2-B6YFsqg4R87TaLxqfbfOo0VTkpCIo=.312809d5-ffa2-48e4-8584-910c6c10cce8@github.com>

> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
> 
> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
> 
> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
> 
> "If a literal IP address is supplied, only the validity of the address format is checked."
> 
> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
> 
> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
> 
> - `IPAddressUtil#parseBsdLiteralV4()` method is e...

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

  moved algorithm description from class spec to the method spec, updated code examples to reflect the network byte order

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18493/files
  - new: https://git.openjdk.org/jdk/pull/18493/files/ebcbef43..005fd11e

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

  Stats: 92 lines in 2 files changed: 57 ins; 22 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18493.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18493/head:pull/18493

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

From schernyshev at openjdk.org  Thu Apr 11 12:58:07 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 11 Apr 2024 12:58:07 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v4]
In-Reply-To: <uw6Rh6kRNDgzWWVy2nCLHF2rw82aNKxds5OPzy_v8P8=.3f2fbe23-cac1-4a39-b2ca-0948aaf75db5@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <dZ8YcwRRRo9b0C3v3wO4Mqb4oNLD5uD3k7kaQdoajAg=.e3dc5b0a-8c58-4d62-a931-1a9d41a690da@github.com>
 <Wxs1ShNxsZnbqG0uUokrqM8iHPfBBkbIKGl-A7XXbjI=.e964ab89-7e41-4a78-8e0e-58a6574f0281@github.com>
 <uw6Rh6kRNDgzWWVy2nCLHF2rw82aNKxds5OPzy_v8P8=.3f2fbe23-cac1-4a39-b2ca-0948aaf75db5@github.com>
Message-ID: <XGvF-eEhkjJz8M5X3DglWoTeENvBv-u-r7AIj-dtb1I=.2446435a-f6cb-4e26-9400-097b4f619e90@github.com>

On Thu, 11 Apr 2024 09:21:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I updated the docs to link to the class specification, also added an anchor in the spec.
>
> I would rather move the description of the loose syntax fully here, since the only method that accepts it is `Inet4Address.ofPosixLiteral`. We need to be absolutely clear that this is the only method that accepts it. Also, I feel that a link to an external document is not sufficient in this case. It's good to have it, but since we actually implement the parsing in java we should describe clearly the accepted syntax and how we parse it here. We have no control over external documents, they can move, their content can change, etc... I believe that the anchor `Inet4Address##format-posix` should lead to this method here, not to the class-level documentation. Having a short paragraph in the class level documentation that explains that an alternative loose syntax is accepted by a specific method is fine. However I don't feel that describing this loose syntax in the class level API documentation is a good idea.

Moved the algorithm description from the class spec to method spec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1560980601

From schernyshev at openjdk.org  Thu Apr 11 12:58:08 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 11 Apr 2024 12:58:08 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v2]
In-Reply-To: <68f9khA_oujuJiFycNyhbJA45kppiRXl9gMLK3G5avk=.1ad9a193-517d-48d2-a575-d9cf2507ddd6@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <Dh_ubSa03PrKi0SE1zkxvSyt5-wgs6qSTA9Wu7HZsOE=.ce7adb24-69d6-4354-be9f-612fe18e686f@github.com>
 <68f9khA_oujuJiFycNyhbJA45kppiRXl9gMLK3G5avk=.1ad9a193-517d-48d2-a575-d9cf2507ddd6@github.com>
Message-ID: <v8UDJlKUif31zqLUNKTBcYyTSWjcqKawT7q5k2bqsos=.2274f644-e9e9-4d8b-9da3-a07c80df65a1@github.com>

On Thu, 11 Apr 2024 09:56:56 GMT, Florent Guillaume <duke at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressed review comments in Javadoc
>
> test/jdk/java/net/InetAddress/OfLiteralTest.java line 232:
> 
>> 230:                 //      with leading 0s treated as octal segment prefixes
>> 231:                 Arguments.of(InetAddressClass.INET4_ADDRESS_POSIX,
>> 232:                         "0177.0200401", ipv4_127_1_1_1),
> 
> Instead of 127.0.1.1 and 127.1.1.1 I would suggest instead testing 127.0.1.2 and 127.1.2.3 so that endianness is demonstrated (i.e. which of 0x102 vs 0x201 gives that result, similarly for octal).

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1560979314

From dfuchs at openjdk.org  Thu Apr 11 15:24:45 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Apr 2024 15:24:45 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v4]
In-Reply-To: <n2-WX6p9QKWr2-B6YFsqg4R87TaLxqfbfOo0VTkpCIo=.312809d5-ffa2-48e4-8584-910c6c10cce8@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <n2-WX6p9QKWr2-B6YFsqg4R87TaLxqfbfOo0VTkpCIo=.312809d5-ffa2-48e4-8584-910c6c10cce8@github.com>
Message-ID: <7EKTDU5hpkOkxxhWURcpjngVFEdSNqTg52iAJHHc24w=.0c0f415b-7446-48f7-92e0-1c84f2751459@github.com>

On Thu, 11 Apr 2024 12:58:07 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
>> 
>> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
>> 
>> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
>> 
>> "If a literal IP address is supplied, only the validity of the address format is checked."
>> 
>> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
>> 
>> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
>> 
>> - `IPAddressUtil#parseB...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved algorithm description from class spec to the method spec, updated code examples to reflect the network byte order

Thanks for taking on the feedback @sercher . I believe we're in a much better place now. I will let @AlekseiEfimov comment on the test and implementation.

src/java.base/share/classes/java/net/Inet4Address.java line 195:

> 193:      * Creates an {@code Inet4Address} based on the provided {@linkplain
> 194:      * Inet4Address##format textual representation} of an IPv4 address in
> 195:      * POSIX {@code inet_addr} compatible form.

Suggestion:

     * Creates an {@code Inet4Address} based on the provided {@linkplain
     * Inet4Address##format-posix textual representation of an IPv4 address in
     * POSIX {@code inet_addr} compatible form}.


Alternatively you could just remove the link, since the format description is just below.

src/java.base/share/classes/java/net/Inet4Address.java line 245:

> 243:      * {@code IllegalArgumentException}.
> 244:      *
> 245:      * @param posixIPAddressLiteral the textual representation of an IPv4 address.

Suggestion:

     * @param posixIPAddressLiteral a textual representation of an IPv4 address.

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

PR Review: https://git.openjdk.org/jdk/pull/18493#pullrequestreview-1994510777
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1561205498
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1561210422

From schernyshev at openjdk.org  Thu Apr 11 15:27:55 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 11 Apr 2024 15:27:55 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
Message-ID: <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>

> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
> 
> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
> 
> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
> 
> "If a literal IP address is supplied, only the validity of the address format is checked."
> 
> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
> 
> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
> 
> - `IPAddressUtil#parseBsdLiteralV4()` method is e...

Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/net/Inet4Address.java
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Update src/java.base/share/classes/java/net/Inet4Address.java
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18493/files
  - new: https://git.openjdk.org/jdk/pull/18493/files/005fd11e..d05d9d54

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

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

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

From ihse at openjdk.org  Mon Apr 15 12:01:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 15 Apr 2024 12:01:49 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <x59-5FRsoG8BgigMF9cO8pdIPeevWfwdq8ejSxnvRSg=.798655fc-6685-4a4c-b460-46f0b5da5ab2@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

I'll close this now. I guess if we want to make progress on this, we will probably have to evaluate every individual warning separately, and add those which does make sense (e.g. `import-preprocessor-directive-pedantic`), and ignore the rest. I personally will not have time nor interest in driving this forward, at least not right now.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-2056659089

From ihse at openjdk.org  Mon Apr 15 12:01:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 15 Apr 2024 12:01:49 GMT
Subject: Withdrawn: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <rrtpUalai1V2FJAlnUszRYP6DiX3YbrT93jC2_hGk_I=.78d8446b-dbba-4e11-8bb7-b7b6fa326c14@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

This pull request has been closed without being integrated.

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

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

From vromero at openjdk.org  Tue Apr 16 18:05:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 16 Apr 2024 18:05:06 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v4]
In-Reply-To: <qtjsShzhgQEKyiwIbZ4ihv1xT7wIwZsWJ6bpqsVbjwg=.305c91fe-5b83-426c-ac82-ca6c34a8cb61@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
 <qtjsShzhgQEKyiwIbZ4ihv1xT7wIwZsWJ6bpqsVbjwg=.305c91fe-5b83-426c-ac82-ca6c34a8cb61@github.com>
Message-ID: <5H9FriMwHXEi75SibY_zoPVu8LcLFmLgVrHKGL58Vh0=.cc3bbbc7-669b-471c-b4d2-ac54cf6df44c@github.com>

On Tue, 9 Apr 2024 15:36:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
>> 
>> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
>> 
>> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
>> 
>> The changes are summarized here:
>> 
>> #### 1. Generalize how we categorize references
>> 
>> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
>> 
>> Previously the `Ref` categories were:
>> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
>> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
>> * `VarRef` - A local variable or method parameter currently in scope
>> * `ExprRef` - An object reference sitting on top of the Java execution stack
>> * `YieldRef` - The current switch expression's yield value(s)
>> * `ReturnRef` - The current method's return value(s)
>> 
>> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
>> 
>> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
>> 
>> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
>> 
>> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
>> 
>> #### 2. Track the types...
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into JDK-8317376
>  - Merge branch 'master' into JDK-8317376
>  - Merge branch 'master' into JDK-8317376
>  - Merge branch 'master' into JDK-8317376
>  - Merge branch 'master' into JDK-8317376
>  - Javadoc++
>  - Merge branch 'master' into JDK-8317376
>  - Several improvements to the 'this' escape analyzer.
>    
>    - Track direct, indirect, and outer references for all Ref types.
>    - Keep type information about all references to improve tracking precision.
>    - Track enhanced for() invocations of iterator(), hasNext(), and next().
>    - Don't report an escape of a non-public outer instances as a leak.
>    - Fix omitted tracking of references from newly instantiated instances.
>    - Fix omitted tracking of leaks via lambda return values.
>    - Remove unneccesary suppressions of this-escape lint warning.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1343:

> 1341:      *    but also NOT an enclosing outer class of 'currentClass'.
> 1342:      */
> 1343:     private boolean isExplicitThisReference(Types types, Type.ClassType currentClass, JCFieldAccess select) {

suggestion: why not moving this method to TreeInfo already in preparation for the changes coming with flexible constructor bodies?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16208#discussion_r1567757547

From acobbs at openjdk.org  Tue Apr 16 19:15:14 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 Apr 2024 19:15:14 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v5]
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <yZaMBdiWd8Q641dDm-qYoeY2I1_JOGZZwwjjIFRXE4A=.7db825b2-6abd-4a42-ae82-b1c6fcea12bd@github.com>

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Synchronize TreeInfo.isExplicitThisReference() with PR #18088.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16208/files
  - new: https://git.openjdk.org/jdk/pull/16208/files/e09e4229..304a92b6

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

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

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

From acobbs at openjdk.org  Tue Apr 16 19:15:18 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 Apr 2024 19:15:18 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v4]
In-Reply-To: <5H9FriMwHXEi75SibY_zoPVu8LcLFmLgVrHKGL58Vh0=.cc3bbbc7-669b-471c-b4d2-ac54cf6df44c@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
 <qtjsShzhgQEKyiwIbZ4ihv1xT7wIwZsWJ6bpqsVbjwg=.305c91fe-5b83-426c-ac82-ca6c34a8cb61@github.com>
 <5H9FriMwHXEi75SibY_zoPVu8LcLFmLgVrHKGL58Vh0=.cc3bbbc7-669b-471c-b4d2-ac54cf6df44c@github.com>
Message-ID: <2Uim0unYk6q6KQnNsOM68Ki8vWom0I4nnIcxGonJP9U=.69837268-3b52-45fc-a6f9-71086608142a@github.com>

On Tue, 16 Apr 2024 18:00:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into JDK-8317376
>>  - Merge branch 'master' into JDK-8317376
>>  - Merge branch 'master' into JDK-8317376
>>  - Merge branch 'master' into JDK-8317376
>>  - Merge branch 'master' into JDK-8317376
>>  - Javadoc++
>>  - Merge branch 'master' into JDK-8317376
>>  - Several improvements to the 'this' escape analyzer.
>>    
>>    - Track direct, indirect, and outer references for all Ref types.
>>    - Keep type information about all references to improve tracking precision.
>>    - Track enhanced for() invocations of iterator(), hasNext(), and next().
>>    - Don't report an escape of a non-public outer instances as a leak.
>>    - Fix omitted tracking of references from newly instantiated instances.
>>    - Fix omitted tracking of leaks via lambda return values.
>>    - Remove unneccesary suppressions of this-escape lint warning.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1343:
> 
>> 1341:      *    but also NOT an enclosing outer class of 'currentClass'.
>> 1342:      */
>> 1343:     private boolean isExplicitThisReference(Types types, Type.ClassType currentClass, JCFieldAccess select) {
> 
> suggestion: why not moving this method to TreeInfo already in preparation for the changes coming with flexible constructor bodies?

Good idea - thanks. Done in 304a92b619e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16208#discussion_r1567832080

From aefimov at openjdk.org  Tue Apr 16 22:42:00 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 16 Apr 2024 22:42:00 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
Message-ID: <rHV5qzf7RJC-gEZYjSaJFFIU61SPK0SUR72pDpbND28=.f8456aaa-e8f2-406c-9563-c9dd2184e317@github.com>

On Thu, 11 Apr 2024 15:27:55 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
>> 
>> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
>> 
>> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
>> 
>> "If a literal IP address is supplied, only the validity of the address format is checked."
>> 
>> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
>> 
>> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
>> 
>> - `IPAddressUtil#parseB...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/Inet4Address.java
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/Inet4Address.java
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

The parsing code and the test changes look good to me with a couple of minor suggestions.

src/java.base/share/classes/java/net/Inet4Address.java line 321:

> 319:      * cannot be parsed as an IPv4 address literal and {@code throwIAE} is {@code true}.
> 320:      */
> 321:     static Inet4Address parseAddressStringPosix(String addressLiteral, boolean throwIAE) {

This method can be made `private` since it's only used in the `Inet4Address` class.
`throwIAE`  is always `true` and therefore can be removed.

src/java.base/share/classes/sun/net/util/IPAddressUtil.java line 711:

> 709:                 fieldValue = parseV4FieldBsd(radix, charBuffer, fieldNumber);
> 710:                 if (fieldValue >= 0) {
> 711:                     if (fieldValue < 256) {

Maybe this check can be acccompanied with a comment to clarify the following, ie if a field value is greater than `255` then it can only be the last field. If it is not the last one then `parseV4FieldBsd` enforces this limit and will return `null`.
That would help future code maintainers :)

src/java.base/share/classes/sun/net/util/IPAddressUtil.java line 730:

> 728:             return null;
> 729:         }
> 730:         // If the last fieldValue is greater than 255 (fieldNumer < 4),

typo:
Suggestion:

        // If the last fieldValue is greater than 255 (fieldNumber < 4),

test/jdk/java/net/InetAddress/OfLiteralTest.java line 26:

> 24: /* @test
> 25:  * @bug 8272215 8315767
> 26:  * @summary Test for ofLiteral API in InetAddress classes

The test summary can mention that `ofLiteralPosix` is also tested here

test/jdk/java/net/InetAddress/OfLiteralTest.java line 126:

> 124:         byte[] ipv4_0_0_0_34 = new byte[]{0, 0, 0, 34};
> 125: 
> 126:         // 127.0.1.1 address bytes

Update comment to match the code:
Suggestion:

        // 127.0.1.2 address bytes

test/jdk/java/net/InetAddress/OfLiteralTest.java line 129:

> 127:         byte[] ipv4_127_0_1_2 = new byte[]{127, 0, 1, 2};
> 128: 
> 129:         // 127.1.1.1 address bytes

Update comment to match the code:
Suggestion:

        // 127.1.2.3 address bytes

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

PR Review: https://git.openjdk.org/jdk/pull/18493#pullrequestreview-2004651764
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1567975404
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1567996061
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1567984828
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1568000966
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1567998369
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1567998873

From jpai at openjdk.org  Wed Apr 17 02:17:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Apr 2024 02:17:01 GMT
Subject: RFR: Merge 33d7127
Message-ID: <R4zdHhoo50zlsRARpFtLHPO1y_Qx-ZNK5P8pint8OvI=.64472a44-f417-43f2-9278-3318593c53ae@github.com>

This brings in the CPU24_04 changes.

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

Commit messages:
 - 8322122: Enhance generation of addresses
 - 8319851: Improve exception logging
 - 8318340: Improve RSA key implementations
 - 8315708: Enhance HTTP/2 client usage

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/18807/files
  Stats: 182 lines in 19 files changed: 58 ins; 51 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/18807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18807/head:pull/18807

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

From dfuchs at openjdk.org  Wed Apr 17 10:34:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 17 Apr 2024 10:34:41 GMT
Subject: RFR: Merge 33d7127
In-Reply-To: <R4zdHhoo50zlsRARpFtLHPO1y_Qx-ZNK5P8pint8OvI=.64472a44-f417-43f2-9278-3318593c53ae@github.com>
References: <R4zdHhoo50zlsRARpFtLHPO1y_Qx-ZNK5P8pint8OvI=.64472a44-f417-43f2-9278-3318593c53ae@github.com>
Message-ID: <cdoKSGmVmL3Bd26MSdda7vZC_qP1VEW3nKvrZzPslts=.f5fef5b8-1b49-4b3c-b04d-96745435b867@github.com>

On Wed, 17 Apr 2024 01:09:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This brings in the CPU24_04 changes.

This looks reasonable. I haven't been involved in all the fixes here - but I haven't spotted anything obviously wrong. The changes to the ConnectionPool look right. If some of the fixes had conflicts that required fixing then asking confirmation from one person involved in their respective reviews would be good.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18807#pullrequestreview-2005685119

From jpai at openjdk.org  Wed Apr 17 10:40:41 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Apr 2024 10:40:41 GMT
Subject: RFR: Merge 33d7127
In-Reply-To: <R4zdHhoo50zlsRARpFtLHPO1y_Qx-ZNK5P8pint8OvI=.64472a44-f417-43f2-9278-3318593c53ae@github.com>
References: <R4zdHhoo50zlsRARpFtLHPO1y_Qx-ZNK5P8pint8OvI=.64472a44-f417-43f2-9278-3318593c53ae@github.com>
Message-ID: <-11ibMJGQY3-ik4a6PAmd2pFKovbIHCSKFcdZfFN034=.4d09b5c4-b95e-4bdb-8ad6-8400d6330988@github.com>

On Wed, 17 Apr 2024 01:09:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This brings in the CPU24_04 changes.

Thank you Daniel for the review.

> If some of the fixes had conflicts that required fixing then asking confirmation from one person involved in their respective reviews would be good.

The specific commits in this merge were all clean and didn't require any conflict resolution. Internal CI testing of tier1, tier2 and tier3 too completed successfully without issues.

I'll go ahead and integrate this shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/18807#issuecomment-2060955414

From jpai at openjdk.org  Wed Apr 17 10:45:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Apr 2024 10:45:12 GMT
Subject: RFR: Merge 33d7127 [v2]
In-Reply-To: <R4zdHhoo50zlsRARpFtLHPO1y_Qx-ZNK5P8pint8OvI=.64472a44-f417-43f2-9278-3318593c53ae@github.com>
References: <R4zdHhoo50zlsRARpFtLHPO1y_Qx-ZNK5P8pint8OvI=.64472a44-f417-43f2-9278-3318593c53ae@github.com>
Message-ID: <pWwPOlnz_J7iSs4JCtiIw0s0XGohFun145EINRtKiW4=.a427441f-71c5-4382-9522-4dce2cc94d38@github.com>

> This brings in the CPU24_04 changes.

Jaikiran Pai 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18807/files
  - new: https://git.openjdk.org/jdk/pull/18807/files/33d71275..33d71275

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

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

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

From jpai at openjdk.org  Wed Apr 17 10:45:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Apr 2024 10:45:13 GMT
Subject: Integrated: Merge 33d7127
In-Reply-To: <R4zdHhoo50zlsRARpFtLHPO1y_Qx-ZNK5P8pint8OvI=.64472a44-f417-43f2-9278-3318593c53ae@github.com>
References: <R4zdHhoo50zlsRARpFtLHPO1y_Qx-ZNK5P8pint8OvI=.64472a44-f417-43f2-9278-3318593c53ae@github.com>
Message-ID: <oxKvJvNFaQsI4OkL1pT-HdscI_FCYTcUj7v05fYcUkE=.ddaf3e23-3d03-4d72-bbcf-fbe64cbf843a@github.com>

On Wed, 17 Apr 2024 01:09:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This brings in the CPU24_04 changes.

This pull request has now been integrated.

Changeset: d2f9a1eb
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d2f9a1eb9709dbd8b1e7b0d1c14b7876281d7f23
Stats:     182 lines in 19 files changed: 58 ins; 51 del; 73 mod

Merge

Reviewed-by: dfuchs

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

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

From jpai at openjdk.org  Wed Apr 17 14:05:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Apr 2024 14:05:00 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
Message-ID: <Mid07HkKU5AJC0-vX6xLPPIEZBzo6A2e-Z2RFgcISlI=.d1ee714a-4676-4e77-91d8-cf30707a31bd@github.com>

On Thu, 11 Apr 2024 15:27:55 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
>> 
>> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
>> 
>> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
>> 
>> "If a literal IP address is supplied, only the validity of the address format is checked."
>> 
>> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
>> 
>> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
>> 
>> - `IPAddressUtil#parseB...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/Inet4Address.java
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/Inet4Address.java
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

Should we be setting any expectations by specifying what  `InetAddress.getHostAddress()` will return for an `Inet4Address` constructed using this new `Inet4Address.ofPosixLiteral()` method? In its current form I believe it will continue to return a decimal representation of the IP address. My guess is that we want it to continue behaving that way?

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

PR Comment: https://git.openjdk.org/jdk/pull/18493#issuecomment-2061339414

From dfuchs at openjdk.org  Wed Apr 17 14:19:01 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 17 Apr 2024 14:19:01 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <Mid07HkKU5AJC0-vX6xLPPIEZBzo6A2e-Z2RFgcISlI=.d1ee714a-4676-4e77-91d8-cf30707a31bd@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
 <Mid07HkKU5AJC0-vX6xLPPIEZBzo6A2e-Z2RFgcISlI=.d1ee714a-4676-4e77-91d8-cf30707a31bd@github.com>
Message-ID: <sTzR7GWOqkKccIyNA3uL0P9DRAmAcWVDRf6kiI49JgA=.7c2d4c9d-3a29-4253-b4cf-0bfc5a75be90@github.com>

On Wed, 17 Apr 2024 14:02:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Should we be setting any expectations by specifying what InetAddress.getHostAddress() will return for an Inet4Address constructed using this new Inet4Address.ofPosixLiteral() method? In its current form I believe it will continue to return a decimal representation of the IP address. My guess is that we want it to continue behaving that way?

In the InetAddress class level API documentation we have:

 * <p> For methods that return a textual representation as output
 * value, the first form, i.e. a dotted-quad string, is used.


Do you think it should be reiterated in the `@apiNote` of the `ofPosixLiteral` method?

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

PR Comment: https://git.openjdk.org/jdk/pull/18493#issuecomment-2061370892

From jpai at openjdk.org  Wed Apr 17 14:30:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Apr 2024 14:30:02 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <sTzR7GWOqkKccIyNA3uL0P9DRAmAcWVDRf6kiI49JgA=.7c2d4c9d-3a29-4253-b4cf-0bfc5a75be90@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
 <Mid07HkKU5AJC0-vX6xLPPIEZBzo6A2e-Z2RFgcISlI=.d1ee714a-4676-4e77-91d8-cf30707a31bd@github.com>
 <sTzR7GWOqkKccIyNA3uL0P9DRAmAcWVDRf6kiI49JgA=.7c2d4c9d-3a29-4253-b4cf-0bfc5a75be90@github.com>
Message-ID: <CCuxOXMT0M-OAtHs03k-KuK3tGD8gVrXMPm9JW9G2PM=.9686b355-7866-41a0-82e0-aa39f272c2e8@github.com>

On Wed, 17 Apr 2024 14:16:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > Should we be setting any expectations by specifying what InetAddress.getHostAddress() will return for an Inet4Address constructed using this new Inet4Address.ofPosixLiteral() method? In its current form I believe it will continue to return a decimal representation of the IP address. My guess is that we want it to continue behaving that way?
> 
> In the InetAddress class level API documentation we have:
> 
> ```
>  * <p> For methods that return a textual representation as output
>  * value, the first form, i.e. a dotted-quad string, is used.
> ```
> 
> Do you think it should be reiterated in the `@apiNote` of the `ofPosixLiteral` method?

The changes proposed in this PR introduce a new paragraph in the class level documentation just before the line which states the dotted-quad string. So I think it may not be clear enough whether dotted-quad string implies decimal values (`127.0.0.1`) or octal dotted-quad string (`0177.0.0.1`) or hexadecimal dotted-quad string (`0x7F.0.0.1`). So I think updating that sentence in class level documentation might help.

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

PR Comment: https://git.openjdk.org/jdk/pull/18493#issuecomment-2061393325

From dfuchs at openjdk.org  Wed Apr 17 14:40:01 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 17 Apr 2024 14:40:01 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <CCuxOXMT0M-OAtHs03k-KuK3tGD8gVrXMPm9JW9G2PM=.9686b355-7866-41a0-82e0-aa39f272c2e8@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
 <Mid07HkKU5AJC0-vX6xLPPIEZBzo6A2e-Z2RFgcISlI=.d1ee714a-4676-4e77-91d8-cf30707a31bd@github.com>
 <sTzR7GWOqkKccIyNA3uL0P9DRAmAcWVDRf6kiI49JgA=.7c2d4c9d-3a29-4253-b4cf-0bfc5a75be90@github.com>
 <CCuxOXMT0M-OAtHs03k-KuK3tGD8gVrXMPm9JW9G2PM=.9686b355-7866-41a0-82e0-aa39f272c2e8@github.com>
Message-ID: <I6tRkYx0P0FS3-ucjI8jNgQg9ed1lJcMduKL7xN91YY=.31452090-98af-469f-b52c-228083a1c0a0@github.com>

On Wed, 17 Apr 2024 14:26:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The changes proposed in this PR introduce a new paragraph in the class level documentation just before the line which states the dotted-quad string. So I think it may not be clear enough whether dotted-quad string implies decimal values (`127.0.0.1`) or octal dotted-quad string (`0177.0.0.1`) or hexadecimal dotted-quad string (`0x7F.0.0.1`). So I think updating that sentence in class level documentation might help.

Good point.

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

PR Comment: https://git.openjdk.org/jdk/pull/18493#issuecomment-2061415792

From dfuchs at openjdk.org  Wed Apr 17 14:40:01 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 17 Apr 2024 14:40:01 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
Message-ID: <ZdlJt5iRBrmnAbEu0frCc-UeZe8QybDOqI8elVPuw84=.759f6288-6311-440d-b0c1-5c4155066aa2@github.com>

On Thu, 11 Apr 2024 15:27:55 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
>> 
>> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
>> 
>> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
>> 
>> "If a literal IP address is supplied, only the validity of the address format is checked."
>> 
>> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
>> 
>> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
>> 
>> - `IPAddressUtil#parseB...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/net/Inet4Address.java
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/net/Inet4Address.java
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

src/java.base/share/classes/java/net/Inet4Address.java line 104:

> 102:  * Purposes</i></a>.
> 103:  * <p> For methods that return a textual representation as output
> 104:  * value, the first form, i.e. a dotted-quad string, is used.

Maybe something like this?

Suggestion:

 * <p> For methods that return a textual representation as output
 * value, the first form, i.e. a dotted-quad string in strict decimal notation, is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1568961262

From jpai at openjdk.org  Wed Apr 17 14:51:43 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Apr 2024 14:51:43 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <ZdlJt5iRBrmnAbEu0frCc-UeZe8QybDOqI8elVPuw84=.759f6288-6311-440d-b0c1-5c4155066aa2@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
 <ZdlJt5iRBrmnAbEu0frCc-UeZe8QybDOqI8elVPuw84=.759f6288-6311-440d-b0c1-5c4155066aa2@github.com>
Message-ID: <b0AZF89W4Tnq2SWrQm2efZS22QsCWGGKzXn1TL3EM7g=.62ecd588-1f63-48f8-ba9c-d0a1f53a215e@github.com>

On Wed, 17 Apr 2024 14:37:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/java/net/Inet4Address.java
>>    
>>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/net/Inet4Address.java
>>    
>>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>
> src/java.base/share/classes/java/net/Inet4Address.java line 104:
> 
>> 102:  * Purposes</i></a>.
>> 103:  * <p> For methods that return a textual representation as output
>> 104:  * value, the first form, i.e. a dotted-quad string, is used.
> 
> Maybe something like this?
> 
> Suggestion:
> 
>  * <p> For methods that return a textual representation as output
>  * value, the first form, i.e. a dotted-quad string in strict decimal notation, is used.

Yes, I think this makes it clear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1568978096

From clanger at openjdk.org  Wed Apr 17 14:59:07 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 17 Apr 2024 14:59:07 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of KeepAliveTest
Message-ID: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>

The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.

It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test cases. Each scenario is tested in an own freshly spawned JVM via the @run main/othervm directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each type of client settings, the VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.

E.g. on my developer laptop runtime went down from ~100s to ~10s.

I also made some additional cleanups in the test.

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

Commit messages:
 - JDK-8330523

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

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

From vromero at openjdk.org  Wed Apr 17 15:28:03 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Apr 2024 15:28:03 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v5]
In-Reply-To: <yZaMBdiWd8Q641dDm-qYoeY2I1_JOGZZwwjjIFRXE4A=.7db825b2-6abd-4a42-ae82-b1c6fcea12bd@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
 <yZaMBdiWd8Q641dDm-qYoeY2I1_JOGZZwwjjIFRXE4A=.7db825b2-6abd-4a42-ae82-b1c6fcea12bd@github.com>
Message-ID: <bHcrbCnG4ke4q1RmIyc3ktxba8FKsqUf_H9eVKs2Pc0=.190776a8-df6c-4a1d-ac32-9359171c0114@github.com>

On Tue, 16 Apr 2024 19:15:14 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
>> 
>> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
>> 
>> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
>> 
>> The changes are summarized here:
>> 
>> #### 1. Generalize how we categorize references
>> 
>> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
>> 
>> Previously the `Ref` categories were:
>> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
>> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
>> * `VarRef` - A local variable or method parameter currently in scope
>> * `ExprRef` - An object reference sitting on top of the Java execution stack
>> * `YieldRef` - The current switch expression's yield value(s)
>> * `ReturnRef` - The current method's return value(s)
>> 
>> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
>> 
>> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
>> 
>> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
>> 
>> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
>> 
>> #### 2. Track the types...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Synchronize TreeInfo.isExplicitThisReference() with PR #18088.

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16208#pullrequestreview-2006363434

From acobbs at openjdk.org  Wed Apr 17 17:38:02 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 17 Apr 2024 17:38:02 GMT
Subject: Integrated: 8317376: Minor improvements to the 'this' escape analyzer
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <OCy_Jt1nyXDmhu4LCQwGMemjEozXSCkHJU42eT0Y7EA=.c631a5cb-efec-405f-9d0d-bdd169515cc9@github.com>

On Mon, 16 Oct 2023 22:08:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

This pull request has now been integrated.

Changeset: 06462847
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/064628471b83616b4463baa78618d1b7a66d0c7c
Stats:     915 lines in 20 files changed: 552 ins; 171 del; 192 mod

8317376: Minor improvements to the 'this' escape analyzer

Reviewed-by: vromero

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

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

From schernyshev at openjdk.org  Wed Apr 17 20:18:25 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 17 Apr 2024 20:18:25 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v6]
In-Reply-To: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
Message-ID: <tDN1LVftFjXF3QCmejwORvBYZZxlyZAc3EwmaAY79rY=.440b73b5-c7e4-4d42-aacb-724e28172ae4@github.com>

> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
> 
> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
> 
> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
> 
> "If a literal IP address is supplied, only the validity of the address format is checked."
> 
> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
> 
> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
> 
> - `IPAddressUtil#parseBsdLiteralV4()` method is e...

Sergey Chernyshev 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>
  Co-authored-by: Aleksei Efimov <aleksej.efimov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18493/files
  - new: https://git.openjdk.org/jdk/pull/18493/files/d05d9d54..2449a331

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

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

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

From schernyshev at openjdk.org  Wed Apr 17 22:23:41 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 17 Apr 2024 22:23:41 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v7]
In-Reply-To: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
Message-ID: <GDHWgKbn58M_3LgVaRvX1uH0x6JpfxNO5TkLurlhJtU=.e60f45a7-61a6-4157-bc44-da9a41d3ef9d@github.com>

> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
> 
> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
> 
> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
> 
> "If a literal IP address is supplied, only the validity of the address format is checked."
> 
> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
> 
> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
> 
> - `IPAddressUtil#parseBsdLiteralV4()` method is e...

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

  addressed more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18493/files
  - new: https://git.openjdk.org/jdk/pull/18493/files/2449a331..e07dafad

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

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

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

From schernyshev at openjdk.org  Wed Apr 17 22:23:41 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 17 Apr 2024 22:23:41 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <rHV5qzf7RJC-gEZYjSaJFFIU61SPK0SUR72pDpbND28=.f8456aaa-e8f2-406c-9563-c9dd2184e317@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
 <rHV5qzf7RJC-gEZYjSaJFFIU61SPK0SUR72pDpbND28=.f8456aaa-e8f2-406c-9563-c9dd2184e317@github.com>
Message-ID: <yoAQIMch1ZTR4VpgloxKcEoU0qhOKEDsnVUOaiviUIc=.75dbb33b-f10f-4162-af86-15231b621ff9@github.com>

On Tue, 16 Apr 2024 22:17:21 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/java/net/Inet4Address.java
>>    
>>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/net/Inet4Address.java
>>    
>>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>
> src/java.base/share/classes/sun/net/util/IPAddressUtil.java line 711:
> 
>> 709:                 fieldValue = parseV4FieldBsd(radix, charBuffer, fieldNumber);
>> 710:                 if (fieldValue >= 0) {
>> 711:                     if (fieldValue < 256) {
> 
> Maybe this check can be acccompanied with a comment to clarify the following, ie if a field value is greater than `255` then it can only be the last field. If it is not the last one then `parseV4FieldBsd` enforces this limit and will return `null`.
> That would help future code maintainers :)

done

> test/jdk/java/net/InetAddress/OfLiteralTest.java line 26:
> 
>> 24: /* @test
>> 25:  * @bug 8272215 8315767
>> 26:  * @summary Test for ofLiteral API in InetAddress classes
> 
> The test summary can mention that `ofLiteralPosix` is also tested here

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1569611795
PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1569611999

From schernyshev at openjdk.org  Wed Apr 17 22:25:57 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 17 Apr 2024 22:25:57 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <b0AZF89W4Tnq2SWrQm2efZS22QsCWGGKzXn1TL3EM7g=.62ecd588-1f63-48f8-ba9c-d0a1f53a215e@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
 <ZdlJt5iRBrmnAbEu0frCc-UeZe8QybDOqI8elVPuw84=.759f6288-6311-440d-b0c1-5c4155066aa2@github.com>
 <b0AZF89W4Tnq2SWrQm2efZS22QsCWGGKzXn1TL3EM7g=.62ecd588-1f63-48f8-ba9c-d0a1f53a215e@github.com>
Message-ID: <VvnWMrdZ5jWNUWsQai_ko-UeGxmNkMgZ9ASsePEaFTY=.e8d258fe-8154-473f-a5f4-aad85f1cdacd@github.com>

On Wed, 17 Apr 2024 14:48:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Inet4Address.java line 104:
>> 
>>> 102:  * Purposes</i></a>.
>>> 103:  * <p> For methods that return a textual representation as output
>>> 104:  * value, the first form, i.e. a dotted-quad string, is used.
>> 
>> Maybe something like this?
>> 
>> Suggestion:
>> 
>>  * <p> For methods that return a textual representation as output
>>  * value, the first form, i.e. a dotted-quad string in strict decimal notation, is used.
>
> Yes, I think this makes it clear.

accepted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18493#discussion_r1569614610

From michaelm at openjdk.org  Thu Apr 18 09:59:07 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 18 Apr 2024 09:59:07 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v5]
In-Reply-To: <CCuxOXMT0M-OAtHs03k-KuK3tGD8gVrXMPm9JW9G2PM=.9686b355-7866-41a0-82e0-aa39f272c2e8@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <90LxUo-bH0DhSw15RAwIIT1FgamNG8JhlehQUyYJiOE=.344d8cbd-1eac-4432-b52d-35ccc8ea54cc@github.com>
 <Mid07HkKU5AJC0-vX6xLPPIEZBzo6A2e-Z2RFgcISlI=.d1ee714a-4676-4e77-91d8-cf30707a31bd@github.com>
 <sTzR7GWOqkKccIyNA3uL0P9DRAmAcWVDRf6kiI49JgA=.7c2d4c9d-3a29-4253-b4cf-0bfc5a75be90@github.com>
 <CCuxOXMT0M-OAtHs03k-KuK3tGD8gVrXMPm9JW9G2PM=.9686b355-7866-41a0-82e0-aa39f272c2e8@github.com>
Message-ID: <BFt-dbJK_dcc2iVdqu0EoaFpGy9S4FxPJ9HPH0kIwQc=.b1e0cf04-402b-4e93-a24e-a9934568b299@github.com>

On Wed, 17 Apr 2024 14:26:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Should we be setting any expectations by specifying what `InetAddress.getHostAddress()` will return for an `Inet4Address` constructed using this new `Inet4Address.ofPosixLiteral()` method? In its current form I believe it will continue to return a decimal representation of the IP address. My guess is that we want it to continue behaving that way?

That seems to be the case for the native function roundtrip. So, I would it expect it to be the same in Java.

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

PR Comment: https://git.openjdk.org/jdk/pull/18493#issuecomment-2063484079

From michaelm at openjdk.org  Thu Apr 18 10:26:57 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 18 Apr 2024 10:26:57 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v7]
In-Reply-To: <GDHWgKbn58M_3LgVaRvX1uH0x6JpfxNO5TkLurlhJtU=.e60f45a7-61a6-4157-bc44-da9a41d3ef9d@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <GDHWgKbn58M_3LgVaRvX1uH0x6JpfxNO5TkLurlhJtU=.e60f45a7-61a6-4157-bc44-da9a41d3ef9d@github.com>
Message-ID: <A-kq2TgYlHiHkG8D9caVogDWwQLsrxQwG629Mk0x7n8=.f30dc81b-c4a5-4891-a9ea-0ba2e028b3db@github.com>

On Wed, 17 Apr 2024 22:23:41 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> There are two distinct approaches to parsing IPv4 literal addresses. One is the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX `inet_addr` allowing octal and hexadecimal forms [2]). The goal of this PR is to provide interface to construct InetAddress objects from literal addresses in POSIX form, to applications that need to mimic the behavior of `inet_addr` used by standard network utilities such as netcat/curl/wget and the majority of web browsers. At present time, there's no way to construct `InetAddress` object from such literal addresses because the existing APIs such as `InetAddress.getByName()`, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume an address and successfully parse it as decimal, regardless of the octal prefix. Hence, the resulting object will point to a different IP address.
>> 
>> Historically `InetAddress.getByName()/.getAllByName()` were the only way to convert a literal address into an InetAddress object. `getAllByName()` API relies on POSIX `getaddrinfo` / `inet_addr` which parses IP address segments with `strtoul` (accepts octal and hexadecimal bases).
>> 
>> The fallback to `getaddrinfo` is undesirable as it may end up with network queries (blocking mode), if `inet_addr` rejects the input literal address. The Java standard explicitly says that
>> 
>> "If a literal IP address is supplied, only the validity of the address format is checked."
>> 
>> @AlekseiEfimov contributed JDK-8272215 [3] that adds new factory methods `.ofLiteral()` to `InetAddress` classes. Although the new API is not affected by the `getaddrinfo` fallback issue, it is not sufficient for an application that needs to interoperate with external tooling that follows POSIX standard. In the current state, `InetAddress#ofLiteral()` and `Inet4Address#ofLiteral()` will consume the input literal address and (regardless of the octal prefix) parse it as decimal numbers. Hence, it's not possible to reliably construct an `InetAddress` object from a literal address in POSIX form that would point to the desired host.
>> 
>> It is proposed to extend the factory methods with `Inet4Address#ofPosixLiteral()` that allows parsing literal IP(v4) addresses in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4]. The changes in the original algorithm are as follows:
>> 
>> - `IPAddressUtil#parseB...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed more review comments

The sentence at line 73 (of Inet4Address) isn't correct any more.

"These forms support parts specified in decimal format only."

Forms here refers to the number of components in the address, not the methods used to parse the address. The new method also supports the multiple "forms" of an address.

I think it might be best to have a new section in the class doc

"Parsing of literal addresses"

which lists the methods that parse as decimal only, and the new method which parses using the "loose" syntax. Then the existing snippet showing examples of parsing as decimal only can be shown. The syntax for loose parsing should remain in the method definition imo.

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

PR Review: https://git.openjdk.org/jdk/pull/18493#pullrequestreview-2008458196

From dfuchs at openjdk.org  Thu Apr 18 11:37:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 Apr 2024 11:37:57 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v7]
In-Reply-To: <A-kq2TgYlHiHkG8D9caVogDWwQLsrxQwG629Mk0x7n8=.f30dc81b-c4a5-4891-a9ea-0ba2e028b3db@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <GDHWgKbn58M_3LgVaRvX1uH0x6JpfxNO5TkLurlhJtU=.e60f45a7-61a6-4157-bc44-da9a41d3ef9d@github.com>
 <A-kq2TgYlHiHkG8D9caVogDWwQLsrxQwG629Mk0x7n8=.f30dc81b-c4a5-4891-a9ea-0ba2e028b3db@github.com>
Message-ID: <rh52HbG2JtAK7Q3v9Tp76Z7jLgife5wDPZRf2HibQJw=.68e488d7-b843-4e64-b409-b0ca54e6dc4c@github.com>

On Thu, 18 Apr 2024 10:24:30 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> which lists the methods that parse as decimal only, and the new method which parses using the "loose" syntax.

That might not be practical: the only method that supports non decimal form is the new `ofBSDLiteral`. But any other method only support decimal notation. These include URL/URI, permissions, InetSocketAdderess, InetAddress, Socket/DatagramSocket constructors, etc... Building a comprehensive list would be both unpractical and difficult.

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

PR Comment: https://git.openjdk.org/jdk/pull/18493#issuecomment-2063654700

From clanger at openjdk.org  Thu Apr 18 12:40:27 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 18 Apr 2024 12:40:27 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v2]
In-Reply-To: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
Message-ID: <zlHnQueCaQIPaQKPtSBN1wJ1VyRlCxhTTlIma3nCJO0=.85f236af-8977-4c19-82fe-fde87316b763@github.com>

> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
> 
> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
> 
> E.g. on my developer laptop runtime went down from ~100s to ~10s.
> 
> I also made additional cleanups/refactoring in the test.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Small further cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18817/files
  - new: https://git.openjdk.org/jdk/pull/18817/files/2fe83fd6..b68258da

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

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

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

From dfuchs at openjdk.org  Thu Apr 18 13:27:01 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 Apr 2024 13:27:01 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v2]
In-Reply-To: <zlHnQueCaQIPaQKPtSBN1wJ1VyRlCxhTTlIma3nCJO0=.85f236af-8977-4c19-82fe-fde87316b763@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <zlHnQueCaQIPaQKPtSBN1wJ1VyRlCxhTTlIma3nCJO0=.85f236af-8977-4c19-82fe-fde87316b763@github.com>
Message-ID: <AFAOxRZz8BjBEdg6jZWgyrqr7r78my6if74hreWYw4A=.592562fc-2cf4-4e3a-9b37-0a118c01d0c6@github.com>

On Thu, 18 Apr 2024 12:40:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
>> 
>> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
>> 
>> E.g. on my developer laptop runtime went down from ~100s to ~10s.
>> 
>> I also made additional cleanups/refactoring in the test.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small further cleanup

Hi Christoph - thanks for this fix. It looks like a very nice improvement. Please give us some time to test the changes through our CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/18817#issuecomment-2063862610

From michaelm at openjdk.org  Thu Apr 18 13:32:03 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 18 Apr 2024 13:32:03 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v7]
In-Reply-To: <rh52HbG2JtAK7Q3v9Tp76Z7jLgife5wDPZRf2HibQJw=.68e488d7-b843-4e64-b409-b0ca54e6dc4c@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <GDHWgKbn58M_3LgVaRvX1uH0x6JpfxNO5TkLurlhJtU=.e60f45a7-61a6-4157-bc44-da9a41d3ef9d@github.com>
 <A-kq2TgYlHiHkG8D9caVogDWwQLsrxQwG629Mk0x7n8=.f30dc81b-c4a5-4891-a9ea-0ba2e028b3db@github.com>
 <rh52HbG2JtAK7Q3v9Tp76Z7jLgife5wDPZRf2HibQJw=.68e488d7-b843-4e64-b409-b0ca54e6dc4c@github.com>
Message-ID: <c47N49MwcnOcZ3xJUCoI7O9ZSKcI-UHhPRWO7a0trg4=.86ecb1e5-61d7-4033-b539-142650e836f5@github.com>

On Thu, 18 Apr 2024 11:35:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > which lists the methods that parse as decimal only, and the new method which parses using the "loose" syntax.
> 
> That might not be practical: the only method that supports non decimal form is the new `ofBSDLiteral`. But any other method only support decimal notation. These include URL/URI, permissions, InetSocketAdderess, InetAddress, Socket/DatagramSocket constructors, etc... Building a comprehensive list would be both unpractical and difficult.

I think we only need to talk about the methods in InetAddress. Though it could be phrased as `ofPosixLiteral` supports decimal, hex and octal. All other parsing is decimal only.

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

PR Comment: https://git.openjdk.org/jdk/pull/18493#issuecomment-2063872720

From jpai at openjdk.org  Thu Apr 18 13:52:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Apr 2024 13:52:03 GMT
Subject: RFR: 8330572: jdk.internal.net.http.HttpConnection calls an expensive
 checkOpen() when returning a HTTP/1.1 connection to the pool
Message-ID: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>

Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8330572?

As noted in that issue, the internal method `checkOpen()` should only be called when picking a non-TLS HTTP/1.1 connection from the pool and before handing it out. That method should not be called in any other places.

The commit in this PR addresses that by removing the call to `checkOpen()` when the connection is being returned back to the pool. The `checkOpen()` call which does a socket channel read is now replaced with a `isOpen()` call which is just a state check.

Existing tests in tier2 continue to pass with this change. A test repeat of 50 of test/jdk/java/net/httpclient tests too passes without any regressions. No new test has been added given the nature of this change.

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

Commit messages:
 - 8330572: jdk.internal.net.http.HttpConnection calls an expensive checkOpen() when returning a HTTP/1.1 connection to the pool

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

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

From dfuchs at openjdk.org  Thu Apr 18 14:36:03 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 Apr 2024 14:36:03 GMT
Subject: RFR: 8330572: jdk.internal.net.http.HttpConnection calls an
 expensive checkOpen() when returning a HTTP/1.1 connection to the pool
In-Reply-To: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>
References: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>
Message-ID: <cfIfpBYXr6r_1fciyxbD6HdSGZ9ThIKhYj-nDOguonk=.767d9542-0726-49ee-9351-396b36b8824d@github.com>

On Thu, 18 Apr 2024 13:47:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8330572?
> 
> As noted in that issue, the internal method `checkOpen()` should only be called when picking a non-TLS HTTP/1.1 connection from the pool and before handing it out. That method should not be called in any other places.
> 
> The commit in this PR addresses that by removing the call to `checkOpen()` when the connection is being returned back to the pool. The `checkOpen()` call which does a socket channel read is now replaced with a `isOpen()` call which is just a state check.
> 
> Existing tests in tier2 continue to pass with this change. A test repeat of 50 of test/jdk/java/net/httpclient tests too passes without any regressions. No new test has been added given the nature of this change.

Looks good to me. Please verify that existing tests are still stable.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18840#pullrequestreview-2009088892

From dfuchs at openjdk.org  Thu Apr 18 14:39:58 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 Apr 2024 14:39:58 GMT
Subject: RFR: 8315767: InetAddress: constructing objects from BSD literal
 addresses [v7]
In-Reply-To: <c47N49MwcnOcZ3xJUCoI7O9ZSKcI-UHhPRWO7a0trg4=.86ecb1e5-61d7-4033-b539-142650e836f5@github.com>
References: <iYl2VOVVs2FZUPcgvaGwvvwTU5AGHfN8-sx_I9O_AMg=.5c90d81a-12eb-4e7a-bb85-919722289815@github.com>
 <GDHWgKbn58M_3LgVaRvX1uH0x6JpfxNO5TkLurlhJtU=.e60f45a7-61a6-4157-bc44-da9a41d3ef9d@github.com>
 <A-kq2TgYlHiHkG8D9caVogDWwQLsrxQwG629Mk0x7n8=.f30dc81b-c4a5-4891-a9ea-0ba2e028b3db@github.com>
 <rh52HbG2JtAK7Q3v9Tp76Z7jLgife5wDPZRf2HibQJw=.68e488d7-b843-4e64-b409-b0ca54e6dc4c@github.com>
 <c47N49MwcnOcZ3xJUCoI7O9ZSKcI-UHhPRWO7a0trg4=.86ecb1e5-61d7-4033-b539-142650e836f5@github.com>
Message-ID: <JTeqqS7WxdNB4uS01aMSlQzAz34xdRHRwZsweUR5GEE=.c533f645-43ae-42e3-92f5-3f448dd76aa2@github.com>

On Thu, 18 Apr 2024 13:29:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> I think we only need to talk about the methods in InetAddress. Though it could be phrased as `ofPosixLiteral` supports decimal, hex and octal. All other parsing is decimal only.

Yes. that latter formulation might be better.

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

PR Comment: https://git.openjdk.org/jdk/pull/18493#issuecomment-2064040745

From jjg at openjdk.org  Thu Apr 18 20:48:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 20:48:04 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`
Message-ID: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>

Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.

There are various categories of update:

* "Box comments" beginning with `/**`
* Misplaced doc comments before package or import statements
* Misplaced doc comments after the annotations for a declaration
* Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
* Use of `/**` for the legal header at or near the top of the file

In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

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

Commit messages:
 - JDK-8330178: Clean up non-standard use of /** comments in `java.base`

Changes: https://git.openjdk.org/jdk/pull/18846/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330178
  Stats: 134 lines in 23 files changed: 50 ins; 56 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/18846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18846/head:pull/18846

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

From mpowers at openjdk.org  Thu Apr 18 21:19:56 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 18 Apr 2024 21:19:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <dmHUQtRTvpmJO4yhZvDJFjFCxtZMXJcJb45ZQ-Lxdlw=.00c6c3b8-960f-4ddb-bb32-0848fc1bad83@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Should the copyright be updated?

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2065339389

From duke at openjdk.org  Thu Apr 18 22:00:25 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 18 Apr 2024 22:00:25 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length
Message-ID: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>

fix bug JDK-B6968351 by avoiding flush after response headers

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

Commit messages:
 - remove extraneous whitespace change
 - fix for small messages with tcp_nodelay off

Changes: https://git.openjdk.org/jdk/pull/18667/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6968351
  Stats: 104 lines in 3 files changed: 97 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18667/head:pull/18667

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

From darcy at openjdk.org  Thu Apr 18 22:50:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Apr 2024 22:50:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <CCg0siue0vsMT0R1LJ9Qgr5BN7eORlS-sqNih3qh2Tg=.8df332ee-d15a-4678-8bbd-9baf26c0e257@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2010059355

From iris at openjdk.org  Thu Apr 18 22:59:55 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 Apr 2024 22:59:55 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <0ffUuhd3mqnGetQ_dn60M7NrftiL02UD7zbITanAuJc=.b4ac0b9d-01c0-47be-a315-903e9ed6424f@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2010068091

From rengels at ix.netcom.com  Fri Apr 19 03:52:05 2024
From: rengels at ix.netcom.com (Robert Engels)
Date: Thu, 18 Apr 2024 22:52:05 -0500
Subject: HttpServer performance issue / improvement
In-Reply-To: <5106D7E3-6482-42C9-B342-B69275DEFE2D@ix.netcom.com>
References: <5106D7E3-6482-42C9-B342-B69275DEFE2D@ix.netcom.com>
Message-ID: <37DAAB7A-F8CA-466E-86BB-A0CB29EA258C@ix.netcom.com>

The OCA tag has been removed. So it?s ok to review now. 

> On Apr 8, 2024, at 9:10?AM, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> ?And thanks for the note about HttpClient - ill leave that as is then.
> 
>> On Apr 8, 2024, at 9:06?AM, Robert Engels <rengels at ix.netcom.com> wrote:
>> 
>> ?It?s fairly isolated but I haven?t checked to see how the JDK differs in jdk8 - but I?m guessing not very much so it should be a trivial port.
>> 
>>>> On Apr 8, 2024, at 9:03?AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>> 
>>> ?Hi Robert,
>>> 
>>> I am waiting for the OCA to be processed before looking
>>> at your PR.
>>> 
>>> FWIW some of the recent tests we have added for the HttpServer
>>> already use the HttpClient - so unless your test/fix does
>>> require HttpURLConnection it is fine to use HttpClient.
>>> 
>>> Were you planning to later propose to backport this change
>>> back to JDK 8?
>>> 
>>> best regards,
>>> 
>>> -- daniel
>>> 
>>>>> On 08/04/2024 14:23, Robert Engels wrote:
>>>> I?ll update my PR to remove the nodelay setting from those tests. I am going to change the PR to use UrlConnection rather than HttpClient as well.
>>> 
>>> 

From jpai at openjdk.org  Fri Apr 19 06:24:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 Apr 2024 06:24:56 GMT
Subject: RFR: 8330572: jdk.internal.net.http.HttpConnection calls an
 expensive checkOpen() when returning a HTTP/1.1 connection to the pool
In-Reply-To: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>
References: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>
Message-ID: <S-SOgywFhXWBgsWa6QFC34dOPXJhL9PIwK-wEkNak5Y=.42584d54-8e95-4e14-b621-d234a8d31189@github.com>

On Thu, 18 Apr 2024 13:47:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8330572?
> 
> As noted in that issue, the internal method `checkOpen()` should only be called when picking a non-TLS HTTP/1.1 connection from the pool and before handing it out. That method should not be called in any other places.
> 
> The commit in this PR addresses that by removing the call to `checkOpen()` when the connection is being returned back to the pool. The `checkOpen()` call which does a socket channel read is now replaced with a `isOpen()` call which is just a state check.
> 
> Existing tests in tier2 continue to pass with this change. A test repeat of 50 of test/jdk/java/net/httpclient tests too passes without any regressions. No new test has been added given the nature of this change.

Thank you Daniel for the review.

> Please verify that existing tests are still stable.

2 runs of test-repeat 50 against `test/jdk/java/net/httpclient` completed successfully and 1 run of tier2 completed without related issues. I'll go ahead with the integration shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/18840#issuecomment-2065840728

From djelinski at openjdk.org  Fri Apr 19 06:28:58 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 06:28:58 GMT
Subject: RFR: 8330572: jdk.internal.net.http.HttpConnection calls an
 expensive checkOpen() when returning a HTTP/1.1 connection to the pool
In-Reply-To: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>
References: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>
Message-ID: <7IPlBA_Akr8OApl8t_Cj_fEvKEY1Ex_XKCzgUF4hXhU=.9164fecf-23ee-4246-b5ae-8afb657d3d58@github.com>

On Thu, 18 Apr 2024 13:47:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8330572?
> 
> As noted in that issue, the internal method `checkOpen()` should only be called when picking a non-TLS HTTP/1.1 connection from the pool and before handing it out. That method should not be called in any other places.
> 
> The commit in this PR addresses that by removing the call to `checkOpen()` when the connection is being returned back to the pool. The `checkOpen()` call which does a socket channel read is now replaced with a `isOpen()` call which is just a state check.
> 
> Existing tests in tier2 continue to pass with this change. A test repeat of 50 of test/jdk/java/net/httpclient tests too passes without any regressions. No new test has been added given the nature of this change.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18840#pullrequestreview-2010620503

From jpai at openjdk.org  Fri Apr 19 06:43:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 Apr 2024 06:43:00 GMT
Subject: RFR: 8330572: jdk.internal.net.http.HttpConnection calls an
 expensive checkOpen() when returning a HTTP/1.1 connection to the pool
In-Reply-To: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>
References: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>
Message-ID: <wQxGXK5ONFFt5vAX_GA0H4DrUMUgMhs2nuXCEJm7PMs=.8cce76c0-ad55-4679-8f7d-79e9224b396a@github.com>

On Thu, 18 Apr 2024 13:47:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8330572?
> 
> As noted in that issue, the internal method `checkOpen()` should only be called when picking a non-TLS HTTP/1.1 connection from the pool and before handing it out. That method should not be called in any other places.
> 
> The commit in this PR addresses that by removing the call to `checkOpen()` when the connection is being returned back to the pool. The `checkOpen()` call which does a socket channel read is now replaced with a `isOpen()` call which is just a state check.
> 
> Existing tests in tier2 continue to pass with this change. A test repeat of 50 of test/jdk/java/net/httpclient tests too passes without any regressions. No new test has been added given the nature of this change.

Thank you Daniel J for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18840#issuecomment-2065860608

From djelinski at openjdk.org  Fri Apr 19 08:30:59 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 08:30:59 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v2]
In-Reply-To: <zlHnQueCaQIPaQKPtSBN1wJ1VyRlCxhTTlIma3nCJO0=.85f236af-8977-4c19-82fe-fde87316b763@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <zlHnQueCaQIPaQKPtSBN1wJ1VyRlCxhTTlIma3nCJO0=.85f236af-8977-4c19-82fe-fde87316b763@github.com>
Message-ID: <mF6_qXWNmtsTUHs_YN0xOotV7DUAcKOt66-K2KJVDnE=.450d7e9a-89f5-404d-a578-a4144ed5ebe6@github.com>

On Thu, 18 Apr 2024 12:40:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
>> 
>> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
>> 
>> E.g. on my developer laptop runtime went down from ~100s to ~10s.
>> 
>> I also made additional cleanups/refactoring in the test.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small further cleanup

With 800 changed lines in a now-976 file, it's practically a new test :)

Would it make sense to move the system properties to the jtreg run lines? Like:

@run main/othervm KeepAliveTest -Dhttp.keepAlive.time.server=100 c1

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

PR Comment: https://git.openjdk.org/jdk/pull/18817#issuecomment-2066088832

From dfuchs at openjdk.org  Fri Apr 19 09:13:00 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 09:13:00 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <A7SDoPKvP6n9J9SfRfEfSJb6Aml92bVsEjBhs4PU8ZE=.f4978e2c-6dc8-48e4-a6d7-43a2ae74e2d8@github.com>

On Sat, 6 Apr 2024 23:35:48 GMT, robert engels <duke at openjdk.org> wrote:

> fix bug JDK-B6968351 by avoiding flush after response headers

Hi Robert, thanks for working on this issue.

src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 210:

> 208:         this.rcode = rCode;
> 209:         String statusLine = "HTTP/1.1 "+rCode+Code.msg(rCode)+"\r\n";
> 210:         ByteArrayOutputStream tmpout = new ByteArrayOutputStream();

Wouldn't it be better to continue using a BufferedOutputStream here? That would put a limit on how much data would be buffered when writing the headers, in case of long response headers.

test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 70:

> 68:         long start = System.currentTimeMillis();
> 69:         for(int i=0;i<1000;i++) {
> 70:             var response = client.send(HttpRequest.newBuilder(new URI("http://localhost:"+server.getAddress().getPort()+"/test")).build(), HttpResponse.BodyHandlers.ofString());

It would be better to use the URI builder here and avoid "localhost:port" form to avoid dependencies on local host machines configuration.


var uri = URIBuilder.newBuilder().scheme("http").loopback().port(...).path(...).build();

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18667#pullrequestreview-2010916948
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572066184
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572072507

From clanger at openjdk.org  Fri Apr 19 09:16:57 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 19 Apr 2024 09:16:57 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v2]
In-Reply-To: <mF6_qXWNmtsTUHs_YN0xOotV7DUAcKOt66-K2KJVDnE=.450d7e9a-89f5-404d-a578-a4144ed5ebe6@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <zlHnQueCaQIPaQKPtSBN1wJ1VyRlCxhTTlIma3nCJO0=.85f236af-8977-4c19-82fe-fde87316b763@github.com>
 <mF6_qXWNmtsTUHs_YN0xOotV7DUAcKOt66-K2KJVDnE=.450d7e9a-89f5-404d-a578-a4144ed5ebe6@github.com>
Message-ID: <5AL9_4CU0KDkyf4JoVYvtKvHoyeNDkxiwiaVFJ3WKs0=.592ee173-9a51-41d8-811f-728280fcd8f7@github.com>

On Fri, 19 Apr 2024 08:28:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> With 800 changed lines in a now-976 file, it's practically a new test :)

Yes, in fact it is. ? I refrained from touching the comment table that describes all the possible combinations which make 50% of the file...

> Would it make sense to move the system properties to the jtreg run lines? Like:
> 
> ```
> @run main/othervm KeepAliveTest -Dhttp.keepAlive.time.server=100 c1
> ```

I thought about that, too. I can go that route if you like - the diff will then be even larger and I should also modify the comment table...

Shall I?

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

PR Comment: https://git.openjdk.org/jdk/pull/18817#issuecomment-2066164691

From djelinski at openjdk.org  Fri Apr 19 09:57:10 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 09:57:10 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>

On Sat, 6 Apr 2024 23:35:48 GMT, robert engels <duke at openjdk.org> wrote:

> fix bug JDK-B6968351 by avoiding flush after response headers

This is not as complex as I expected it to be. Which is a good thing!

Some tests are failing with this change. See:

test/jdk/sun/net/www/http/KeepAliveCache/B8293562.java
test/jdk/java/net/Authenticator/B4769350.java

These tests don't close the exchange or the output stream after sending the response, and the headers are never flushed. Users might have similar code, so I think a release note might be needed.

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 39:

> 37: import javax.net.ssl.SSLContext;
> 38: import javax.net.ssl.SSLEngine;
> 39: import java.io.*;

Please do not use wildcard imports in this file.

test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 30:

> 28:  * @library /test/lib
> 29:  * @run main B6968351
> 30:  * @run main/othervm -Dsun.net.httpserver.nodelay=false -Djdk.httpclient.HttpClient.log=all -Djava.net.preferIPv6Addresses=true -Djavax.net.debug=all B6968351

Do you need all these system properties here?

test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 45:

> 43: import java.util.logging.*;
> 44: 
> 45: public class B6968351 {

You could use a more revealing name here; the B<bug numer> aren't very useful

test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 75:

> 73:         long time = System.currentTimeMillis()-start;
> 74:         System.out.println("time "+time);
> 75:         if(time>5000) throw new IllegalStateException("took too long");

Use jtreg timeout instead, like:

@run main/timeout=5 B6968351

(the timeout value is in seconds, but it's scaled x4 by default)

this will interrupt the test if/when the timeout is hit, and will also enable scaling the timeout on slower machines

test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 90:

> 88:             is.close();
> 89:             rmap.add("content-type","text/plain");
> 90:             t.sendResponseHeaders(200,5);

if I read the code correctly, there might be a similar delay when sending the last chunk of a chunked response. Would you like to fix it here as well? If not, we can file another ticket for it.

In order to send a chunked response, change the second parameter to `0` here.

test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 91:

> 89:             rmap.add("content-type","text/plain");
> 90:             t.sendResponseHeaders(200,5);
> 91:             t.getResponseBody().write("hello".getBytes());

Suggestion:

            t.getResponseBody().write("hello".getBytes(StandardCharsets.ISO_8859_1));

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

PR Review: https://git.openjdk.org/jdk/pull/18667#pullrequestreview-2010884813
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572046765
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572048695
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572121432
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572052902
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572123627
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572059622

From jpai at openjdk.org  Fri Apr 19 10:11:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 Apr 2024 10:11:03 GMT
Subject: Integrated: 8330572: jdk.internal.net.http.HttpConnection calls an
 expensive checkOpen() when returning a HTTP/1.1 connection to the pool
In-Reply-To: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>
References: <0nVizPFwMmZ58clWheu6cz8x2fFT2E4lNFFstpZQels=.4da8d533-9cd1-4661-ab11-6ea34fad517b@github.com>
Message-ID: <dY-88xJVz-0dw0hmKhR99LWhAoBAR2WHREsyB5PYeFA=.64e32368-9932-4e89-838a-aac0c972f700@github.com>

On Thu, 18 Apr 2024 13:47:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8330572?
> 
> As noted in that issue, the internal method `checkOpen()` should only be called when picking a non-TLS HTTP/1.1 connection from the pool and before handing it out. That method should not be called in any other places.
> 
> The commit in this PR addresses that by removing the call to `checkOpen()` when the connection is being returned back to the pool. The `checkOpen()` call which does a socket channel read is now replaced with a `isOpen()` call which is just a state check.
> 
> Existing tests in tier2 continue to pass with this change. A test repeat of 50 of test/jdk/java/net/httpclient tests too passes without any regressions. No new test has been added given the nature of this change.

This pull request has now been integrated.

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

8330572: jdk.internal.net.http.HttpConnection calls an expensive checkOpen() when returning a HTTP/1.1 connection to the pool

Reviewed-by: dfuchs, djelinski

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

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

From djelinski at openjdk.org  Fri Apr 19 10:23:59 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 10:23:59 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v2]
In-Reply-To: <zlHnQueCaQIPaQKPtSBN1wJ1VyRlCxhTTlIma3nCJO0=.85f236af-8977-4c19-82fe-fde87316b763@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <zlHnQueCaQIPaQKPtSBN1wJ1VyRlCxhTTlIma3nCJO0=.85f236af-8977-4c19-82fe-fde87316b763@github.com>
Message-ID: <jOL2j7SwSC_UYA4qkC9GfJYgtc5dgeYs_KdxTE1bVMk=.1f4e7773-1658-404d-b777-5ba2bf603196@github.com>

On Thu, 18 Apr 2024 12:40:27 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
>> 
>> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
>> 
>> E.g. on my developer laptop runtime went down from ~100s to ~10s.
>> 
>> I also made additional cleanups/refactoring in the test.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small further cleanup

If that makes the end result smaller / easier to read, go for it!

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

PR Comment: https://git.openjdk.org/jdk/pull/18817#issuecomment-2066274751

From dfuchs at openjdk.org  Fri Apr 19 10:39:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 10:39:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length
In-Reply-To: <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
Message-ID: <PaGidsnHH7uNaHhPUtZJHDZsNRxcqgL1F1rNKfJrJc4=.feef094d-0926-49ee-9d6a-0cbb34bd6795@github.com>

On Fri, 19 Apr 2024 08:53:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 75:
> 
>> 73:         long time = System.currentTimeMillis()-start;
>> 74:         System.out.println("time "+time);
>> 75:         if(time>5000) throw new IllegalStateException("took too long");
> 
> Use jtreg timeout instead, like:
> 
> @run main/timeout=5 B6968351
> 
> (the timeout value is in seconds, but it's scaled x4 by default)
> 
> this will interrupt the test if/when the timeout is hit, and will also enable scaling the timeout on slower machines

Another possibility is to use Utils.adjustTimeout to take care of slow machines.

> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 91:
> 
>> 89:             rmap.add("content-type","text/plain");
>> 90:             t.sendResponseHeaders(200,5);
>> 91:             t.getResponseBody().write("hello".getBytes());
> 
> Suggestion:
> 
>             t.getResponseBody().write("hello".getBytes(StandardCharsets.ISO_8859_1));

well if you do that then you'd have to do 


t.sendResponseHeaders(200, "hello".getBytes(StandardCharsets.ISO_8859_1).length);


as well.... Or you could assume  that "hello" will always be encoded the same - and with 5 bytes,  whatever the charset...
There are quite a few tests that already make that assumption.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572148877
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572177151

From dfuchs at openjdk.org  Fri Apr 19 10:51:56 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 10:51:56 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length
In-Reply-To: <A7SDoPKvP6n9J9SfRfEfSJb6Aml92bVsEjBhs4PU8ZE=.f4978e2c-6dc8-48e4-a6d7-43a2ae74e2d8@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <A7SDoPKvP6n9J9SfRfEfSJb6Aml92bVsEjBhs4PU8ZE=.f4978e2c-6dc8-48e4-a6d7-43a2ae74e2d8@github.com>
Message-ID: <sBH41mn1_iim4nn959Imnm5i1SAO4dfTFvmbhWwnwZ8=.ef23ee26-1ecb-4d76-9776-5b439c7d2ce4@github.com>

On Fri, 19 Apr 2024 09:03:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 210:
> 
>> 208:         this.rcode = rCode;
>> 209:         String statusLine = "HTTP/1.1 "+rCode+Code.msg(rCode)+"\r\n";
>> 210:         ByteArrayOutputStream tmpout = new ByteArrayOutputStream();
> 
> Wouldn't it be better to continue using a BufferedOutputStream here? That would put a limit on how much data would be buffered when writing the headers, in case of long response headers.

Forget I asked this. @djelinski pointed out this is necessary to avoid having to flush at line 281. But I see that at line 686 you replaced rawout with a BufferedOutputStream - so do we still need the temporary ByteArrayOutputStream? Can't we just write directly to `ros` (possibly assert ros instanceof BufferedOutputStream if we want to make sure...)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572188500

From aivanov at openjdk.org  Fri Apr 19 10:55:58 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 10:55:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

src/java.base/macosx/classes/apple/security/AppleProvider.java line 33:

> 31: /*
> 32:  * The Apple Security Provider.
> 33:  */

Does it make sense to incorporate this comment into the following javadoc comment?


/**
 * Defines the (an) Apple security provider.
 * ...
 */
@SuppressWarnings("serial") // JDK implementation class

src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 37:

> 35: import static sun.security.util.SecurityProviderConstants.*;
> 36: 
> 37: /*

Should this be included in the main javadoc comment? The `@author` tags belong in the javadoc comment.

The javadoc itself is likely unreadable, when processed the entire comment becomes one very long paragraph.

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

> 36: 
> 37: /**
> 38:  * Open an file input stream given a URL.

Suggestion:

 * Open a file input stream given a URL.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572192780
PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572184441
PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572189001

From aivanov at openjdk.org  Fri Apr 19 11:04:56 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 11:04:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <-ZdPijmlx_H98EC5meigkk-QBEQawMNWEQi-Y-dyHgo=.469f84c6-9897-49c3-ba55-872d13939555@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

It is somewhat off-topic. Yet I noticed javadoc comments in some files are followed a blank line, and others aren't. Out of my curiosity, is there a convention about the blank line between the javadoc comment and the class or interface declaration? Should there be one?


/**
 * This is a class.
 */
public class A {}


or


/**
 * This is a class.
 */

public class A {}


Which is the most common? Which is preferred?

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2066337900

From dfuchs at openjdk.org  Fri Apr 19 11:29:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 11:29:57 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <c4-wxoGocaNumdyy8fUX4fVZBsSZxtJcKNmWXGbswiU=.d7e14e40-5057-473b-87af-fae5864be982@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Changes to networking code looks good. I didn't spot any issue with the rest but I'm usually not a reviewer there.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2011186056

From prappo at openjdk.org  Fri Apr 19 11:35:58 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 19 Apr 2024 11:35:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

This comment is not a review. I simply use the opportunity provided by this PR to suggest that we stop making new `/** ... */` and separately fix old jtreg comments like this:

    /**
     * @test TestSmallHeap
     * @bug 8067438 8152239
     * @summary Verify that starting the VM with a small heap works
     * @library /test/lib
     * @modules java.base/jdk.internal.misc
     * @build jdk.test.whitebox.WhiteBox
     * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
     * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI     gc.TestSmallHeap
     */

I know that those comments only appear in tests, and that tests are never documented. Still, it is confusing to see such comments and IDEs might frown upon them too. Generally, it is a good rule of thumb that `/** ... */` should be reserved only for javadoc.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2066383735

From djelinski at openjdk.org  Fri Apr 19 12:39:59 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 12:39:59 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length
In-Reply-To: <sBH41mn1_iim4nn959Imnm5i1SAO4dfTFvmbhWwnwZ8=.ef23ee26-1ecb-4d76-9776-5b439c7d2ce4@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <A7SDoPKvP6n9J9SfRfEfSJb6Aml92bVsEjBhs4PU8ZE=.f4978e2c-6dc8-48e4-a6d7-43a2ae74e2d8@github.com>
 <sBH41mn1_iim4nn959Imnm5i1SAO4dfTFvmbhWwnwZ8=.ef23ee26-1ecb-4d76-9776-5b439c7d2ce4@github.com>
Message-ID: <RzFkR1Bzdiz3UaGC5WIqzcDV8criucO-K4bXZ8USHVI=.2cec387d-6573-4e69-bc47-0570318c26fc@github.com>

On Fri, 19 Apr 2024 10:48:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 210:
>> 
>>> 208:         this.rcode = rCode;
>>> 209:         String statusLine = "HTTP/1.1 "+rCode+Code.msg(rCode)+"\r\n";
>>> 210:         ByteArrayOutputStream tmpout = new ByteArrayOutputStream();
>> 
>> Wouldn't it be better to continue using a BufferedOutputStream here? That would put a limit on how much data would be buffered when writing the headers, in case of long response headers.
>
> Forget I asked this. @djelinski pointed out this is necessary to avoid having to flush at line 281. But I see that at line 686 you replaced rawout with a BufferedOutputStream - so do we still need the temporary ByteArrayOutputStream? Can't we just write directly to `ros` (possibly assert ros instanceof BufferedOutputStream if we want to make sure...)

Before doing that, you might want to check the HTTPS case. As far as I can tell, we don't do any buffering when SSL is in use.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572303202

From duke at openjdk.org  Fri Apr 19 14:44:00 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 14:44:00 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length
In-Reply-To: <RzFkR1Bzdiz3UaGC5WIqzcDV8criucO-K4bXZ8USHVI=.2cec387d-6573-4e69-bc47-0570318c26fc@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <A7SDoPKvP6n9J9SfRfEfSJb6Aml92bVsEjBhs4PU8ZE=.f4978e2c-6dc8-48e4-a6d7-43a2ae74e2d8@github.com>
 <sBH41mn1_iim4nn959Imnm5i1SAO4dfTFvmbhWwnwZ8=.ef23ee26-1ecb-4d76-9776-5b439c7d2ce4@github.com>
 <RzFkR1Bzdiz3UaGC5WIqzcDV8criucO-K4bXZ8USHVI=.2cec387d-6573-4e69-bc47-0570318c26fc@github.com>
Message-ID: <gCe8sRIObzZNEtrzKsYAlngsHjkIPZDpk5YdMXRkeKs=.1bb2d440-de53-4e38-abbf-e5325af6a033@github.com>

On Fri, 19 Apr 2024 12:37:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Forget I asked this. @djelinski pointed out this is necessary to avoid having to flush at line 281. But I see that at line 686 you replaced rawout with a BufferedOutputStream - so do we still need the temporary ByteArrayOutputStream? Can't we just write directly to `ros` (possibly assert ros instanceof BufferedOutputStream if we want to make sure...)
>
> Before doing that, you might want to check the HTTPS case. As far as I can tell, we don't do any buffering when SSL is in use.

I think it was safer for future enhancements the way it was done. The other advantage of using a BAOS over the BOS is that it has better support for underlying hardware that has large frames (e.g. > 64k) to limit the number of OS writes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572476412

From duke at openjdk.org  Fri Apr 19 14:44:01 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 14:44:01 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length
In-Reply-To: <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
Message-ID: <dfpuL2oJUUxJXDXFXlNZnQXmIM4dGeKeSu5J5xX9RPs=.6d09fc05-9551-4eb9-927d-7947eb28d16c@github.com>

On Fri, 19 Apr 2024 09:48:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 45:
> 
>> 43: import java.util.logging.*;
>> 44: 
>> 45: public class B6968351 {
> 
> You could use a more revealing name here; the B*bug numer* aren't very useful

This was done to match the other tests with similar naming in this directory, but I am not against changing it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572478553

From duke at openjdk.org  Fri Apr 19 15:17:17 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 15:17:17 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  update based on PR review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/3e4669c3..8aa89b0d

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

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

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

From duke at openjdk.org  Fri Apr 19 15:17:18 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 15:17:18 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <A7SDoPKvP6n9J9SfRfEfSJb6Aml92bVsEjBhs4PU8ZE=.f4978e2c-6dc8-48e4-a6d7-43a2ae74e2d8@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <A7SDoPKvP6n9J9SfRfEfSJb6Aml92bVsEjBhs4PU8ZE=.f4978e2c-6dc8-48e4-a6d7-43a2ae74e2d8@github.com>
Message-ID: <GJPh_WMQJcArtKsyz_PDdiPAuupMcFyNd8QZg_WUOmA=.4197edf1-ed2c-4f20-bd04-bd03eaa50d3d@github.com>

On Fri, 19 Apr 2024 09:08:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update based on PR review
>
> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 70:
> 
>> 68:         long start = System.currentTimeMillis();
>> 69:         for(int i=0;i<1000;i++) {
>> 70:             var response = client.send(HttpRequest.newBuilder(new URI("http://localhost:"+server.getAddress().getPort()+"/test")).build(), HttpResponse.BodyHandlers.ofString());
> 
> It would be better to use the URI builder here and avoid "localhost:port" form to avoid dependencies on local host machines configuration.
> 
> 
> var uri = URIBuilder.newBuilder().scheme("http").loopback().port(...).path(...).build();

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572526178

From dfuchs at openjdk.org  Fri Apr 19 15:25:58 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 15:25:58 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <gCe8sRIObzZNEtrzKsYAlngsHjkIPZDpk5YdMXRkeKs=.1bb2d440-de53-4e38-abbf-e5325af6a033@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <A7SDoPKvP6n9J9SfRfEfSJb6Aml92bVsEjBhs4PU8ZE=.f4978e2c-6dc8-48e4-a6d7-43a2ae74e2d8@github.com>
 <sBH41mn1_iim4nn959Imnm5i1SAO4dfTFvmbhWwnwZ8=.ef23ee26-1ecb-4d76-9776-5b439c7d2ce4@github.com>
 <RzFkR1Bzdiz3UaGC5WIqzcDV8criucO-K4bXZ8USHVI=.2cec387d-6573-4e69-bc47-0570318c26fc@github.com>
 <gCe8sRIObzZNEtrzKsYAlngsHjkIPZDpk5YdMXRkeKs=.1bb2d440-de53-4e38-abbf-e5325af6a033@github.com>
Message-ID: <pOjeMVZvLpuiS8DhgUoJZ5I_Cfrc63L3UqH4pY-etQA=.622c1505-42f8-4cb0-86a2-3e253378a764@github.com>

On Fri, 19 Apr 2024 14:37:27 GMT, robert engels <duke at openjdk.org> wrote:

>> Before doing that, you might want to check the HTTPS case. As far as I can tell, we don't do any buffering when SSL is in use.
>
> I think it was safer for future enhancements the way it was done. The other advantage of using a BAOS over the BOS is that it has better support for underlying hardware that has large frames (e.g. > 64k) to limit the number of OS writes.

OK - I was just concerned about the additional buffering this implies. Previously we would only buffer as much as the size of the internal BufferedOutputStream buffer. Now we're buffering the whole set of headers until the whole set has been encoded.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572538401

From dfuchs at openjdk.org  Fri Apr 19 15:28:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 15:28:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <dfpuL2oJUUxJXDXFXlNZnQXmIM4dGeKeSu5J5xX9RPs=.6d09fc05-9551-4eb9-927d-7947eb28d16c@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
 <dfpuL2oJUUxJXDXFXlNZnQXmIM4dGeKeSu5J5xX9RPs=.6d09fc05-9551-4eb9-927d-7947eb28d16c@github.com>
Message-ID: <IRAhGi3bu2v7xZvP8Pf7odeE96C4FKDJbx23nnDbh78=.ac74ab33-6cd1-496f-9654-f1921644e573@github.com>

On Fri, 19 Apr 2024 14:39:08 GMT, robert engels <duke at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 45:
>> 
>>> 43: import java.util.logging.*;
>>> 44: 
>>> 45: public class B6968351 {
>> 
>> You could use a more revealing name here; the B*bug numer* aren't very useful
>
> This was done to match the other tests with similar naming in this directory, but I am not against changing it.

I agree with Daniel here - with new tests we try to use a more descriptive name. I hate to see JBS issues titled `foo/bar/BNNNNNN.java failed` - and then I have no clue of what that test might be doing :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572543675

From djelinski at openjdk.org  Fri Apr 19 15:45:00 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 15:45:00 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
Message-ID: <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>

On Fri, 19 Apr 2024 15:17:17 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update based on PR review

test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 30:

> 28:  * @library /test/lib
> 29:  * @run main/timeout=5 B6968351
> 30:  * @run main/othervm -Dsun.net.httpserver.nodelay=false B6968351

Suggestion:

 * @run main/othervm/timeout=5 -Dsun.net.httpserver.nodelay=false B6968351

you need the timeout on every `run` line.

The test will be run as many times as there are `run` lines; I'm assuming you actually want to run it twice here, correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572568118

From duke at openjdk.org  Fri Apr 19 15:44:57 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 15:44:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
Message-ID: <P-6yyBq4wSbKj0VxpgR-JfHJ2lSkmh2LzqK-eExmBAc=.499a1100-6d85-4a12-a4a1-619cb0c14a19@github.com>

On Fri, 19 Apr 2024 09:54:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This is not as complex as I expected it to be. Which is a good thing!
> 
> Some tests are failing with this change. See:
> 
> ```
> test/jdk/sun/net/www/http/KeepAliveCache/B8293562.java
> test/jdk/java/net/Authenticator/B4769350.java
> ```
> 
> These tests don't close the exchange or the output stream after sending the response, and the headers are never flushed. Users might have similar code, so I think a release note might be needed.

I think this is a trivial fix. We should be able to either:

1) Flush the FixedLengthOutputStream when the bytes remaining is 0.
2) Always flush the output stream after an exchange completes. This won't affect performance if it has already been flushed()/closed() previously.

I think 1 is the better option - because you can't really use a chunked output stream without flushing or closing the stream - as the client would hang.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2066834030

From duke at openjdk.org  Fri Apr 19 15:50:00 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 15:50:00 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
 <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>
Message-ID: <gFGg0DHCs2gzTLQ2PYML9h9VXieq9mVf4UlUl6gh4_c=.d9dc0cf7-119c-4b19-ae74-3149407bac86@github.com>

On Fri, 19 Apr 2024 15:42:15 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update based on PR review
>
> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 30:
> 
>> 28:  * @library /test/lib
>> 29:  * @run main/timeout=5 B6968351
>> 30:  * @run main/othervm -Dsun.net.httpserver.nodelay=false B6968351
> 
> Suggestion:
> 
>  * @run main/othervm/timeout=5 -Dsun.net.httpserver.nodelay=false B6968351
> 
> you need the timeout on every `run` line.
> 
> The test will be run as many times as there are `run` lines; I'm assuming you actually want to run it twice here, correct?

No I didn't. TBH, this is my first usage of jtreg. I was duplicating other tests somewhat blindly. I will fix.

> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 90:
> 
>> 88:             is.close();
>> 89:             rmap.add("content-type","text/plain");
>> 90:             t.sendResponseHeaders(200,5);
> 
> if I read the code correctly, there might be a similar delay when sending the last chunk of a chunked response. Would you like to fix it here as well? If not, we can file another ticket for it.
> 
> In order to send a chunked response, change the second parameter to `0` here.

If you send a chunked response you must close the exchange, or close the output stream, or there is no way to determine the data is done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572573150
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572575348

From duke at openjdk.org  Fri Apr 19 15:50:01 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 15:50:01 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <IRAhGi3bu2v7xZvP8Pf7odeE96C4FKDJbx23nnDbh78=.ac74ab33-6cd1-496f-9654-f1921644e573@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
 <dfpuL2oJUUxJXDXFXlNZnQXmIM4dGeKeSu5J5xX9RPs=.6d09fc05-9551-4eb9-927d-7947eb28d16c@github.com>
 <IRAhGi3bu2v7xZvP8Pf7odeE96C4FKDJbx23nnDbh78=.ac74ab33-6cd1-496f-9654-f1921644e573@github.com>
Message-ID: <IfAXu4KAjtpN5N44Nlxh_My6u18LcRIR__6ifoq1Pn4=.3b1db370-b88c-4057-bbd4-04a00dbd169c@github.com>

On Fri, 19 Apr 2024 15:26:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This was done to match the other tests with similar naming in this directory, but I am not against changing it.
>
> I agree with Daniel here - with new tests we try to use a more descriptive name. I hate to see JBS issues titled `foo/bar/BNNNNNN.java failed` - and then I have no clue of what that test might be doing :-)

I will change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572573578

From djelinski at openjdk.org  Fri Apr 19 16:06:06 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 16:06:06 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <gFGg0DHCs2gzTLQ2PYML9h9VXieq9mVf4UlUl6gh4_c=.d9dc0cf7-119c-4b19-ae74-3149407bac86@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
 <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>
 <gFGg0DHCs2gzTLQ2PYML9h9VXieq9mVf4UlUl6gh4_c=.d9dc0cf7-119c-4b19-ae74-3149407bac86@github.com>
Message-ID: <1X3NajBwoFmXfDGwhDYVGOogHq5dNWhPgy1NJoDpv8k=.e3006bcd-a583-42a8-b744-dcc600723a95@github.com>

On Fri, 19 Apr 2024 15:47:15 GMT, robert engels <duke at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 90:
>> 
>>> 88:             is.close();
>>> 89:             rmap.add("content-type","text/plain");
>>> 90:             t.sendResponseHeaders(200,5);
>> 
>> if I read the code correctly, there might be a similar delay when sending the last chunk of a chunked response. Would you like to fix it here as well? If not, we can file another ticket for it.
>> 
>> In order to send a chunked response, change the second parameter to `0` here.
>
> If you send a chunked response you must close the exchange, or close the output stream, or there is no way to determine the data is done.

The problem with closing a chunked stream is that it flushes both before and after the final chunk. I assume it may also cause delays.

The only case when you don't need to close the exchange or the output stream is when your response contains no content.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572602425

From djelinski at openjdk.org  Fri Apr 19 16:19:58 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 16:19:58 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <P-6yyBq4wSbKj0VxpgR-JfHJ2lSkmh2LzqK-eExmBAc=.499a1100-6d85-4a12-a4a1-619cb0c14a19@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
 <P-6yyBq4wSbKj0VxpgR-JfHJ2lSkmh2LzqK-eExmBAc=.499a1100-6d85-4a12-a4a1-619cb0c14a19@github.com>
Message-ID: <Jfe8mplNbg5SKkvt-llmY9ZZnqx8QZQwKp3vR-MmPUw=.320e029d-5eff-40f5-b624-65f7babbc19a@github.com>

On Fri, 19 Apr 2024 15:41:54 GMT, robert engels <duke at openjdk.org> wrote:

> I think this is a trivial fix. We should be able to either:
> 
> 1. Flush the FixedLengthOutputStream when the bytes remaining is 0.

This is reasonable, and should fix `B8293562`, but it won't fix `B4769350`, which creates a chunked response, and then leaks it. See the `proxyReply` method in that file.

> 2. Always flush the output stream after an exchange completes. This won't affect performance if it has already been flushed()/closed() previously.

The exchange does not automatically complete when you exit the `handle` method; you need to explicitly complete it, either by calling close or by closing the output stream. Either of these actions will flush the output stream.

This behavior enables users to asynchronously handle the exchange outside of the `handle` method. I don't know if anyone actually uses that functionality, but it's been here forever, and I don't think we want to change it now.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2066890570

From michaelm at openjdk.org  Fri Apr 19 16:19:58 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 19 Apr 2024 16:19:58 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <P-6yyBq4wSbKj0VxpgR-JfHJ2lSkmh2LzqK-eExmBAc=.499a1100-6d85-4a12-a4a1-619cb0c14a19@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
 <P-6yyBq4wSbKj0VxpgR-JfHJ2lSkmh2LzqK-eExmBAc=.499a1100-6d85-4a12-a4a1-619cb0c14a19@github.com>
Message-ID: <8gqXVl98p1rLyrFgX4QngBGnXytfSfRuUhExTTNQ7qM=.1ab9d4ea-2753-42bd-8ae1-35638eceafe3@github.com>

On Fri, 19 Apr 2024 15:41:54 GMT, robert engels <duke at openjdk.org> wrote:

> This is not as complex as I expected it to be. Which is a good thing!
> 
> Some tests are failing with this change. See:
> 
> ```
> test/jdk/sun/net/www/http/KeepAliveCache/B8293562.java
> test/jdk/java/net/Authenticator/B4769350.java
> ```
> 
> These tests don't close the exchange or the output stream after sending the response, and the headers are never flushed. Users might have similar code, so I think a release note might be needed.

This is a concern. Release note needed at least or I wonder if the new behavior should be enabled through a configuration switch. Probably not worth going to that extreme, but we need to consider the compatibility impact carefully.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2066892828

From duke at openjdk.org  Fri Apr 19 16:41:57 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 16:41:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <8gqXVl98p1rLyrFgX4QngBGnXytfSfRuUhExTTNQ7qM=.1ab9d4ea-2753-42bd-8ae1-35638eceafe3@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
 <P-6yyBq4wSbKj0VxpgR-JfHJ2lSkmh2LzqK-eExmBAc=.499a1100-6d85-4a12-a4a1-619cb0c14a19@github.com>
 <8gqXVl98p1rLyrFgX4QngBGnXytfSfRuUhExTTNQ7qM=.1ab9d4ea-2753-42bd-8ae1-35638eceafe3@github.com>
Message-ID: <paJvo4c-rcsVELGbeu7FOBjyhYAj_xJnp7KwZ28OOgE=.30072aae-d189-4406-8211-a4634cb97c7c@github.com>

On Fri, 19 Apr 2024 16:17:35 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> > This is not as complex as I expected it to be. Which is a good thing!
> > Some tests are failing with this change. See:
> > ```
> > test/jdk/sun/net/www/http/KeepAliveCache/B8293562.java
> > test/jdk/java/net/Authenticator/B4769350.java
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > These tests don't close the exchange or the output stream after sending the response, and the headers are never flushed. Users might have similar code, so I think a release note might be needed.
> 
> This is a concern. Release note needed at least or I wonder if the new behavior should be enabled through a configuration switch. Probably not worth going to that extreme, but we need to consider the compatibility impact carefully.

We won't need a release note. I figured out how to fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2066923739

From duke at openjdk.org  Fri Apr 19 17:09:57 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 17:09:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <1X3NajBwoFmXfDGwhDYVGOogHq5dNWhPgy1NJoDpv8k=.e3006bcd-a583-42a8-b744-dcc600723a95@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
 <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>
 <gFGg0DHCs2gzTLQ2PYML9h9VXieq9mVf4UlUl6gh4_c=.d9dc0cf7-119c-4b19-ae74-3149407bac86@github.com>
 <1X3NajBwoFmXfDGwhDYVGOogHq5dNWhPgy1NJoDpv8k=.e3006bcd-a583-42a8-b744-dcc600723a95@github.com>
Message-ID: <mRV-UCBuKZcQHHQIaXSUnZL16HXFCFhs3J3PqHeXnAc=.cf993f12-8fd6-4ecb-b508-7cab883211d6@github.com>

On Fri, 19 Apr 2024 16:03:42 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The problem with closing a chunked stream is that it flushes both before and after the final chunk. I assume it may also cause delays.
> 
> The only case when you don't need to close the exchange or the output stream is when your response contains no content.

I don't understand this in reference to the other tests failing because they are not closing the output stream or ending the exchange. If that is incorrect behavior - because they are sending content - then those tests are invalid.

Still I have a fix for this I believe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572673757

From duke at openjdk.org  Fri Apr 19 17:12:58 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 17:12:58 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <paJvo4c-rcsVELGbeu7FOBjyhYAj_xJnp7KwZ28OOgE=.30072aae-d189-4406-8211-a4634cb97c7c@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
 <P-6yyBq4wSbKj0VxpgR-JfHJ2lSkmh2LzqK-eExmBAc=.499a1100-6d85-4a12-a4a1-619cb0c14a19@github.com>
 <8gqXVl98p1rLyrFgX4QngBGnXytfSfRuUhExTTNQ7qM=.1ab9d4ea-2753-42bd-8ae1-35638eceafe3@github.com>
 <paJvo4c-rcsVELGbeu7FOBjyhYAj_xJnp7KwZ28OOgE=.30072aae-d189-4406-8211-a4634cb97c7c@github.com>
Message-ID: <3jYCCsCTMVDIdaynZRPMWmCTKkBNgmUNEu_sxUj0_UE=.84e5e2e5-8057-4d84-a832-d6514fdad72e@github.com>

On Fri, 19 Apr 2024 16:39:37 GMT, robert engels <duke at openjdk.org> wrote:

> B4769350

I don't understand this. If the handler "leaks it", isn't that a bug? If sending a chunked response I think you have to close the output stream or end the exchange otherwise it is a bug in the handler code.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2066972419

From djelinski at openjdk.org  Fri Apr 19 17:26:59 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 17:26:59 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <mRV-UCBuKZcQHHQIaXSUnZL16HXFCFhs3J3PqHeXnAc=.cf993f12-8fd6-4ecb-b508-7cab883211d6@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
 <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>
 <gFGg0DHCs2gzTLQ2PYML9h9VXieq9mVf4UlUl6gh4_c=.d9dc0cf7-119c-4b19-ae74-3149407bac86@github.com>
 <1X3NajBwoFmXfDGwhDYVGOogHq5dNWhPgy1NJoDpv8k=.e3006bcd-a583-42a8-b744-dcc600723a95@github.com>
 <mRV-UCBuKZcQHHQIaXSUnZL16HXFCFhs3J3PqHeXnAc=.cf993f12-8fd6-4ecb-b508-7cab883211d6@github.com>
Message-ID: <FQ1Fq582qFnEhQ3BuaYJ6ypyjnRsL_LGNCFEo-njQHU=.a69dba43-accb-4bb9-8576-23702217cb5d@github.com>

On Fri, 19 Apr 2024 17:06:54 GMT, robert engels <duke at openjdk.org> wrote:

>> The problem with closing a chunked stream is that it flushes both before and after the final chunk. I assume it may also cause delays.
>> 
>> The only case when you don't need to close the exchange or the output stream is when your response contains no content.
>
>> The problem with closing a chunked stream is that it flushes both before and after the final chunk. I assume it may also cause delays.
>> 
>> The only case when you don't need to close the exchange or the output stream is when your response contains no content.
> 
> I don't understand this in reference to the other tests failing because they are not closing the output stream or ending the exchange. If that is incorrect behavior - because they are sending content - then those tests are invalid.
> 
> Still I have a fix for this I believe.

ah no, this is not related to the test failures; this is only about the original issue (small sends result in problems with delayed acks)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572691999

From djelinski at openjdk.org  Fri Apr 19 17:29:57 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 17:29:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
Message-ID: <2LnoPBijTo9eokIQxn5eC3HrGsMP_kQeMYfhBfXKU-c=.72253d6a-e14f-47a4-ba94-bb56781b12c7@github.com>

On Fri, 19 Apr 2024 15:17:17 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update based on PR review

Yes it is a bug. But even with the bug the code used to work, and now it doesn't. Users might have similar buggy code that will stop working when they get this fix. We need to post a release note so that they know what to expect.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2066996033

From duke at openjdk.org  Fri Apr 19 17:38:13 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 17:38:13 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v3]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <n5lK022N-j6x0Wl6Mz8Y5EO3fCFDR9ATOD8TuneZkSk=.e420f42e-7475-4c12-a7e9-131635cecf35@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with two additional commits since the last revision:

 - automatically close a fixed response. this is benign as a further close is ignore, and a further write continues to throw an exception for too much data
 - update based on PR review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/8aa89b0d..c5f26ada

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

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

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

From duke at openjdk.org  Fri Apr 19 17:38:13 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 17:38:13 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v2]
In-Reply-To: <2LnoPBijTo9eokIQxn5eC3HrGsMP_kQeMYfhBfXKU-c=.72253d6a-e14f-47a4-ba94-bb56781b12c7@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
 <2LnoPBijTo9eokIQxn5eC3HrGsMP_kQeMYfhBfXKU-c=.72253d6a-e14f-47a4-ba94-bb56781b12c7@github.com>
Message-ID: <V8cBwXJzl4QbGEQ9lbQtsmLeP77MdK4gawd2I503iak=.b8649e2b-cc51-4d78-8b20-ef155980e1ef@github.com>

On Fri, 19 Apr 2024 17:27:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Yes it is a bug. But even with the bug the code used to work, and now it doesn't. Users might have similar buggy code that will stop working when they get this fix. We need to post a release note so that they know what to expect.

Are you sure it worked? I think the connection would be "dead" - the client would see the last response - but if it tried to send another request on the connection it would hang - because WriteFinished event would never have been emitted - and so the exchange/connection would never be read for another request.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2067004026

From duke at openjdk.org  Fri Apr 19 17:43:57 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 17:43:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v3]
In-Reply-To: <3jYCCsCTMVDIdaynZRPMWmCTKkBNgmUNEu_sxUj0_UE=.84e5e2e5-8057-4d84-a832-d6514fdad72e@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
 <P-6yyBq4wSbKj0VxpgR-JfHJ2lSkmh2LzqK-eExmBAc=.499a1100-6d85-4a12-a4a1-619cb0c14a19@github.com>
 <8gqXVl98p1rLyrFgX4QngBGnXytfSfRuUhExTTNQ7qM=.1ab9d4ea-2753-42bd-8ae1-35638eceafe3@github.com>
 <paJvo4c-rcsVELGbeu7FOBjyhYAj_xJnp7KwZ28OOgE=.30072aae-d189-4406-8211-a4634cb97c7c@github.com>
 <3jYCCsCTMVDIdaynZRPMWmCTKkBNgmUNEu_sxUj0_UE=.84e5e2e5-8057-4d84-a832-d6514fdad72e@github.com>
Message-ID: <NdO4a5cVj1u_80dm43Q7jmb0gaU80EWMaiyCUSkZVF8=.ac585a4d-7f1e-4c73-be75-c43d38f0c2d9@github.com>

On Fri, 19 Apr 2024 17:10:43 GMT, robert engels <duke at openjdk.org> wrote:

> > B4769350
> 
> I don't understand this. If the handler "leaks it", isn't that a bug? If sending a chunked response I think you have to close the output stream or end the exchange otherwise it is a bug in the handler code.
> 
> Also, in reviewing the code, I don't think the old code could have worked either. If you don't close() the stream or the exchange() then the write finished event is never fired so the internals will be messed up - and the connection will hang.

I tested B4769350 with these changes and it worked without failure.

Is there a command line to only run all of the httpserver tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2067024817

From duke at openjdk.org  Fri Apr 19 17:51:27 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 17:51:27 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v4]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <EfQOxNxbigpq-EYnP-QmgJhFYtv9QgJfqVQF6iGX9c4=.48e3d833-f292-48c5-bf95-1ccd48146e06@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  fix jtreg params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/c5f26ada..3cf69db1

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

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

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

From duke at openjdk.org  Fri Apr 19 17:54:57 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 17:54:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v4]
In-Reply-To: <FQ1Fq582qFnEhQ3BuaYJ6ypyjnRsL_LGNCFEo-njQHU=.a69dba43-accb-4bb9-8576-23702217cb5d@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
 <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>
 <gFGg0DHCs2gzTLQ2PYML9h9VXieq9mVf4UlUl6gh4_c=.d9dc0cf7-119c-4b19-ae74-3149407bac86@github.com>
 <1X3NajBwoFmXfDGwhDYVGOogHq5dNWhPgy1NJoDpv8k=.e3006bcd-a583-42a8-b744-dcc600723a95@github.com>
 <mRV-UCBuKZcQHHQIaXSUnZL16HXFCFhs3J3PqHeXnAc=.cf993f12-8fd6-4ecb-b508-7cab883211d6@github.com>
 <FQ1Fq582qFnEhQ3BuaYJ6ypyjnRsL_LGNCFEo-njQHU=.a69dba43-accb-4bb9-8576-23702217cb5d@github.com>
Message-ID: <7gMnDphp6zexNLyqTRy26w4rFMKRPaHlNrdeAWMUeyM=.96a9cc88-e20e-436d-95cb-6ebc91e44fee@github.com>

On Fri, 19 Apr 2024 17:24:33 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> The problem with closing a chunked stream is that it flushes both before and after the final chunk. I assume it may also cause delays.
>>> 
>>> The only case when you don't need to close the exchange or the output stream is when your response contains no content.
>> 
>> I don't understand this in reference to the other tests failing because they are not closing the output stream or ending the exchange. If that is incorrect behavior - because they are sending content - then those tests are invalid.
>> 
>> Still I have a fix for this I believe.
>
> ah no, this is not related to the test failures; this is only about the original issue (small sends result in problems with delayed acks)

> The problem with closing a chunked stream is that it flushes both before and after the final chunk. I assume it may also cause delays.
> 
> The only case when you don't need to close the exchange or the output stream is when your response contains no content.

Can you point me to the code covering the before and after the final chunk? I would think the before flush should be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572720529

From djelinski at openjdk.org  Fri Apr 19 18:15:05 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 18:15:05 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v4]
In-Reply-To: <NdO4a5cVj1u_80dm43Q7jmb0gaU80EWMaiyCUSkZVF8=.ac585a4d-7f1e-4c73-be75-c43d38f0c2d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
 <P-6yyBq4wSbKj0VxpgR-JfHJ2lSkmh2LzqK-eExmBAc=.499a1100-6d85-4a12-a4a1-619cb0c14a19@github.com>
 <8gqXVl98p1rLyrFgX4QngBGnXytfSfRuUhExTTNQ7qM=.1ab9d4ea-2753-42bd-8ae1-35638eceafe3@github.com>
 <paJvo4c-rcsVELGbeu7FOBjyhYAj_xJnp7KwZ28OOgE=.30072aae-d189-4406-8211-a4634cb97c7c@github.com>
 <3jYCCsCTMVDIdaynZRPMWmCTKkBNgmUNEu_sxUj0_UE=.84e5e2e5-8057-4d84-a832-d6514fdad72e@github.com>
 <NdO4a5cVj1u_80dm43Q7jmb0gaU80EWMaiyCUSkZVF8=.ac585a4d-7f1e-4c73-be75-c43d38f0c2d9@github.com>
Message-ID: <61_vLR8zZ3nWKcbfN5rEaPqcBqJSafr5Nt2S1ljWpGs=.c8a16719-0a09-4c86-a6ae-40ac3620e008@github.com>

On Fri, 19 Apr 2024 17:41:22 GMT, robert engels <duke at openjdk.org> wrote:

> Is there a command line to only run all of the httpserver tests?

I'd use `make test TEST=jdk_net`. If you want something more selective, you can also point `TEST` to a specific file or directory.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2067065314

From djelinski at openjdk.org  Fri Apr 19 18:15:07 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 18:15:07 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v4]
In-Reply-To: <EfQOxNxbigpq-EYnP-QmgJhFYtv9QgJfqVQF6iGX9c4=.48e3d833-f292-48c5-bf95-1ccd48146e06@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <EfQOxNxbigpq-EYnP-QmgJhFYtv9QgJfqVQF6iGX9c4=.48e3d833-f292-48c5-bf95-1ccd48146e06@github.com>
Message-ID: <RYhQiVNDzouE_3H-XpwH2zYoOlXA9huv58aJAmRB35U=.901c444e-bf8a-497c-bde1-e7141e41d605@github.com>

On Fri, 19 Apr 2024 17:51:27 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix jtreg params

src/jdk.httpserver/share/classes/sun/net/httpserver/FixedLengthOutputStream.java line 68:

> 66:         remaining --;
> 67:         if(remaining==0) {
> 68:             close();

`close()` has the side effect of closing the input stream. This again may break other code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572742125

From djelinski at openjdk.org  Fri Apr 19 18:20:57 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 19 Apr 2024 18:20:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v4]
In-Reply-To: <7gMnDphp6zexNLyqTRy26w4rFMKRPaHlNrdeAWMUeyM=.96a9cc88-e20e-436d-95cb-6ebc91e44fee@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
 <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>
 <gFGg0DHCs2gzTLQ2PYML9h9VXieq9mVf4UlUl6gh4_c=.d9dc0cf7-119c-4b19-ae74-3149407bac86@github.com>
 <1X3NajBwoFmXfDGwhDYVGOogHq5dNWhPgy1NJoDpv8k=.e3006bcd-a583-42a8-b744-dcc600723a95@github.com>
 <mRV-UCBuKZcQHHQIaXSUnZL16HXFCFhs3J3PqHeXnAc=.cf993f12-8fd6-4ecb-b508-7cab883211d6@github.com>
 <FQ1Fq582qFnEhQ3BuaYJ6ypyjnRsL_LGNCFEo-njQHU=.a69dba43-accb-4bb9-8576-23702217cb5d@github.com>
 <7gMnDphp6zexNLyqTRy26w4rFMKRPaHlNrdeAWMUeyM=.96a9cc88-e20e-436d-95cb-6ebc91e44fee@github.com>
Message-ID: <01bO5jbUDypvv32oyKEP7d9631bnarB6I-2DEZx57xY=.b688b60b-9f9d-486b-8c3d-691cba06f93a@github.com>

On Fri, 19 Apr 2024 17:51:55 GMT, robert engels <duke at openjdk.org> wrote:

>> ah no, this is not related to the test failures; this is only about the original issue (small sends result in problems with delayed acks)
>
>> The problem with closing a chunked stream is that it flushes both before and after the final chunk. I assume it may also cause delays.
>> 
>> The only case when you don't need to close the exchange or the output stream is when your response contains no content.
> 
> Can you point me to the code covering the before and after the final chunk? I would think the before flush should be removed.

https://github.com/openjdk/jdk/blob/b704e91241b0f84d866f50a8f2c6af240087cb29/src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java#L140-L144

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572745437

From duke at openjdk.org  Fri Apr 19 18:20:58 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 18:20:58 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v4]
In-Reply-To: <01bO5jbUDypvv32oyKEP7d9631bnarB6I-2DEZx57xY=.b688b60b-9f9d-486b-8c3d-691cba06f93a@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
 <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>
 <gFGg0DHCs2gzTLQ2PYML9h9VXieq9mVf4UlUl6gh4_c=.d9dc0cf7-119c-4b19-ae74-3149407bac86@github.com>
 <1X3NajBwoFmXfDGwhDYVGOogHq5dNWhPgy1NJoDpv8k=.e3006bcd-a583-42a8-b744-dcc600723a95@github.com>
 <mRV-UCBuKZcQHHQIaXSUnZL16HXFCFhs3J3PqHeXnAc=.cf993f12-8fd6-4ecb-b508-7cab883211d6@github.com>
 <FQ1Fq582qFnEhQ3BuaYJ6ypyjnRsL_LGNCFEo-njQHU=.a69dba43-accb-4bb9-8576-23702217cb5d@github.com>
 <7gMnDphp6zexNLyqTRy26w4rFMKRPaHlNrdeAWMUeyM=.96a9cc88-e20e-436d-95cb-6ebc91e44fee@github.com>
 <01bO5jbUDypvv32oyKEP7d9631bnarB6I-2DEZx57xY=.b688b60b-9f9d-486b-8c3d-691cba06f93a@github.com>
Message-ID: <TSqn3RPfbvnIigLNL86bimwpuW7Qqbve3EuWqwh23rE=.df8af562-c400-4047-ab1e-820f2e6e4dcd@github.com>

On Fri, 19 Apr 2024 18:15:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> The problem with closing a chunked stream is that it flushes both before and after the final chunk. I assume it may also cause delays.
>>> 
>>> The only case when you don't need to close the exchange or the output stream is when your response contains no content.
>> 
>> Can you point me to the code covering the before and after the final chunk? I would think the before flush should be removed.
>
> https://github.com/openjdk/jdk/blob/b704e91241b0f84d866f50a8f2c6af240087cb29/src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java#L140-L144

I figured out what you are referring to. Let me look at this, I am pretty sure I can remove the first flush.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572747571

From duke at openjdk.org  Fri Apr 19 18:31:11 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 18:31:11 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v5]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <RJPKAES_czlY2JgySpnKIQ3ie_RZlAGs0GpkVPu6Afk=.bd932b35-b8c8-42b3-83ad-8b40e8b0e77c@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  ignore flush() on closed stream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/3cf69db1..d9126b96

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

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

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

From duke at openjdk.org  Fri Apr 19 18:31:12 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 18:31:12 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v4]
In-Reply-To: <RYhQiVNDzouE_3H-XpwH2zYoOlXA9huv58aJAmRB35U=.901c444e-bf8a-497c-bde1-e7141e41d605@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <EfQOxNxbigpq-EYnP-QmgJhFYtv9QgJfqVQF6iGX9c4=.48e3d833-f292-48c5-bf95-1ccd48146e06@github.com>
 <RYhQiVNDzouE_3H-XpwH2zYoOlXA9huv58aJAmRB35U=.901c444e-bf8a-497c-bde1-e7141e41d605@github.com>
Message-ID: <PlFPAkszJnqU7jwVSUwj84yXXPgqbT2u4pclWldz9Qg=.1205d2b0-c113-4f3e-b891-5430cc76a5f9@github.com>

On Fri, 19 Apr 2024 18:12:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix jtreg params
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/FixedLengthOutputStream.java line 68:
> 
>> 66:         remaining --;
>> 67:         if(remaining==0) {
>> 68:             close();
> 
> `close()` has the side effect of closing the input stream. This again may break other code.

We can remove this. As I stated, it is a bad bug and will leave the connection in a corrupted state if the handler does not call close() on the outstream or the exchange, so I don't think existing code "works".

Also, I think issuing the close() here is benign, because any further writes would throw an exception (too much data), and a subsequent close (or multiple closes) are ignored.

Essentially, once you have written all of the data you stated you would send, it is a critical error if you do anything on the output stream other than flush() or close(). I added a check that a flush() on a closed stream is ignored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572757591

From duke at openjdk.org  Fri Apr 19 18:43:18 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 18:43:18 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v6]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <rZVkbR7OdMSoJRHtX_ois2AnMYtktKUbEqoWmaAD1-c=.2e869df3-5a0f-4d6f-890f-01250b6ca5bc@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  fix chunked response for small packets

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/d9126b96..aca4cb11

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

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

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

From duke at openjdk.org  Fri Apr 19 18:43:18 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 18:43:18 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v6]
In-Reply-To: <TSqn3RPfbvnIigLNL86bimwpuW7Qqbve3EuWqwh23rE=.df8af562-c400-4047-ab1e-820f2e6e4dcd@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
 <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>
 <gFGg0DHCs2gzTLQ2PYML9h9VXieq9mVf4UlUl6gh4_c=.d9dc0cf7-119c-4b19-ae74-3149407bac86@github.com>
 <1X3NajBwoFmXfDGwhDYVGOogHq5dNWhPgy1NJoDpv8k=.e3006bcd-a583-42a8-b744-dcc600723a95@github.com>
 <mRV-UCBuKZcQHHQIaXSUnZL16HXFCFhs3J3PqHeXnAc=.cf993f12-8fd6-4ecb-b508-7cab883211d6@github.com>
 <FQ1Fq582qFnEhQ3BuaYJ6ypyjnRsL_LGNCFEo-njQHU=.a69dba43-accb-4bb9-8576-23702217cb5d@github.com>
 <7gMnDphp6zexNLyqTRy26w4rFMKRPaHlNrdeAWMUeyM=.96a9cc88-e20e-436d-95cb-6ebc91e44fee@github.com>
 <01bO5jbUDypvv32oyKEP7d9631bnarB6I-2DEZx57xY=.b688b60b-9f9d-486b-8c3d-691cba06f93a@github.com>
 <TSqn3RPfbvnIigLNL86bimwpuW7Qqbve3EuWqwh23rE=.df8af562-c400-4047-ab1e-820f2e6e4dcd@github.com>
Message-ID: <h1MxJrETBIqeTRkvLDfmeNWbKwkUv9ScQh0YZHsOBy4=.9cb03f9f-796c-49f1-8be3-639c7a3ab2b0@github.com>

On Fri, 19 Apr 2024 18:17:56 GMT, robert engels <duke at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/blob/b704e91241b0f84d866f50a8f2c6af240087cb29/src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java#L140-L144
>
> I figured out what you are referring to. Let me look at this, I am pretty sure I can remove the first flush.

I posted a fix which addresses this. I will modify the test case to test both methods of returning the data.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572772695

From duke at openjdk.org  Fri Apr 19 18:54:48 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 18:54:48 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v7]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <-LQSk5Gw-8uKtIV8Ee4RzW6HRxp4fJ5aiTpmdizXrv8=.210bf2f2-a1d4-435e-b3e8-7f609f64113e@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with two additional commits since the last revision:

 - avoid sending multiple empty chunks
 - test both fixed and chunked responses

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/aca4cb11..603b093a

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

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

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

From dfuchs at openjdk.org  Fri Apr 19 18:54:49 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 18:54:49 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v6]
In-Reply-To: <rZVkbR7OdMSoJRHtX_ois2AnMYtktKUbEqoWmaAD1-c=.2e869df3-5a0f-4d6f-890f-01250b6ca5bc@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <rZVkbR7OdMSoJRHtX_ois2AnMYtktKUbEqoWmaAD1-c=.2e869df3-5a0f-4d6f-890f-01250b6ca5bc@github.com>
Message-ID: <AEHH-Fzlbl1bSinlLJnH-JPW0urX0K7yn6DAeaMcxXI=.0cf72d9d-4f53-4db3-a1e9-a3961ad667ea@github.com>

On Fri, 19 Apr 2024 18:43:18 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix chunked response for small packets

src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java line 142:

> 140:         try {
> 141:             /* write any pending chunk data */
> 142:             writeChunk();

Isn't there a risk that you might write two empty chunks here if there are no pending chunks?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572777362

From duke at openjdk.org  Fri Apr 19 18:54:49 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 18:54:49 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v6]
In-Reply-To: <AEHH-Fzlbl1bSinlLJnH-JPW0urX0K7yn6DAeaMcxXI=.0cf72d9d-4f53-4db3-a1e9-a3961ad667ea@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <rZVkbR7OdMSoJRHtX_ois2AnMYtktKUbEqoWmaAD1-c=.2e869df3-5a0f-4d6f-890f-01250b6ca5bc@github.com>
 <AEHH-Fzlbl1bSinlLJnH-JPW0urX0K7yn6DAeaMcxXI=.0cf72d9d-4f53-4db3-a1e9-a3961ad667ea@github.com>
Message-ID: <vQxmuN8WefU1JkSOdoCbIlfsjlYDII-HlPBrngVFowE=.84309d43-ac5e-4bc0-93e5-7a17b23fc140@github.com>

On Fri, 19 Apr 2024 18:44:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix chunked response for small packets
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java line 142:
> 
>> 140:         try {
>> 141:             /* write any pending chunk data */
>> 142:             writeChunk();
> 
> Isn't there a risk that you might write two empty chunks here if there are no pending chunks?

yes, let me fixed that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572781977

From dfuchs at openjdk.org  Fri Apr 19 18:54:49 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 18:54:49 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v6]
In-Reply-To: <vQxmuN8WefU1JkSOdoCbIlfsjlYDII-HlPBrngVFowE=.84309d43-ac5e-4bc0-93e5-7a17b23fc140@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <rZVkbR7OdMSoJRHtX_ois2AnMYtktKUbEqoWmaAD1-c=.2e869df3-5a0f-4d6f-890f-01250b6ca5bc@github.com>
 <AEHH-Fzlbl1bSinlLJnH-JPW0urX0K7yn6DAeaMcxXI=.0cf72d9d-4f53-4db3-a1e9-a3961ad667ea@github.com>
 <vQxmuN8WefU1JkSOdoCbIlfsjlYDII-HlPBrngVFowE=.84309d43-ac5e-4bc0-93e5-7a17b23fc140@github.com>
Message-ID: <zYnxTQS4naqwMuXj_cXirgqL9BoSTETAsJpR0nzllIc=.a61bbdbb-009f-4a16-a974-926275ea3255@github.com>

On Fri, 19 Apr 2024 18:49:33 GMT, robert engels <duke at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java line 142:
>> 
>>> 140:         try {
>>> 141:             /* write any pending chunk data */
>>> 142:             writeChunk();
>> 
>> Isn't there a risk that you might write two empty chunks here if there are no pending chunks?
>
> yes, let me fixed that.

Shouldn't you look at whether count > 0 as is  done in flush() ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572782506

From duke at openjdk.org  Fri Apr 19 18:54:49 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 18:54:49 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v6]
In-Reply-To: <zYnxTQS4naqwMuXj_cXirgqL9BoSTETAsJpR0nzllIc=.a61bbdbb-009f-4a16-a974-926275ea3255@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <rZVkbR7OdMSoJRHtX_ois2AnMYtktKUbEqoWmaAD1-c=.2e869df3-5a0f-4d6f-890f-01250b6ca5bc@github.com>
 <AEHH-Fzlbl1bSinlLJnH-JPW0urX0K7yn6DAeaMcxXI=.0cf72d9d-4f53-4db3-a1e9-a3961ad667ea@github.com>
 <vQxmuN8WefU1JkSOdoCbIlfsjlYDII-HlPBrngVFowE=.84309d43-ac5e-4bc0-93e5-7a17b23fc140@github.com>
 <zYnxTQS4naqwMuXj_cXirgqL9BoSTETAsJpR0nzllIc=.a61bbdbb-009f-4a16-a974-926275ea3255@github.com>
Message-ID: <wnWsbkuvSqeT1TQY1ZdZ1IjB8PzQazYL6k0g1do8Y3s=.6640ec64-b623-4b33-9b4e-714d5987a1be@github.com>

On Fri, 19 Apr 2024 18:50:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> yes, let me fixed that.
>
> Shouldn't you look at whether count > 0 as is  done in flush() ?

corrected. good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572783063

From duke at openjdk.org  Fri Apr 19 18:54:49 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 18:54:49 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v7]
In-Reply-To: <h1MxJrETBIqeTRkvLDfmeNWbKwkUv9ScQh0YZHsOBy4=.9cb03f9f-796c-49f1-8be3-639c7a3ab2b0@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <N-tGwsvZdxzKwUDoboOSh3YyupM2NuylXsSwP9d3mgU=.84e46270-c734-4747-9f42-e0a783073426@github.com>
 <TSnWq6Mbe0f3BXNzpzpSn499bUs9qTZlUnQQqvMM71g=.42ab139e-aaa9-4945-b721-0f87b0452d89@github.com>
 <gFGg0DHCs2gzTLQ2PYML9h9VXieq9mVf4UlUl6gh4_c=.d9dc0cf7-119c-4b19-ae74-3149407bac86@github.com>
 <1X3NajBwoFmXfDGwhDYVGOogHq5dNWhPgy1NJoDpv8k=.e3006bcd-a583-42a8-b744-dcc600723a95@github.com>
 <mRV-UCBuKZcQHHQIaXSUnZL16HXFCFhs3J3PqHeXnAc=.cf993f12-8fd6-4ecb-b508-7cab883211d6@github.com>
 <FQ1Fq582qFnEhQ3BuaYJ6ypyjnRsL_LGNCFEo-njQHU=.a69dba43-accb-4bb9-8576-23702217cb5d@github.com>
 <7gMnDphp6zexNLyqTRy26w4rFMKRPaHlNrdeAWMUeyM=.96a9cc88-e20e-436d-95cb-6ebc91e44fee@github.com>
 <01bO5jbUDypvv32oyKEP7d9631bnarB6I-2DEZx57xY=.b688b60b-9f9d-486b-8c3d-691cba06f93a@github.com>
 <TSqn3RPfbvnIigLNL86bimwpuW7Qqbve3EuWqwh23rE=.df8af562-c400-4047-ab1e-820f2e6e4dcd@github.com>
 <h1MxJrETBIqeTRkvLDfmeNWbKwkUv9ScQh0
 YZHsOBy4=.9cb03f9f-796c-49f1-8be3-639c7a3ab2b0@github.com>
Message-ID: <RK8ayj1KDGix0S82SL6bvN3-jxrOJHDa-8rLrBeryXk=.f34c9dd8-f58c-4084-902f-27a43b24e719@github.com>

On Fri, 19 Apr 2024 18:40:20 GMT, robert engels <duke at openjdk.org> wrote:

>> I figured out what you are referring to. Let me look at this, I am pretty sure I can remove the first flush.
>
> I posted a fix which addresses this. I will modify the test case to test both methods of returning the data.

test case has been updated as well to test both fixed and chunked responses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572781450

From duke at openjdk.org  Fri Apr 19 18:56:58 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 18:56:58 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v4]
In-Reply-To: <PlFPAkszJnqU7jwVSUwj84yXXPgqbT2u4pclWldz9Qg=.1205d2b0-c113-4f3e-b891-5430cc76a5f9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <EfQOxNxbigpq-EYnP-QmgJhFYtv9QgJfqVQF6iGX9c4=.48e3d833-f292-48c5-bf95-1ccd48146e06@github.com>
 <RYhQiVNDzouE_3H-XpwH2zYoOlXA9huv58aJAmRB35U=.901c444e-bf8a-497c-bde1-e7141e41d605@github.com>
 <PlFPAkszJnqU7jwVSUwj84yXXPgqbT2u4pclWldz9Qg=.1205d2b0-c113-4f3e-b891-5430cc76a5f9@github.com>
Message-ID: <g8FGjPwYNAdzrRSU3HsRvwjK9qWssxPUKc9ZZzlKv-8=.65edb1af-60e3-4157-aeb9-bbe8b5599e69@github.com>

On Fri, 19 Apr 2024 18:28:19 GMT, robert engels <duke at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/sun/net/httpserver/FixedLengthOutputStream.java line 68:
>> 
>>> 66:         remaining --;
>>> 67:         if(remaining==0) {
>>> 68:             close();
>> 
>> `close()` has the side effect of closing the input stream. This again may break other code.
>
> We can remove this. As I stated, it is a bad bug and will leave the connection in a corrupted state if the handler does not call close() on the outstream or the exchange, so I don't think existing code "works".
> 
> Also, I think issuing the close() here is benign, because any further writes would throw an exception (too much data), and a subsequent close (or multiple closes) are ignored.
> 
> Essentially, once you have written all of the data you stated you would send, it is a critical error if you do anything on the output stream other than flush() or close(). I added a check that a flush() on a closed stream is ignored.

as to the input stream being closed, that already would have happened. If the handler closed the output stream, then tried to read the input stream, it would fail.

in retrospect, I think this should be removed, because if the handler was not closing the output stream before, the connection would have been dead, so it seems doubtful this was the case in the field. and then we can fix the broken tests to not not have a bug in not properly closing the output stream.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572786639

From duke at openjdk.org  Fri Apr 19 19:00:20 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 19:00:20 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v8]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <eiIjCoU8v2U-GjgeCc_yqUIc8vgDLCSFd4qwaaTrOYc=.03807c44-23d0-42d3-8d75-43a6f4295cba@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  avoid sending multiple empty chunks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/603b093a..12389caf

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

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

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

From jjg at openjdk.org  Fri Apr 19 19:10:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:10:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <ed4aAlPaZnpFM_HVp75esTjXxSCzwKem2HqiWHPwcvM=.8264f272-6ffe-453f-940c-f0db3225adb1@github.com>

On Fri, 19 Apr 2024 10:53:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> src/java.base/macosx/classes/apple/security/AppleProvider.java line 33:
> 
>> 31: /*
>> 32:  * The Apple Security Provider.
>> 33:  */
> 
> Does it make sense to incorporate this comment into the following javadoc comment?
> 
> 
> /**
>  * Defines the (an) Apple security provider.
>  * ...
>  */
> @SuppressWarnings("serial") // JDK implementation class

Maybe, but only maybe, and if so, it would be out of scope for this work. That would be up to the relevant component team.

That being said, neither comment is part of any public API, and this comment is effectively already present in the first sentence of the actual doc comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572813320

From jjg at openjdk.org  Fri Apr 19 19:14:59 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:14:59 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <EyFdhhhVPa0ZjxN9MNwl--5bvRDGYrZJR8miOOgOBZ0=.513db9e4-6a6f-49b2-a0c8-3baa05cf5cf0@github.com>

On Fri, 19 Apr 2024 10:44:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 37:
> 
>> 35: import static sun.security.util.SecurityProviderConstants.*;
>> 36: 
>> 37: /*
> 
> Should this be included in the main javadoc comment? The `@author` tags belong in the javadoc comment.
> 
> The javadoc itself is likely unreadable, when processed the entire comment becomes one very long paragraph.

That would be up to the relevant component to decide how to improve these comments. The goal here is proactively fix any warnings that may be generated about multiple doc comments on a declaration.

I note that neither comment contributes to the public API, and that `@author` tags are generally obsolete these days. The VCS metadata is a more accurate reflection of individual contributions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572818078

From duke at openjdk.org  Fri Apr 19 19:15:19 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 19:15:19 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v9]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <PR9aplOwXx7y1-rdgd7ArN70BZLY6DXAwi5ExLrfcro=.4d3c1148-4f68-4179-98be-c3e33d16cda2@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  avoid sending multiple empty chunks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/12389caf..c69bc7dc

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

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

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

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
  
  Fix grammatical typo
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18846/files
  - new: https://git.openjdk.org/jdk/pull/18846/files/fcbe02d5..d7b46a85

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

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

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

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <plSw9jOH-0xxK5ZFqpYVa_RdLe0jGTIrrmOije3GV2c=.8c3f6569-fdfb-4fe8-b501-78f5da7fdf74@github.com>

On Fri, 19 Apr 2024 10:49:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>>   
>>   Fix grammatical typo
>>   
>>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>
> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 38:
> 
>> 36: 
>> 37: /**
>> 38:  * Open an file input stream given a URL.
> 
> Suggestion:
> 
>  * Open a file input stream given a URL.

OK, I'll accept this as a minor typo mixup, that does not in itself need a CSR. But generally, it is not a goal to fix issues in the content of doc comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572821973

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

> It is somewhat off-topic. Yet I noticed javadoc comments in some files are followed a blank line, and others aren't. Out of my curiosity, is there a convention about the blank line between the javadoc comment and the class or interface declaration? Should there be one?
> 
> ```java
> /**
>  * This is a class.
>  */
> public class A {}
> ```
> 
> or
> 
> ```java
> /**
>  * This is a class.
>  */
> 
> public class A {}
> ```
> 
> Which is the most common? Which is preferred?

We do not have an overall style guide.   The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067156407

From jjg at openjdk.org  Fri Apr 19 19:27:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:27:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>
Message-ID: <-fG_aheP9IBZLBq6GVU_1peVxqhpa7cQB0cpYK7cdDY=.b81305e0-56d5-4df2-9ac2-ca73e6433177@github.com>

On Fri, 19 Apr 2024 11:32:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This comment is not a review. I simply use the opportunity provided by this PR to suggest that we stop making new `/** ... */` and separately fix old jtreg comments like this:
> 
> ```
> /**
>  * @test TestSmallHeap
>  * @bug 8067438 8152239
>  * @summary Verify that starting the VM with a small heap works
>  * @library /test/lib
>  * @modules java.base/jdk.internal.misc
>  * @build jdk.test.whitebox.WhiteBox
>  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>  * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI     gc.TestSmallHeap
>  */
> ```
> 
> I know that those comments only appear in tests, and that tests are never documented. Still, it is confusing to see such comments and IDEs might frown upon them too. Generally, it is a good rule of thumb that `/** ... */` should be reserved only for javadoc.

I agree we should not be using `/**` for test description comments.
IntelliJ tells me there are 103+ matches in 97+ files, so this would be a non-trivial cleanup. 
I note there are 22 issues in `test/langtools/jdk` tests (i.e. javadoc tests), so let's start there ;-)

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067164929

From aivanov at openjdk.org  Fri Apr 19 19:32:57 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 19:32:57 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <Lq-Q7ZUwaTVlfO51UDbEwlePabsWtebfX4r-DIObVwU=.fd2569b7-0595-4661-a841-aa890b9c3daa@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2012219677

From aivanov at openjdk.org  Fri Apr 19 19:32:58 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 19:32:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
Message-ID: <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>

On Fri, 19 Apr 2024 19:18:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> We do not have an overall style guide. The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.

That's what I do.

I saw either style used in JDK. Yet I didn't check which style is more common? to decide which style I should use when creating new files with javadoc comments. [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) doesn't have a blank line between the javadoc comment and class declaration; nor do javadoc comments for fields and methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067169319

From naoto at openjdk.org  Fri Apr 19 19:51:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Apr 2024 19:51:06 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Unless it is absolutely necessary, I would not fix comments in `jdk.internal.icu` sources, as they are in the upstream code, and would like to minimize the merging effort.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067190364

From duke at openjdk.org  Fri Apr 19 19:52:01 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 19:52:01 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v9]
In-Reply-To: <PR9aplOwXx7y1-rdgd7ArN70BZLY6DXAwi5ExLrfcro=.4d3c1148-4f68-4179-98be-c3e33d16cda2@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <PR9aplOwXx7y1-rdgd7ArN70BZLY6DXAwi5ExLrfcro=.4d3c1148-4f68-4179-98be-c3e33d16cda2@github.com>
Message-ID: <LIiGD2qwLmLqA6TZk_hrHZhhFYKlnkaG7TwyVxz5n38=.f1d1d26a-cfb8-45d9-91dc-b6949d50fed7@github.com>

On Fri, 19 Apr 2024 19:15:19 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid sending multiple empty chunks

Hi all. Hold off on further review. My local OSX version is failing - but strangely the linux version is working. I believe the environment may be corrupted but I need to track down what is happening.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2067191592

From duke at openjdk.org  Fri Apr 19 20:14:42 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 20:14:42 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v10]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <Rn2epiiPvjcsAMBM-vwgJiQWz4dxqQiIGym8lstd4so=.ce48148b-2760-46d9-b494-ed7328f9ed00@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  need to flush before close

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/c69bc7dc..1e278f23

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

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

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

From duke at openjdk.org  Fri Apr 19 20:14:42 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 20:14:42 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v9]
In-Reply-To: <LIiGD2qwLmLqA6TZk_hrHZhhFYKlnkaG7TwyVxz5n38=.f1d1d26a-cfb8-45d9-91dc-b6949d50fed7@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <PR9aplOwXx7y1-rdgd7ArN70BZLY6DXAwi5ExLrfcro=.4d3c1148-4f68-4179-98be-c3e33d16cda2@github.com>
 <LIiGD2qwLmLqA6TZk_hrHZhhFYKlnkaG7TwyVxz5n38=.f1d1d26a-cfb8-45d9-91dc-b6949d50fed7@github.com>
Message-ID: <sFrPt47pQsCVKQrymjV-sRLucjOAr6-R7ZCnte5c8H8=.076fb130-8f80-4bf8-88bd-0f922b8c720e@github.com>

On Fri, 19 Apr 2024 19:48:24 GMT, robert engels <duke at openjdk.org> wrote:

> Hi all. Hold off on further review. My local OSX version is failing - but strangely the linux version is working. I believe the environment may be corrupted but I need to track down what is happening.

Everything is working now.

I think removing the auto-close in the fixed output and fixing the test cases is a better solution, since I don't think existing code would work without the close anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2067219226

From duke at openjdk.org  Fri Apr 19 20:18:08 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 20:18:08 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v11]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <ICeH3ojZ0GNnEKSJ_rScZIxwvGeEl1SFoo55JwvJjPg=.b7707d67-6462-49de-857a-fe27f872b580@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  rename testcase for clarity

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/1e278f23..c94f3c2b

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

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

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

From duke at openjdk.org  Fri Apr 19 20:18:08 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 19 Apr 2024 20:18:08 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v11]
In-Reply-To: <IfAXu4KAjtpN5N44Nlxh_My6u18LcRIR__6ifoq1Pn4=.3b1db370-b88c-4057-bbd4-04a00dbd169c@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <pxnjSAwfHG2nPJ93MQM6BfRLORZZcVKLq1OME6Rviks=.12d94e0f-4db0-4509-b5d0-8c5fad3e3186@github.com>
 <dfpuL2oJUUxJXDXFXlNZnQXmIM4dGeKeSu5J5xX9RPs=.6d09fc05-9551-4eb9-927d-7947eb28d16c@github.com>
 <IRAhGi3bu2v7xZvP8Pf7odeE96C4FKDJbx23nnDbh78=.ac74ab33-6cd1-496f-9654-f1921644e573@github.com>
 <IfAXu4KAjtpN5N44Nlxh_My6u18LcRIR__6ifoq1Pn4=.3b1db370-b88c-4057-bbd4-04a00dbd169c@github.com>
Message-ID: <A9FCxTNY7Mb2bBRuvfZNHjhdnBYpzEB0Xy5tsYOsV-k=.7c87eb36-f958-4d0b-bfc5-87a62b20b2a0@github.com>

On Fri, 19 Apr 2024 15:45:50 GMT, robert engels <duke at openjdk.org> wrote:

>> I agree with Daniel here - with new tests we try to use a more descriptive name. I hate to see JBS issues titled `foo/bar/BNNNNNN.java failed` - and then I have no clue of what that test might be doing :-)
>
> I will change.

changed to TcpNoDelayNotRequired

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572898923

From jjg at openjdk.org  Fri Apr 19 20:36:30 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 20:36:30 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
 <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>
Message-ID: <H9YDeHC1vbzTbg9fB2HdGaLMDU1BuKqekRT-kLMyGKU=.2d7b6fc4-b059-4944-89b3-67004dac6ea0@github.com>

On Fri, 19 Apr 2024 19:47:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Unless it is absolutely necessary, I would not fix comments in `jdk.internal.icu` sources, as they are in the upstream code, and would like to minimize the merging effort.

@naotoj Given the policy and strong desire to compile `java.base` with all lint warnings enabled and `-Werror`, all of the proposed changes in this PR will each individually break the build if/when the warning is added to `javac` and we continue to compile `java.base` with the current build settings.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067246948

From naoto at openjdk.org  Fri Apr 19 20:40:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Apr 2024 20:40:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

OK, fair enough. Approving for the `icu` part

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2012372872

From jjg at openjdk.org  Fri Apr 19 21:07:02 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 21:07:02 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
 <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>
Message-ID: <7LlnKXolx2fp1kJEq5_UYjcC-q0Y8AF2hidczf7kPl8=.bcfb39c9-9992-44ee-9cec-8bfcda42dd9b@github.com>

On Fri, 19 Apr 2024 20:38:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> OK, fair enough. Approving for the `icu` part

Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067280359

From clanger at openjdk.org  Sat Apr 20 23:13:48 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 20 Apr 2024 23:13:48 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v3]
In-Reply-To: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
Message-ID: <99jN8b2P3kZeY9Pc_Zmvf-oKfGnWoVs2M1RdqcQb_b4=.911978ac-bb25-4d90-a306-e56e9b245b50@github.com>

> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
> 
> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
> 
> E.g. on my developer laptop runtime went down from ~100s to ~10s.
> 
> I also made additional cleanups/refactoring in the test.

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

 - Simplify the test further
 - Merge branch 'master' into JDK-8330523
 - Small further cleanup
 - JDK-8330523

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18817/files
  - new: https://git.openjdk.org/jdk/pull/18817/files/b68258da..eae78eca

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

  Stats: 28015 lines in 191 files changed: 13646 ins; 13218 del; 1151 mod
  Patch: https://git.openjdk.org/jdk/pull/18817.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18817/head:pull/18817

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

From clanger at openjdk.org  Sat Apr 20 23:13:48 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 20 Apr 2024 23:13:48 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v2]
In-Reply-To: <jOL2j7SwSC_UYA4qkC9GfJYgtc5dgeYs_KdxTE1bVMk=.1f4e7773-1658-404d-b777-5ba2bf603196@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <zlHnQueCaQIPaQKPtSBN1wJ1VyRlCxhTTlIma3nCJO0=.85f236af-8977-4c19-82fe-fde87316b763@github.com>
 <jOL2j7SwSC_UYA4qkC9GfJYgtc5dgeYs_KdxTE1bVMk=.1f4e7773-1658-404d-b777-5ba2bf603196@github.com>
Message-ID: <Sy5G6NuQBHlpRnJCiURLr-zBiNON68G5kJSjvChgh5o=.dfeee980-d7c5-4f77-8ac9-c91f75f0e4e9@github.com>

On Fri, 19 Apr 2024 10:20:58 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> If that makes the end result smaller / easier to read, go for it!

Here we go!

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

PR Comment: https://git.openjdk.org/jdk/pull/18817#issuecomment-2067810508

From ethan at mccue.dev  Sun Apr 21 01:56:45 2024
From: ethan at mccue.dev (Ethan McCue)
Date: Sat, 20 Apr 2024 21:56:45 -0400
Subject: HttpServer.create default backlog value overloads
Message-ID: <CA+NR86jd67gm1jWt3TZmY4MunNvSkqu1gfe30QUN2+HP=kCd5A@mail.gmail.com>

Hi all,

I've been looking at the HttpServer API recently with the aim of making its
API a little more friendly to the average joe.

One area that feels like it would be an easy win, and correct me if I'm
wrong, is with the "backlog" parameter provided at server creation.

HttpServer.create(new InetSocketAddress(4000), 0);

HttpServer.create().bind(new InetSocketAddress(4000), 0);

In both cases, values less than or equal to 0 are documented to mean "use a
system default." It feels beneficial to provide overloads which do not
require users to specify that.

HttpServer.create(new InetSocketAddress(4000));

HttpServer.create().bind(new InetSocketAddress(4000));

 With perhaps similar treatment given to the create method which sets up an
initial context.

(There is at least 1 more "magic number" in the API @ .sendResponseHeaders,
but one thing at a time)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20240420/5bfc0342/attachment.htm>

From duke at openjdk.org  Sun Apr 21 18:24:48 2024
From: duke at openjdk.org (robert engels)
Date: Sun, 21 Apr 2024 18:24:48 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v12]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <5fju_Dx9Z6wMP6sqUOlwG_jKfhwDqgIvA_LAJlb5-Gc=.c3e71a6c-c3ea-49e9-a5f1-336f29c7f0c9@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  fix jtreg params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/c94f3c2b..99f3c68a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=10-11

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

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

From duke at openjdk.org  Sun Apr 21 18:49:45 2024
From: duke at openjdk.org (robert engels)
Date: Sun, 21 Apr 2024 18:49:45 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v13]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <eANUSdz3i5ukud0zOD-RUHzNF1s7Y8Ntga9q8xEIV00=.5bdbba90-0484-496d-815d-35fd5c2ade7e@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  remove FixLengthOutputStream changes since not needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/99f3c68a..e15334b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=11-12

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

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

From duke at openjdk.org  Sun Apr 21 18:58:33 2024
From: duke at openjdk.org (robert engels)
Date: Sun, 21 Apr 2024 18:58:33 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v13]
In-Reply-To: <eANUSdz3i5ukud0zOD-RUHzNF1s7Y8Ntga9q8xEIV00=.5bdbba90-0484-496d-815d-35fd5c2ade7e@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <eANUSdz3i5ukud0zOD-RUHzNF1s7Y8Ntga9q8xEIV00=.5bdbba90-0484-496d-815d-35fd5c2ade7e@github.com>
Message-ID: <yqL3o_Pc7cpQkHS0090RfDiKqKhHGiKw06bVcaOuxN8=.ae8a6965-3d49-4bdd-9988-60888c788a6d@github.com>

On Sun, 21 Apr 2024 18:49:45 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove FixLengthOutputStream changes since not needed

Hi all. I simplified the PR quite a bit by removing the changes to the fixed length output stream by flushing in ServerImpl.

I think all existing "bad" behavior is accounted for and you still have the performance benefit of not sending small packets.

I am still unclear about the concerns regarding "existing code will break" - since if the handler never closes the output stream or the exchange, the connection would be dead and any further requests on it would hang. It seems there are some broken tests cases that exhibit this - which this patch still allows to work - but I don't think the test case behavior could ever be found in the real world.

Let me know if there is anything else I need to do or clarify. I very much appreciate all of the feedback I have received.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2068165518

From duke at openjdk.org  Sun Apr 21 19:03:53 2024
From: duke at openjdk.org (robert engels)
Date: Sun, 21 Apr 2024 19:03:53 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  flush after exchange returns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/e15334b2..30340e58

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=12-13

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

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

From duke at openjdk.org  Mon Apr 22 09:20:41 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 22 Apr 2024 09:20:41 GMT
Subject: RFR: 8309259: Reduce calls to MethodHandles.lookup() in
 jdk.internal.net.http.Stream
Message-ID: <nTejy5MMocs3fL9-fNq5ke0CZqWuqAzJM5YHNTSqXwI=.0a7072b7-927b-47af-8dbc-dbccc5d6b649@github.com>

Please review this simple enhancement that is just reducing the number of times we call the `MethodHandles.lookup()` method, as it can be a bit slow.

TIA

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

Commit messages:
 - Update Copyright
 - reduced number of calls to `MethodHandles.lookup()`

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

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

From clanger at openjdk.org  Mon Apr 22 11:14:48 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 22 Apr 2024 11:14:48 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests
Message-ID: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>

While working in that area I found some potential for cleanup of a few tests.

Most notably:

B5045306.java:
- does not need to run in othervm
- the executor service that it uses should be shut down eventually to free resources

B8291637.java:
- use just one instead of two test VM invocations
KeepAliveTimerThread.java:
call to grp.destroy() at the end is pointless (API is void & deprecated for removal)

Generally:
The deprecated URL constructor is used. It can be switched to the handy URIBuilder
Some more try with resources here and there

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

Commit messages:
 - Copyright year
 - JDK-8330814

Changes: https://git.openjdk.org/jdk/pull/18884/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18884&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330814
  Stats: 277 lines in 5 files changed: 114 ins; 57 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/18884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18884/head:pull/18884

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

From clanger at openjdk.org  Mon Apr 22 11:28:41 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 22 Apr 2024 11:28:41 GMT
Subject: RFR: 8330815: Use pattern matching for instanceof in KeepAliveCache
Message-ID: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>

In su.net.www.http.KeepAliveCache we could use pattern matching for instanceof.

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

Commit messages:
 - JDK-8330815

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

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

From duke at openjdk.org  Mon Apr 22 11:40:39 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 22 Apr 2024 11:40:39 GMT
Subject: RFR: 8306928: Duplicate variable assignement in
 jdk.internal.net.http.AuthenticationFilter#getCredentials
Message-ID: <PxdHTPmJN78PPxHe5Z-ZLbh3rHRdsOuG4K4RytPPTso=.bb3b3f64-797b-49d5-819b-4542d1727af3@github.com>

Picking up a dropped issue please review this simple change.
Passes tier 1-2

TIA

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

Commit messages:
 - Removed duplicate assignment in `getCredentials(...)`

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

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

From clanger at openjdk.org  Mon Apr 22 11:59:29 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 22 Apr 2024 11:59:29 GMT
Subject: RFR: 8306928: Duplicate variable assignement in
 jdk.internal.net.http.AuthenticationFilter#getCredentials
In-Reply-To: <PxdHTPmJN78PPxHe5Z-ZLbh3rHRdsOuG4K4RytPPTso=.bb3b3f64-797b-49d5-819b-4542d1727af3@github.com>
References: <PxdHTPmJN78PPxHe5Z-ZLbh3rHRdsOuG4K4RytPPTso=.bb3b3f64-797b-49d5-819b-4542d1727af3@github.com>
Message-ID: <sLNGT5_HoMm4Yc9de0GzLhl7cqqHgE92ilM4h76NV7k=.cc505e54-3faa-43dd-9b17-6d24ad40effd@github.com>

On Mon, 22 Apr 2024 00:50:51 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Picking up a dropped issue please review this simple change.
> Passes tier 1-2
> 
> TIA

Good and trivial.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18880#pullrequestreview-2014555998

From djelinski at openjdk.org  Mon Apr 22 12:18:30 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 22 Apr 2024 12:18:30 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
Message-ID: <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>

On Sun, 21 Apr 2024 19:03:53 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   flush after exchange returns

src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 851:

> 849:                     uc.doFilter (new HttpExchangeImpl (tx));
> 850:                 }
> 851:                 tx.getResponseBody().flush();

I admire the creativity, but I don't think we can do that here. At this point the stream can be owned by another thread, either because the response was completed and we are now handling another request, or because the user decided to handle the request on a separate thread started from `handle`. In either case, flushing here could lead to concurrency issues like sending the wrong data to the user.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574656121

From duke at openjdk.org  Mon Apr 22 12:36:30 2024
From: duke at openjdk.org (robert engels)
Date: Mon, 22 Apr 2024 12:36:30 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
Message-ID: <A2UF--xLcUT_ykWWpuEIZqYplIxduyn036fknp1hpBQ=.191c5982-3e79-4341-b9d1-05f1d8e23fd8@github.com>

On Mon, 22 Apr 2024 12:16:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   flush after exchange returns
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 851:
> 
>> 849:                     uc.doFilter (new HttpExchangeImpl (tx));
>> 850:                 }
>> 851:                 tx.getResponseBody().flush();
> 
> I admire the creativity, but I don't think we can do that here. At this point the stream can be owned by another thread, either because the response was completed and we are now handling another request, or because the user decided to handle the request on a separate thread started from `handle`. In either case, flushing here could lead to concurrency issues like sending the wrong data to the user.

I am not sure the semantics of a flush on a stream chain that the server owns in subject to corruption in this way - as it should only be sending data waiting to be sent, but in general, you?re correct. 

Based on all of the feedback I don?t think this can be fixed if you want to allow existing incorrect behavior. 

I am under the impression that the stream or exchange must be closed - not doing so is a bad bug. 

I am going to revert this change under that assumption. 

I am not sure where you want to go next. The current implementation leads to really poor network utilization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574679561

From duke at openjdk.org  Mon Apr 22 12:48:57 2024
From: duke at openjdk.org (robert engels)
Date: Mon, 22 Apr 2024 12:48:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v15]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <XaJIEq1BL2CwdGGIgpiPCixcHdxbqkiNyGuT-gfTy4c=.862f35c9-499d-4702-bdcd-3c5e615cd93f@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  Revert "flush after exchange returns"
  
  This reverts commit 30340e58be8ae08205400079b055460ed9ac2e25.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/30340e58..02dc1ad7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=13-14

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

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

From duke at openjdk.org  Mon Apr 22 12:48:57 2024
From: duke at openjdk.org (robert engels)
Date: Mon, 22 Apr 2024 12:48:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
Message-ID: <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>

On Mon, 22 Apr 2024 12:16:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   flush after exchange returns
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 851:
> 
>> 849:                     uc.doFilter (new HttpExchangeImpl (tx));
>> 850:                 }
>> 851:                 tx.getResponseBody().flush();
> 
> I admire the creativity, but I don't think we can do that here. At this point the stream can be owned by another thread, either because the response was completed and we are now handling another request, or because the user decided to handle the request on a separate thread started from `handle`. In either case, flushing here could lead to concurrency issues like sending the wrong data to the user.

I reverted the commit. I think my comment that the TcpNoDelayNotRequired hangs the client connection if the stream is not closed - in the existing JDK code - shows that the concern regarding "existing code" is not valid. I think it only these test cases that exhibit the bad behavior and it was never detected because the tests are run in isolation in a new jvm each time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574694473

From djelinski at openjdk.org  Mon Apr 22 12:48:57 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 22 Apr 2024 12:48:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
Message-ID: <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>

On Mon, 22 Apr 2024 12:44:58 GMT, robert engels <duke at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 851:
>> 
>>> 849:                     uc.doFilter (new HttpExchangeImpl (tx));
>>> 850:                 }
>>> 851:                 tx.getResponseBody().flush();
>> 
>> I admire the creativity, but I don't think we can do that here. At this point the stream can be owned by another thread, either because the response was completed and we are now handling another request, or because the user decided to handle the request on a separate thread started from `handle`. In either case, flushing here could lead to concurrency issues like sending the wrong data to the user.
>
> I reverted the commit. I think my comment that the TcpNoDelayNotRequired hangs the client connection if the stream is not closed - in the existing JDK code - shows that the concern regarding "existing code" is not valid. I think it only these test cases that exhibit the bad behavior and it was never detected because the tests are run in isolation in a new jvm each time.

We don't want to allow it; we want to fix the broken tests, and add a release note so that the users know how to recognize that their code is broken and know how to fix it. 

This should be fine in a new JDK version, where the users are expected to invest some effort in upgrading. Do you plan to backport this change to older releases? If you do, it would make sense to add a system property to revert to the old (slow) behavior. This would allow the users to use the updated version without recompiling their code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574694547

From duke at openjdk.org  Mon Apr 22 12:53:34 2024
From: duke at openjdk.org (robert engels)
Date: Mon, 22 Apr 2024 12:53:34 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
Message-ID: <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>

On Mon, 22 Apr 2024 12:45:01 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> I reverted the commit. I think my comment that the TcpNoDelayNotRequired hangs the client connection if the stream is not closed - in the existing JDK code - shows that the concern regarding "existing code" is not valid. I think it only these test cases that exhibit the bad behavior and it was never detected because the tests are run in isolation in a new jvm each time.
>
> We don't want to allow it; we want to fix the broken tests, and add a release note so that the users know how to recognize that their code is broken and know how to fix it. 
> 
> This should be fine in a new JDK version, where the users are expected to invest some effort in upgrading. Do you plan to backport this change to older releases? If you do, it would make sense to add a system property to revert to the old (slow) behavior. This would allow the users to use the updated version without recompiling their code.

also, I reviewed the semantics of the buffered output stream. It is fully synchronized, so flushing here is fine and cannot corrupt the data to the client. But still, I don't think it is needed as it doesn't really solve anything if the api conditions are more clearly specified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574702437

From duke at openjdk.org  Mon Apr 22 13:08:30 2024
From: duke at openjdk.org (robert engels)
Date: Mon, 22 Apr 2024 13:08:30 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
Message-ID: <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>

On Mon, 22 Apr 2024 12:50:31 GMT, robert engels <duke at openjdk.org> wrote:

>> We don't want to allow it; we want to fix the broken tests, and add a release note so that the users know how to recognize that their code is broken and know how to fix it. 
>> 
>> This should be fine in a new JDK version, where the users are expected to invest some effort in upgrading. Do you plan to backport this change to older releases? If you do, it would make sense to add a system property to revert to the old (slow) behavior. This would allow the users to use the updated version without recompiling their code.
>
> also, I reviewed the semantics of the buffered output stream. It is fully synchronized, so flushing here is fine and cannot corrupt the data to the client. But still, I don't think it is needed as it doesn't really solve anything if the api conditions are more clearly specified.

> We don't want to allow it; we want to fix the broken tests, and add a release note so that the users know how to recognize that their code is broken and know how to fix it.
> 
> This should be fine in a new JDK version, where the users are expected to invest some effort in upgrading. Do you plan to backport this change to older releases? If you do, it would make sense to add a system property to revert to the old (slow) behavior. This would allow the users to use the updated version without recompiling their code.

Hi Daniel. I think there is still some disconnect - I apologize for not being clear. I don't think there will be anything to fix even if back-ported. The only thing to do would be to inform the users they no longer needs to add the 'no delay' option to achieve better network performance. Any existing client code must be closing the stream or exchange - or the code would not work - the clients would hang.

The only problem with the existing JDk impl is that there is very slow performance when doing so. This PR fixes the performance issue - it doesn't change the semantics of the communication. 

The only reason that a few test cases are breaking with this PR is that they are written incorrectly - but it was never discovered because it was launching the test in a new jvm and only performing a single call.

At least that is the way I see it - but there's been a lot of discussion so maybe I've missed something.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574727045

From dfuchs at openjdk.org  Mon Apr 22 14:14:36 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 Apr 2024 14:14:36 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
Message-ID: <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>

On Mon, 22 Apr 2024 13:05:31 GMT, robert engels <duke at openjdk.org> wrote:

>> also, I reviewed the semantics of the buffered output stream. It is fully synchronized, so flushing here is fine and cannot corrupt the data to the client. But still, I don't think it is needed as it doesn't really solve anything if the api conditions are more clearly specified.
>
>> We don't want to allow it; we want to fix the broken tests, and add a release note so that the users know how to recognize that their code is broken and know how to fix it.
>> 
>> This should be fine in a new JDK version, where the users are expected to invest some effort in upgrading. Do you plan to backport this change to older releases? If you do, it would make sense to add a system property to revert to the old (slow) behavior. This would allow the users to use the updated version without recompiling their code.
> 
> Hi Daniel. I think there is still some disconnect - I apologize for not being clear. I don't think there will be anything to fix even if back-ported. The only thing to do would be to inform the users they no longer needs to add the 'no delay' option to achieve better network performance. Any existing client code must be closing the stream or exchange - or the code would not work - the clients would hang.
> 
> The only problem with the existing JDk impl is that there is very slow performance when doing so. This PR fixes the performance issue - it doesn't change the semantics of the communication. 
> 
> The only reason that a few test cases are breaking with this PR is that they are written incorrectly - but it was never discovered because it was launching the test in a new jvm and only performing a single call.
> 
> At least that is the way I see it - but there's been a lot of discussion so maybe I've missed something.

I can see that a bad handler could call `sendResponse(500, 0);` instead of `sendResponse(500, -1)`, and forget to close the body output stream or the exchange.  A client might just not read the body if it receives 500. Before the fix, the server will flush the headers and the client will receive them and everything would work. After the fix, the headers will not be flushed (as a chunked body is expected), and everything will hang (or eventually timeout).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574825398

From duke at openjdk.org  Mon Apr 22 14:42:30 2024
From: duke at openjdk.org (robert engels)
Date: Mon, 22 Apr 2024 14:42:30 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
Message-ID: <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>

On Mon, 22 Apr 2024 14:10:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> We don't want to allow it; we want to fix the broken tests, and add a release note so that the users know how to recognize that their code is broken and know how to fix it.
>>> 
>>> This should be fine in a new JDK version, where the users are expected to invest some effort in upgrading. Do you plan to backport this change to older releases? If you do, it would make sense to add a system property to revert to the old (slow) behavior. This would allow the users to use the updated version without recompiling their code.
>> 
>> Hi Daniel. I think there is still some disconnect - I apologize for not being clear. I don't think there will be anything to fix even if back-ported. The only thing to do would be to inform the users they no longer needs to add the 'no delay' option to achieve better network performance. Any existing client code must be closing the stream or exchange - or the code would not work - the clients would hang.
>> 
>> The only problem with the existing JDk impl is that there is very slow performance when doing so. This PR fixes the performance issue - it doesn't change the semantics of the communication. 
>> 
>> The only reason that a few test cases are breaking with this PR is that they are written incorrectly - but it was never discovered because it was launching the test in a new jvm and only performing a single call.
>> 
>> At least that is the way I see it - but there's been a lot of discussion so maybe I've missed something.
>
> I can see that a bad handler could call `sendResponse(500, 0);` instead of `sendResponse(500, -1)`, and forget to close the body output stream or the exchange.  A client might just not read the body if it receives 500. Before the fix, the server will flush the headers and the client will receive them and everything would work. After the fix, the headers will not be flushed (as a chunked body is expected), and everything will hang (or eventually timeout).

Prior to this change, If the handler does not close the body output stream or exchange, then yes, the client will see those headers but if it tries to send another request - which will reuse the same connection by default in HttpClient - the server will never see it - hanging the client.

The server must see a 'write finished' event in order to properly prepare the connection for the next request.

As I pointed out, you can change the TcpNoDelayNotRequired test and comment out the close, and run it on JDK 11 for instance - and the test will fail - it will hang leading to a timeout - even if tcp nodelay is turned on.

Which leads to my contention there can't be existing code like this in the wild.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574876220

From dfuchs at openjdk.org  Mon Apr 22 14:54:29 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 Apr 2024 14:54:29 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
Message-ID: <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>

On Mon, 22 Apr 2024 14:40:02 GMT, robert engels <duke at openjdk.org> wrote:

>> I can see that a bad handler could call `sendResponse(500, 0);` instead of `sendResponse(500, -1)`, and forget to close the body output stream or the exchange.  A client might just not read the body if it receives 500. Before the fix, the server will flush the headers and the client will receive them and everything would work. After the fix, the headers will not be flushed (as a chunked body is expected), and everything will hang (or eventually timeout).
>
> Prior to this change, If the handler does not close the body output stream or exchange, then yes, the client will see those headers but if it tries to send another request - which will reuse the same connection by default in HttpClient - the server will never see it - hanging the client.
> 
> The server must see a 'write finished' event in order to properly prepare the connection for the next request.
> 
> As I pointed out, you can change the TcpNoDelayNotRequired test and comment out the close, and run it on JDK 11 for instance - and the test will fail - it will hang leading to a timeout - even if tcp nodelay is turned on.
> 
> Which leads to my contention there can't be existing code like this in the wild.

Just to be clear - I agree with Daniel that the line 851 should be removed. I was just speculating about the possible backward compatibility issues of *not* flushing the stream after writing the headers. We saw some test failures, and we all agreed that these test started to fail because the handler was badly implemented. I'm just speculating here about the possible existence of such handlers in the wild. Passing 0 when intending to pass -1 to `sendResponseHeaders` is a common mistake that can go unnoticed if the body output stream or exchange are properly closed. If the exchange or body output stream is not properly close, it could go unnoticed as long as the client doesn't attempt to read the body and doesn't reuse the connection.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574895460

From duke at openjdk.org  Mon Apr 22 15:25:29 2024
From: duke at openjdk.org (robert engels)
Date: Mon, 22 Apr 2024 15:25:29 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
Message-ID: <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>

On Mon, 22 Apr 2024 14:51:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Prior to this change, If the handler does not close the body output stream or exchange, then yes, the client will see those headers but if it tries to send another request - which will reuse the same connection by default in HttpClient - the server will never see it - hanging the client.
>> 
>> The server must see a 'write finished' event in order to properly prepare the connection for the next request.
>> 
>> As I pointed out, you can change the TcpNoDelayNotRequired test and comment out the close, and run it on JDK 11 for instance - and the test will fail - it will hang leading to a timeout - even if tcp nodelay is turned on.
>> 
>> Which leads to my contention there can't be existing code like this in the wild.
>
> Just to be clear - I agree with Daniel that the line 851 should be removed. I was just speculating about the possible backward compatibility issues of *not* flushing the stream after writing the headers. We saw some test failures, and we all agreed that these test started to fail because the handler was badly implemented. I'm just speculating here about the possible existence of such handlers in the wild. Passing 0 when intending to pass -1 to `sendResponseHeaders` is a common mistake that can go unnoticed if the body output stream or exchange are properly closed. If the exchange or body output stream is not properly close, it could go unnoticed as long as the client doesn't attempt to read the body and doesn't reuse the connection.

I already removed that line - it is not necessary (but I also think it is fine - there is no race/corruption possible, and it would restore the previous behavior of always sending the headers).

To your point though, I think I must not be stating this very clearly, I'll try again.

If the code was making this "common mistake" - the code would never have worked before - the connection would hung for any future requests. The handler MUST close the stream/exchange if it states it will be returning content (length >=0) or that connection is dead.

Returning a 500 error does not force a close of the connection - the receiving client would expect to be able to send another request - at which point the server would never see it. The only time this would work is if the handler added the 'Connection: close' header and the client dropped the connection - that would allow the server to detect the dead connection and clean-up.

If it used (500,0) that is a chunked response, so if the handler never closes it, the data will not be sent - the chunked handler already buffers - and the client will hang waiting for data never to arrive.

So if there is code in the wild using sendResponse(500,0) and not closing the connection, then their server is already badly broken. It simply will not work.

You can change the TcpNoDelayNotRequired test to do this, and run it under JDK 11, and the test will fail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574949616

From dfuchs at openjdk.org  Mon Apr 22 15:42:29 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 Apr 2024 15:42:29 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
Message-ID: <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>

On Mon, 22 Apr 2024 15:23:01 GMT, robert engels <duke at openjdk.org> wrote:

>> Just to be clear - I agree with Daniel that the line 851 should be removed. I was just speculating about the possible backward compatibility issues of *not* flushing the stream after writing the headers. We saw some test failures, and we all agreed that these test started to fail because the handler was badly implemented. I'm just speculating here about the possible existence of such handlers in the wild. Passing 0 when intending to pass -1 to `sendResponseHeaders` is a common mistake that can go unnoticed if the body output stream or exchange are properly closed. If the exchange or body output stream is not properly close, it could go unnoticed as long as the client doesn't attempt to read the body and doesn't reuse the connection.
>
> I already removed that line - it is not necessary (but I also think it is fine - there is no race/corruption possible, and it would restore the previous behavior of always sending the headers).
> 
> To your point though, I think I must not be stating this very clearly, I'll try again.
> 
> If the code was making this "common mistake" - the code would never have worked before - the connection would hung for any future requests. The handler MUST close the stream/exchange if it states it will be returning content (length >=0) or that connection is dead.
> 
> Returning a 500 error does not force a close of the connection - the receiving client would expect to be able to send another request - at which point the server would never see it. The only time this would work is if the handler added the 'Connection: close' header and the client dropped the connection - that would allow the server to detect the dead connection and clean-up.
> 
> If it used (500,0) that is a chunked response, so if the handler never closes it, the data will not be sent - the chunked handler already buffers - and the client will hang waiting for data never to arrive.
> 
> So if there is code in the wild using sendResponse(500,0) and not closing the connection, then their server is already badly broken. It simply will not work.
> 
> You can change the TcpNoDelayNotRequired test to do this, and run it under JDK 11, and the test will fail.

I understand what you're saying - but you would be surprised of what you could encounter in the wild. In any case, it's not an issue if no backport is intended.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1574976067

From duke at openjdk.org  Mon Apr 22 16:32:30 2024
From: duke at openjdk.org (robert engels)
Date: Mon, 22 Apr 2024 16:32:30 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
 <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
Message-ID: <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>

On Mon, 22 Apr 2024 15:39:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I already removed that line - it is not necessary (but I also think it is fine - there is no race/corruption possible, and it would restore the previous behavior of always sending the headers).
>> 
>> To your point though, I think I must not be stating this very clearly, I'll try again.
>> 
>> If the code was making this "common mistake" - the code would never have worked before - the connection would hung for any future requests. The handler MUST close the stream/exchange if it states it will be returning content (length >=0) or that connection is dead.
>> 
>> Returning a 500 error does not force a close of the connection - the receiving client would expect to be able to send another request - at which point the server would never see it. The only time this would work is if the handler added the 'Connection: close' header and the client dropped the connection - that would allow the server to detect the dead connection and clean-up.
>> 
>> If it used (500,0) that is a chunked response, so if the handler never closes it, the data will not be sent - the chunked handler already buffers - and the client will hang waiting for data never to arrive.
>> 
>> So if there is code in the wild using sendResponse(500,0) and not closing the connection, then their server is already badly broken. It simply will not work.
>> 
>> You can change the TcpNoDelayNotRequired test to do this, and run it under JDK 11, and the test will fail.
>
> I understand what you're saying - but you would be surprised of what you could encounter in the wild. In any case, it's not an issue if no backport is intended.

If I write a test case "test multiple requests without closing" - and add that test case to earlier JDK versions, it will fail every time - with no setting that would allow it to work.

So trying to protect earlier bad code that couldn't possibly have worked doesn't seem right to me. I am fairly certain that the only existing code that will break are the incorrect tests cases that exist in the JDK. There can be no existing handlers in the wild that will break with these changes.

I feel like I am taking up too much of your time with these discussions.  I was only trying to fix the jdk version for others (using the knowledge I gained in the robaho impl).

A back-ported change could guard the changes - they are fairly trivial - but I'll let others undertake that.

The api [docs](https://docs.oracle.com/en/java/javase/11/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpExchange.html) already state:

> When the response body has been written, the stream must be closed to terminate the exchange.

so I don't think back-porting as is an issue. I have never encountered an impl of an api that tries to work around improper use of the api.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1575047161

From jjg at openjdk.org  Mon Apr 22 17:41:28 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 22 Apr 2024 17:41:28 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
 <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
Message-ID: <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>

On Fri, 19 Apr 2024 19:29:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > We do not have an overall style guide. The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.
> 
> That's what I do.
> 
> I saw either style used in JDK. Yet I didn't check which style is more common? to decide which style I should use when creating new files with javadoc comments. [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) doesn't have a blank line between the javadoc comment and class declaration; nor do javadoc comments for fields and methods.

The document [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) is depressingly obsolete, as indicated by this text towards the end:

>Footnotes
>
> [1] At Java Software, we use @version for the SCCS version. See "man sccs-get" for details. The consensus seems to be the following:

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2070379608

From aivanov at openjdk.org  Mon Apr 22 17:56:28 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Apr 2024 17:56:28 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
 <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
 <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>
Message-ID: <00Gbr5mrPAEDVFsF8tkDSasn1qIk1OftDX9nvExC9mg=.c3313acd-0939-4af8-9c36-e9c8b7e6e518@github.com>

On Mon, 22 Apr 2024 17:38:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The document [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) is depressingly obsolete, as indicated by this text towards the end:

I know. Yet there's nothing newer, is there?

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2070433346

From djelinski at openjdk.org  Mon Apr 22 18:54:29 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 22 Apr 2024 18:54:29 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
 <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
 <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>
Message-ID: <YpvmCHWo1csew9zv81wH2lK4_C5bgDjzOcDqeZZLoEg=.c88b3070-9f3f-4093-a6a7-92ce954bda5f@github.com>

On Mon, 22 Apr 2024 16:30:01 GMT, robert engels <duke at openjdk.org> wrote:

>> I understand what you're saying - but you would be surprised of what you could encounter in the wild. In any case, it's not an issue if no backport is intended.
>
> If I write a test case "test multiple requests without closing" - and add that test case to earlier JDK versions, it will fail every time - with no setting that would allow it to work.
> 
> So trying to protect earlier bad code that couldn't possibly have worked doesn't seem right to me. I am fairly certain that the only existing code that will break are the incorrect tests cases that exist in the JDK. There can be no existing handlers in the wild that will break with these changes.
> 
> I feel like I am taking up too much of your time with these discussions.  I was only trying to fix the jdk version for others (using the knowledge I gained in the robaho impl).
> 
> A back-ported change could guard the changes - they are fairly trivial - but I'll let others undertake that.
> 
> The api [docs](https://docs.oracle.com/en/java/javase/11/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpExchange.html) already state:
> 
>> When the response body has been written, the stream must be closed to terminate the exchange.
> 
> so I don't think back-porting as is an issue. I have never encountered an impl of an api that tries to work around improper use of the api.

Let me add some background:
https://www.hyrumslaw.com/
https://xkcd.com/1172/
https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility

Every time we make an observable behavioral change, we need to decide if we can make it without any additional documentation, or if a release note or a CSR is necessary.

In this case we have 2 failing tests with that change. As you correctly pointed out, these tests are failing because of bugs in their implementation. But then, these tests show that the change is already impacting existing code. With that in mind, a release note will be necessary. This is not for us; this is for the users who may upgrade to the latest version and find that their tests are failing.

The product changes are fine in their current form. Could you fix the failing tests?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1575225497

From duke at openjdk.org  Mon Apr 22 22:10:30 2024
From: duke at openjdk.org (robert engels)
Date: Mon, 22 Apr 2024 22:10:30 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <YpvmCHWo1csew9zv81wH2lK4_C5bgDjzOcDqeZZLoEg=.c88b3070-9f3f-4093-a6a7-92ce954bda5f@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
 <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
 <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>
 <YpvmCHWo1csew9zv81wH2lK4_C5bgDjzOcDqeZZLoEg=.c88b3070-9f3f-4093-a6a7-92ce954bda5f@github.com>
Message-ID: <taVZalykq-yOezCpnKDt7lZbFd7BM3WqHNpOVDCee9k=.d7864035-974f-4018-bb18-bb21cafe6f9c@github.com>

On Mon, 22 Apr 2024 18:52:00 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> If I write a test case "test multiple requests without closing" - and add that test case to earlier JDK versions, it will fail every time - with no setting that would allow it to work.
>> 
>> So trying to protect earlier bad code that couldn't possibly have worked doesn't seem right to me. I am fairly certain that the only existing code that will break are the incorrect tests cases that exist in the JDK. There can be no existing handlers in the wild that will break with these changes.
>> 
>> I feel like I am taking up too much of your time with these discussions.  I was only trying to fix the jdk version for others (using the knowledge I gained in the robaho impl).
>> 
>> A back-ported change could guard the changes - they are fairly trivial - but I'll let others undertake that.
>> 
>> The api [docs](https://docs.oracle.com/en/java/javase/11/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpExchange.html) already state:
>> 
>>> When the response body has been written, the stream must be closed to terminate the exchange.
>> 
>> so I don't think back-porting as is an issue. I have never encountered an impl of an api that tries to work around improper use of the api.
>
> Let me add some background:
> https://www.hyrumslaw.com/
> https://xkcd.com/1172/
> https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility
> 
> Every time we make an observable behavioral change, we need to decide if we can make it without any additional documentation, or if a release note or a CSR is necessary.
> 
> In this case we have 2 failing tests with that change. As you correctly pointed out, these tests are failing because of bugs in their implementation. But then, these tests show that the change is already impacting existing code. With that in mind, a release note will be necessary. This is not for us; this is for the users who may upgrade to the latest version and find that their tests are failing.
> 
> The product changes are fine in their current form. Could you fix the failing tests?

I?ll update the PR to fix the tests. I understand the need for backwards compatibility- it?s one of the prime reasons Java is awesome - but in this situation the tests are validating that 1+1=3 and I don?t think anyone wants that. 

You?re assuming that changing the validation of the test cases means the potential for breaking code - as I?ve stated before I don?t think that?s possible in this case - because the test cases were never verifying code you would see in a production system.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1575406288

From darcy at openjdk.org  Tue Apr 23 02:29:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 Apr 2024 02:29:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <S6J882dLjdmFPXHVRQm77lTy73k9FIGC_-kDiBLael4=.0191a2c7-4f55-41b8-a389-e238c8b63f84@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2016121831

From iris at openjdk.org  Tue Apr 23 02:35:31 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 23 Apr 2024 02:35:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <QuHZeejL48phB87kuWRWzlunHQ6KGRSVvyNNCVjTFzk=.1edeb3eb-3cd6-4ed3-a0b5-1a39937dd7e3@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2016126206

From jpai at openjdk.org  Tue Apr 23 05:57:33 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 23 Apr 2024 05:57:33 GMT
Subject: RFR: 8306928: Duplicate variable assignement in
 jdk.internal.net.http.AuthenticationFilter#getCredentials
In-Reply-To: <PxdHTPmJN78PPxHe5Z-ZLbh3rHRdsOuG4K4RytPPTso=.bb3b3f64-797b-49d5-819b-4542d1727af3@github.com>
References: <PxdHTPmJN78PPxHe5Z-ZLbh3rHRdsOuG4K4RytPPTso=.bb3b3f64-797b-49d5-819b-4542d1727af3@github.com>
Message-ID: <0DNK0er99986Y2U7gQcq0L93Y8sdRy0S7xgtS5d_ZGc=.3f4860eb-bb5d-4f27-929b-c850ba5ff477@github.com>

On Mon, 22 Apr 2024 00:50:51 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Picking up a dropped issue please review this simple change.
> Passes tier 1-2
> 
> TIA

Hello Nizar, the change looks good to me. The tests for java/net/httpclient area reside in tier2 and I see that you have already run those.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18880#pullrequestreview-2016294671

From duke at openjdk.org  Tue Apr 23 05:57:33 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 23 Apr 2024 05:57:33 GMT
Subject: Integrated: 8306928: Duplicate variable assignement in
 jdk.internal.net.http.AuthenticationFilter#getCredentials
In-Reply-To: <PxdHTPmJN78PPxHe5Z-ZLbh3rHRdsOuG4K4RytPPTso=.bb3b3f64-797b-49d5-819b-4542d1727af3@github.com>
References: <PxdHTPmJN78PPxHe5Z-ZLbh3rHRdsOuG4K4RytPPTso=.bb3b3f64-797b-49d5-819b-4542d1727af3@github.com>
Message-ID: <HJY4kuEwe_6KN-SY9NJaswwGjL9KgxszFo7kT5kAZOw=.2927942f-5acb-4588-8901-8f102f3b75bc@github.com>

On Mon, 22 Apr 2024 00:50:51 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Picking up a dropped issue please review this simple change.
> Passes tier 1-2
> 
> TIA

This pull request has now been integrated.

Changeset: 550a1386
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/550a1386222462cca10f79a66453d2f08431dfdf
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8306928: Duplicate variable assignement in jdk.internal.net.http.AuthenticationFilter#getCredentials

Reviewed-by: clanger, jpai

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

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

From pminborg at openjdk.org  Tue Apr 23 06:27:27 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 23 Apr 2024 06:27:27 GMT
Subject: RFR: 8309259: Reduce calls to MethodHandles.lookup() in
 jdk.internal.net.http.Stream
In-Reply-To: <nTejy5MMocs3fL9-fNq5ke0CZqWuqAzJM5YHNTSqXwI=.0a7072b7-927b-47af-8dbc-dbccc5d6b649@github.com>
References: <nTejy5MMocs3fL9-fNq5ke0CZqWuqAzJM5YHNTSqXwI=.0a7072b7-927b-47af-8dbc-dbccc5d6b649@github.com>
Message-ID: <BeVuFe4NEWBzA2jGf-hR9ipH9Rnn0dsbzJXYSmwe_V8=.8fd4b1c6-665d-4fe8-adfa-7e7c38d9273a@github.com>

On Fri, 19 Apr 2024 12:02:43 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this simple enhancement that is just reducing the number of times we call the `MethodHandles.lookup()` method, as it can be a bit slow.
> Passes tier 1-3
> 
> TIA

Nice cleanup. LGTM.

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18862#pullrequestreview-2016337671

From jpai at openjdk.org  Tue Apr 23 07:18:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 23 Apr 2024 07:18:48 GMT
Subject: RFR: 8309259: Reduce calls to MethodHandles.lookup() in
 jdk.internal.net.http.Stream
In-Reply-To: <nTejy5MMocs3fL9-fNq5ke0CZqWuqAzJM5YHNTSqXwI=.0a7072b7-927b-47af-8dbc-dbccc5d6b649@github.com>
References: <nTejy5MMocs3fL9-fNq5ke0CZqWuqAzJM5YHNTSqXwI=.0a7072b7-927b-47af-8dbc-dbccc5d6b649@github.com>
Message-ID: <ounw4Li9v1hsWe5C29NPa52hYsYQFpdPscDTZgBSBS4=.2a2e0a5f-f249-45e0-beec-c02383057743@github.com>

On Fri, 19 Apr 2024 12:02:43 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this simple enhancement that is just reducing the number of times we call the `MethodHandles.lookup()` method, as it can be a bit slow.
> Passes tier 1-3
> 
> TIA

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18862#pullrequestreview-2016444787

From duke at openjdk.org  Tue Apr 23 07:21:43 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 23 Apr 2024 07:21:43 GMT
Subject: Integrated: 8309259: Reduce calls to MethodHandles.lookup() in
 jdk.internal.net.http.Stream
In-Reply-To: <nTejy5MMocs3fL9-fNq5ke0CZqWuqAzJM5YHNTSqXwI=.0a7072b7-927b-47af-8dbc-dbccc5d6b649@github.com>
References: <nTejy5MMocs3fL9-fNq5ke0CZqWuqAzJM5YHNTSqXwI=.0a7072b7-927b-47af-8dbc-dbccc5d6b649@github.com>
Message-ID: <UPEgzQ0Pyx4Uyax4E1pILNyEkmGaBMQolbR-b_LRess=.a178e9d3-4549-445f-a38c-d0e02be0f0a6@github.com>

On Fri, 19 Apr 2024 12:02:43 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> Please review this simple enhancement that is just reducing the number of times we call the `MethodHandles.lookup()` method, as it can be a bit slow.
> Passes tier 1-3
> 
> TIA

This pull request has now been integrated.

Changeset: 89610770
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/896107705615a3b9363b7a0a3e6703b20fedef70
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8309259: Reduce calls to MethodHandles.lookup() in jdk.internal.net.http.Stream

Reviewed-by: pminborg, jpai

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

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

From jpai at openjdk.org  Tue Apr 23 07:23:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 23 Apr 2024 07:23:30 GMT
Subject: RFR: 8330815: Use pattern matching for instanceof in
 KeepAliveCache
In-Reply-To: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>
References: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>
Message-ID: <-eyUrFmg8iJOhR7ACOBBiR_7IZ8t7adsRp7YktpcAVY=.dd9085af-61ae-440d-8aa5-f9a09d532c69@github.com>

On Mon, 22 Apr 2024 11:23:59 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> In su.net.www.http.KeepAliveCache we could use pattern matching for instanceof.

Hello Christoph, this cleanup change looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18885#pullrequestreview-2016454353

From aturbanov at openjdk.org  Tue Apr 23 08:10:29 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 23 Apr 2024 08:10:29 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests
In-Reply-To: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
Message-ID: <SQcrP7fA34i-9ncdfJ64xbF_HBbcXj_LRxEqNbLhe8g=.4d72a701-345c-47b4-a806-21ae2110b929@github.com>

On Mon, 22 Apr 2024 11:06:57 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> While working in that area I found some potential for cleanup of a few tests.
> 
> Most notably:
> 
> B5045306.java:
> - does not need to run in othervm
> - the executor service that it uses should be shut down eventually to free resources
> 
> B8291637.java:
> - use just one instead of two test VM invocations
> KeepAliveTimerThread.java:
> call to grp.destroy() at the end is pointless (API is void & deprecated for removal)
> 
> Generally:
> The deprecated URL constructor is used. It can be switched to the handy URIBuilder
> Some more try with resources here and there

test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 143:

> 141:             ThreadInfo[] threadInfo = threadMXBean.getThreadInfo(threads);
> 142:             for (int i=0; i<threadInfo.length; i++) {
> 143:                 if (threadInfo[i].getThreadName().equals("Keep-Alive-SocketCleaner"))  {

Suggestion:

                if (threadInfo[i].getThreadName().equals("Keep-Alive-SocketCleaner")) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1575829443

From djelinski at openjdk.org  Tue Apr 23 08:32:30 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 23 Apr 2024 08:32:30 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v15]
In-Reply-To: <XaJIEq1BL2CwdGGIgpiPCixcHdxbqkiNyGuT-gfTy4c=.862f35c9-499d-4702-bdcd-3c5e615cd93f@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <XaJIEq1BL2CwdGGIgpiPCixcHdxbqkiNyGuT-gfTy4c=.862f35c9-499d-4702-bdcd-3c5e615cd93f@github.com>
Message-ID: <fNNKu6QQiXiLM0MfIkSKm4u2-908FxGRGY1tba3nCWk=.d3c4bc51-410f-45ea-8bc5-93b9abe30562@github.com>

On Mon, 22 Apr 2024 12:48:57 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "flush after exchange returns"
>   
>   This reverts commit 30340e58be8ae08205400079b055460ed9ac2e25.

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 83:

> 81:         long time = System.currentTimeMillis()-start;
> 82:         System.out.println("time "+time);
> 83:         if(time>5000) throw new IllegalStateException("took too long");

Please drop this line. The timeout will be handled by jtreg, and this line makes the test fail on some of our slower CI machines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1575861044

From clanger at openjdk.org  Tue Apr 23 08:39:56 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 23 Apr 2024 08:39:56 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v2]
In-Reply-To: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
Message-ID: <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>

> While working in that area I found some potential for cleanup of a few tests.
> 
> Most notably:
> 
> B5045306.java:
> - does not need to run in othervm
> - the executor service that it uses should be shut down eventually to free resources
> 
> B8291637.java:
> - use just one instead of two test VM invocations
> KeepAliveTimerThread.java:
> call to grp.destroy() at the end is pointless (API is void & deprecated for removal)
> 
> Generally:
> The deprecated URL constructor is used. It can be switched to the handy URIBuilder
> Some more try with resources here and there

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18884/files
  - new: https://git.openjdk.org/jdk/pull/18884/files/ab993202..92bddff8

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

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

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

From djelinski at openjdk.org  Tue Apr 23 08:56:27 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 23 Apr 2024 08:56:27 GMT
Subject: RFR: 8330815: Use pattern matching for instanceof in
 KeepAliveCache
In-Reply-To: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>
References: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>
Message-ID: <v8n8zzLSX1NXEo-8QtY4-pmcFrnmKGlXLc-9vaSjpQk=.7e86bcc9-48bb-46aa-8cdf-d5bd535118de@github.com>

On Mon, 22 Apr 2024 11:23:59 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> In su.net.www.http.KeepAliveCache we could use pattern matching for instanceof.

I'd prefer this instead:

        if (!(obj instanceof KeepAliveKey kae))
            return false;

because it's more awesome :) but what you propose looks good too.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18885#pullrequestreview-2016651386

From clanger at openjdk.org  Tue Apr 23 10:49:42 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 23 Apr 2024 10:49:42 GMT
Subject: RFR: 8330815: Use pattern matching for instanceof in
 KeepAliveCache [v2]
In-Reply-To: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>
References: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>
Message-ID: <XE-ij63UWepnIyDha8VfqeGUwUgd8QN0SIbqm0E4W8g=.bf1942fe-f915-4baf-8cb4-1d035d7667ea@github.com>

> In su.net.www.http.KeepAliveCache we could use pattern matching for instanceof.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Add Daniel's more awesome suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18885/files
  - new: https://git.openjdk.org/jdk/pull/18885/files/a7129acd..5c9f5cc9

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

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

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

From clanger at openjdk.org  Tue Apr 23 10:49:42 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 23 Apr 2024 10:49:42 GMT
Subject: RFR: 8330815: Use pattern matching for instanceof in
 KeepAliveCache [v2]
In-Reply-To: <v8n8zzLSX1NXEo-8QtY4-pmcFrnmKGlXLc-9vaSjpQk=.7e86bcc9-48bb-46aa-8cdf-d5bd535118de@github.com>
References: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>
 <v8n8zzLSX1NXEo-8QtY4-pmcFrnmKGlXLc-9vaSjpQk=.7e86bcc9-48bb-46aa-8cdf-d5bd535118de@github.com>
Message-ID: <DPZqudPJfFqpgnxoIELuMqE0ELdHfJVlQ6t6SDlnDnM=.6750b341-290b-4838-826a-b1ec4f2e7514@github.com>

On Tue, 23 Apr 2024 08:54:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd prefer this instead:
> 
> ```
>         if (!(obj instanceof KeepAliveKey kae))
>             return false;
> ```
> 
> because it's more awesome :) but what you propose looks good too.

Yes, you're right. Adapted. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18885#issuecomment-2071983640

From djelinski at openjdk.org  Tue Apr 23 11:13:28 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 23 Apr 2024 11:13:28 GMT
Subject: RFR: 8330815: Use pattern matching for instanceof in
 KeepAliveCache [v2]
In-Reply-To: <XE-ij63UWepnIyDha8VfqeGUwUgd8QN0SIbqm0E4W8g=.bf1942fe-f915-4baf-8cb4-1d035d7667ea@github.com>
References: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>
 <XE-ij63UWepnIyDha8VfqeGUwUgd8QN0SIbqm0E4W8g=.bf1942fe-f915-4baf-8cb4-1d035d7667ea@github.com>
Message-ID: <GzyF4BGrQOm1SBeDnoTSUekDcmJZ9euhJiZmY4RcLLw=.b4ccf72b-3d17-4c53-8ca7-681b88a87700@github.com>

On Tue, 23 Apr 2024 10:49:42 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> In su.net.www.http.KeepAliveCache we could use pattern matching for instanceof.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Daniel's more awesome suggestion

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18885#pullrequestreview-2016936237

From michaelm at openjdk.org  Tue Apr 23 15:27:29 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 23 Apr 2024 15:27:29 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <taVZalykq-yOezCpnKDt7lZbFd7BM3WqHNpOVDCee9k=.d7864035-974f-4018-bb18-bb21cafe6f9c@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
 <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
 <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>
 <YpvmCHWo1csew9zv81wH2lK4_C5bgDjzOcDqeZZLoEg=.c88b3070-9f3f-4093-a6a7-92ce954bda5f@github.com>
 <taVZalykq-yOezCpnKDt7lZbFd7BM3WqHNpOVDCee9k=.d7864035-974f-4018-bb18-bb21cafe6f9c@github.com>
Message-ID: <uXIBthbqrYPsTQYbWdy8N2jmY3-g4zAf9yZsYQY9pB8=.15ee48f1-6fee-428a-bd57-bc736e25c751@github.com>

On Mon, 22 Apr 2024 22:07:32 GMT, robert engels <duke at openjdk.org> wrote:

>> Let me add some background:
>> https://www.hyrumslaw.com/
>> https://xkcd.com/1172/
>> https://wiki.openjdk.org/display/csr/Kinds+of+Compatibility
>> 
>> Every time we make an observable behavioral change, we need to decide if we can make it without any additional documentation, or if a release note or a CSR is necessary.
>> 
>> In this case we have 2 failing tests with that change. As you correctly pointed out, these tests are failing because of bugs in their implementation. But then, these tests show that the change is already impacting existing code. With that in mind, a release note will be necessary. This is not for us; this is for the users who may upgrade to the latest version and find that their tests are failing.
>> 
>> The product changes are fine in their current form. Could you fix the failing tests?
>
> I?ll update the PR to fix the tests. I understand the need for backwards compatibility- it?s one of the prime reasons Java is awesome - but in this situation the tests are validating that 1+1=3 and I don?t think anyone wants that. 
> 
> You?re assuming that changing the validation of the test cases means the potential for breaking code - as I?ve stated before I don?t think that?s possible in this case - because the test cases were never verifying code you would see in a production system.

If the client was based on HttpURLConnection in Java and if the code was doing HTTP authentication then it's possible it could happen because HTTPURLConnection closes the connection in between each phase of the authentication. It is unfortunate as well that the server side HttpExchange.sendResponseHeaders method's second parameter is quite counter-intuitive in its meaning. It is a common mistake to provide a parameter value of zero (which means use chunked-encoding) when what is intended is probably -1, (meaning no response content).

In any case, we all still accept that the change is worthwhile, and we just need to flag it in the release notes. We also obviously have to fix the tests so they pass. You just need to make sure the exchanges get closed in all handlers defined in those two tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1576456907

From duke at openjdk.org  Tue Apr 23 16:15:50 2024
From: duke at openjdk.org (robert engels)
Date: Tue, 23 Apr 2024 16:15:50 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v16]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <Jh-Avn_c37JfwpiAQDHxJ1vQu7oyueGR6a8Za9CFue0=.e9faf1a8-e2bb-415e-9aa7-e8de753a1cab@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  remove timing check and rely on the test harness timeout

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/02dc1ad7..9660dc0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=14-15

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

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

From duke at openjdk.org  Tue Apr 23 16:15:50 2024
From: duke at openjdk.org (robert engels)
Date: Tue, 23 Apr 2024 16:15:50 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v15]
In-Reply-To: <fNNKu6QQiXiLM0MfIkSKm4u2-908FxGRGY1tba3nCWk=.d3c4bc51-410f-45ea-8bc5-93b9abe30562@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <XaJIEq1BL2CwdGGIgpiPCixcHdxbqkiNyGuT-gfTy4c=.862f35c9-499d-4702-bdcd-3c5e615cd93f@github.com>
 <fNNKu6QQiXiLM0MfIkSKm4u2-908FxGRGY1tba3nCWk=.d3c4bc51-410f-45ea-8bc5-93b9abe30562@github.com>
Message-ID: <QIbl0089eC8Vqnml-Ipp3bamfcEY9toR5phTshsn9U4=.3bea281e-efea-497f-9356-3e3f5f1334b2@github.com>

On Tue, 23 Apr 2024 08:29:41 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "flush after exchange returns"
>>   
>>   This reverts commit 30340e58be8ae08205400079b055460ed9ac2e25.
>
> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 83:
> 
>> 81:         long time = System.currentTimeMillis()-start;
>> 82:         System.out.println("time "+time);
>> 83:         if(time>5000) throw new IllegalStateException("took too long");
> 
> Please drop this line. The timeout will be handled by jtreg, and this line makes the test fail on some of our slower CI machines.

Sorry. It returned when I reverted some changes for a test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1576529549

From duke at openjdk.org  Tue Apr 23 16:21:29 2024
From: duke at openjdk.org (robert engels)
Date: Tue, 23 Apr 2024 16:21:29 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <uXIBthbqrYPsTQYbWdy8N2jmY3-g4zAf9yZsYQY9pB8=.15ee48f1-6fee-428a-bd57-bc736e25c751@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
 <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
 <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>
 <YpvmCHWo1csew9zv81wH2lK4_C5bgDjzOcDqeZZLoEg=.c88b3070-9f3f-4093-a6a7-92ce954bda5f@github.com>
 <taVZalykq-yOezCpnKDt7lZbFd7BM3WqHNpOVDCee9k=.d7864035-974f-4018-bb18-bb21cafe6f9c@github.com>
 <uXIBthbqrYPsTQYbWdy8N2jmY3-g4zAf9yZsYQY9pB8=.15ee48f1-6fee-428a-bd57-bc736e25c751@github.com>
Message-ID: <lHHmwMe1ukpYdHVWdUlv-D976q3a9szgwc_sQT91fTA=.81283681-aad0-468c-9f18-b078314a4d06@github.com>

On Tue, 23 Apr 2024 15:24:52 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I?ll update the PR to fix the tests. I understand the need for backwards compatibility- it?s one of the prime reasons Java is awesome - but in this situation the tests are validating that 1+1=3 and I don?t think anyone wants that. 
>> 
>> You?re assuming that changing the validation of the test cases means the potential for breaking code - as I?ve stated before I don?t think that?s possible in this case - because the test cases were never verifying code you would see in a production system.
>
> If the client was based on HttpURLConnection in Java and if the code was doing HTTP authentication then it's possible it could happen because HTTPURLConnection closes the connection in between each phase of the authentication (in some cases). It is unfortunate as well that the server side HttpExchange.sendResponseHeaders method's second parameter is quite counter-intuitive in its meaning. It is a common mistake to provide a parameter value of zero (which means use chunked-encoding) when what is intended is probably -1, (meaning no response content).
> 
> In any case, we all still accept that the change is worthwhile, and we just need to flag it in the release notes. We also obviously have to fix the tests so they pass. You just need to make sure the exchanges get closed in all handlers defined in those two tests.

If the handler sends headers(code,0) and doesn't close the stream, the connection is dead. If what you are saying is that the old behavior was to send the headers at this point, the client would see it and terminate the connection - that feels like a lot of ifs.

but as I mentioned, adding the flush after the exchange handler chain call is safe and would catch this scenario - even if the handler returns the data synchronously - as the buffered output stream at the top of the stream is fully synchronized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1576537356

From jjg at openjdk.org  Tue Apr 23 18:46:34 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 Apr 2024 18:46:34 GMT
Subject: Integrated: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <Hf-QMEmB4eLr-CA0UEIiWRwxxplcD-ZKUVbOJ44BPsc=.20073ab8-4ece-463c-a4e4-afdba6586f28@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

This pull request has now been integrated.

Changeset: 9cc163a9
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9cc163a999eb8e9597d45b095b642c25071043bd
Stats:     134 lines in 23 files changed: 50 ins; 56 del; 28 mod

8330178: Clean up non-standard use of /** comments in `java.base`

Reviewed-by: darcy, iris, dfuchs, aivanov, naoto

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

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

From duke at openjdk.org  Tue Apr 23 19:10:48 2024
From: duke at openjdk.org (robert engels)
Date: Tue, 23 Apr 2024 19:10:48 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  fix broken test cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/9660dc0c..4060575b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=15-16

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

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

From duke at openjdk.org  Tue Apr 23 19:10:48 2024
From: duke at openjdk.org (robert engels)
Date: Tue, 23 Apr 2024 19:10:48 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <lHHmwMe1ukpYdHVWdUlv-D976q3a9szgwc_sQT91fTA=.81283681-aad0-468c-9f18-b078314a4d06@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
 <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
 <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>
 <YpvmCHWo1csew9zv81wH2lK4_C5bgDjzOcDqeZZLoEg=.c88b3070-9f3f-4093-a6a7-92ce954bda5f@github.com>
 <taVZalykq-yOezCpnKDt7lZbFd7BM3WqHNpOVDCee9k=.d7864035-974f-4018-bb18-bb21cafe6f9c@github.com>
 <uXIBthbqrYPsTQYbWdy8N2jmY3-g4zAf9yZsYQY9pB8=.15ee48f1-6fee-428a-bd57-bc736e25c751@github.com>
 <lHHmwMe1ukpYdHVWdUlv-D976q3a9szgwc_sQT91fTA=.81283681-aad0-468c-9f18-b078314a4d06@github.com>
Message-ID: <lzSz1lU8VJKfhcl1U8RxwpCWdweH22BMVpgLRt_ZaSg=.a286abf9-9bcb-4cb8-8c05-55f82ad0a327@github.com>

On Tue, 23 Apr 2024 16:19:12 GMT, robert engels <duke at openjdk.org> wrote:

>> If the client was based on HttpURLConnection in Java and if the code was doing HTTP authentication then it's possible it could happen because HTTPURLConnection closes the connection in between each phase of the authentication (in some cases). It is unfortunate as well that the server side HttpExchange.sendResponseHeaders method's second parameter is quite counter-intuitive in its meaning. It is a common mistake to provide a parameter value of zero (which means use chunked-encoding) when what is intended is probably -1, (meaning no response content).
>> 
>> In any case, we all still accept that the change is worthwhile, and we just need to flag it in the release notes. We also obviously have to fix the tests so they pass. You just need to make sure the exchanges get closed in all handlers defined in those two tests.
>
> If the handler sends headers(code,0) and doesn't close the stream, the connection is dead. If what you are saying is that the old behavior was to send the headers at this point, the client would see it and terminate the connection - that feels like a lot of ifs.
> 
> but as I mentioned, adding the flush after the exchange handler chain call is safe and would catch this scenario - even if the handler returns the data synchronously - as the buffered output stream at the top of the stream is fully synchronized.

The PR has been updated to fix the tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1576770275

From duke at openjdk.org  Tue Apr 23 19:33:30 2024
From: duke at openjdk.org (robert engels)
Date: Tue, 23 Apr 2024 19:33:30 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <lzSz1lU8VJKfhcl1U8RxwpCWdweH22BMVpgLRt_ZaSg=.a286abf9-9bcb-4cb8-8c05-55f82ad0a327@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
 <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
 <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>
 <YpvmCHWo1csew9zv81wH2lK4_C5bgDjzOcDqeZZLoEg=.c88b3070-9f3f-4093-a6a7-92ce954bda5f@github.com>
 <taVZalykq-yOezCpnKDt7lZbFd7BM3WqHNpOVDCee9k=.d7864035-974f-4018-bb18-bb21cafe6f9c@github.com>
 <uXIBthbqrYPsTQYbWdy8N2jmY3-g4zAf9yZsYQY9pB8=.15ee48f1-6fee-428a-bd57-bc736e25c751@github.com>
 <lHHmwMe1ukpYdHVWdUlv-D976q3a9szgwc_sQT91fTA=.81283681-aad0-468c-9f18-b078314a4d06@github.com>
 <lzSz1lU8VJKfhcl1U8RxwpCWdweH22BMVpgLRt_ZaSg=.a286abf9-9bcb-4cb8-8c05-55f82ad0a327@github.com>
Message-ID: <UaxwDtZq-0uihevw1dGyjs9Anoj0f2gqkD5oy0CO_9A=.e1608fb0-c9f7-425a-916c-0c8ffde693ec@github.com>

On Tue, 23 Apr 2024 19:08:06 GMT, robert engels <duke at openjdk.org> wrote:

>> If the handler sends headers(code,0) and doesn't close the stream, the connection is dead. If what you are saying is that the old behavior was to send the headers at this point, the client would see it and terminate the connection - that feels like a lot of ifs.
>> 
>> but as I mentioned, adding the flush after the exchange handler chain call is safe and would catch this scenario - even if the handler returns the data synchronously - as the buffered output stream at the top of the stream is fully synchronized.
>
> The PR has been updated to fix the tests.

By the way, as an x-Googler I am familiar with Hyrum and have seen the link. I would hope that Googlers would have written api test cases - independent of the implementation - which maybe would have caught the problem here earlier but that might be wishful thinking.

Since the api allows for async handling - validating that an arbitrary handler closes the stream doesn't seem possible other than by testing that the client receives the data it expects, and that the connection does not hang when keep alive with multiple requests is enabled. So I don't think runtime checks could have caught it either.

If someone wrote a handler that relied on the fact that headers were sent "early", and/or that streams were flushed even though the api specification states the handler must close the stream - they would be coding to the sun implementation - and if they lacked access to the source code they would never be able to determine that is what was happening.

The sun tests in this regard are incorrectly testing/expecting behavior that the published api specifically prohibits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1576794566

From jpai at openjdk.org  Wed Apr 24 06:47:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 Apr 2024 06:47:29 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v2]
In-Reply-To: <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
 <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
Message-ID: <M2wmIG6-se4U6YruDNli5mVFgCXkrYs9i8Eg4lSAfRk=.a24122b2-4bdf-4217-85a1-efb4485333c6@github.com>

On Tue, 23 Apr 2024 08:39:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> While working in that area I found some potential for cleanup of a few tests.
>> 
>> Most notably:
>> 
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free resources
>> 
>> B8291637.java:
>> - use just one instead of two test VM invocations
>> KeepAliveTimerThread.java:
>> call to grp.destroy() at the end is pointless (API is void & deprecated for removal)
>> 
>> Generally:
>> The deprecated URL constructor is used. It can be switched to the handy URIBuilder
>> Some more try with resources here and there
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java line 142:

> 140:                 .port(port)
> 141:                 .path("/firstCall")
> 142:                 .toURL();

Hello Christoph, what's the significance of changing the path from `/` to `/firstCall` in this test?

test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java line 148:

> 146:             int c;
> 147:             byte[] buf = new byte[256];
> 148:             while ((c=i.read(buf)) != -1) {

Nit: needs a space before and after the `=`

test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java line 149:

> 147:             byte[] buf = new byte[256];
> 148:             while ((c=i.read(buf)) != -1) {
> 149:                 count+=c;

Same here, needs a space before/after `+=`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1577359424
PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1577360405
PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1577360693

From jpai at openjdk.org  Wed Apr 24 06:50:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 Apr 2024 06:50:28 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v2]
In-Reply-To: <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
 <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
Message-ID: <UJvA_CmhhauBANP5Hyo_QTmY1lA0L-99iQK2uLy0iiY=.6ed4d703-eca7-4ae0-9948-b0d0eb2a5e3f@github.com>

On Tue, 23 Apr 2024 08:39:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> While working in that area I found some potential for cleanup of a few tests.
>> 
>> Most notably:
>> 
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free resources
>> 
>> B8291637.java:
>> - use just one instead of two test VM invocations
>> KeepAliveTimerThread.java:
>> call to grp.destroy() at the end is pointless (API is void & deprecated for removal)
>> 
>> Generally:
>> The deprecated URL constructor is used. It can be switched to the handy URIBuilder
>> Some more try with resources here and there
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 55:

> 53: 
> 54: /* Part 1:
> 55:  * The http client makes a connection to a URL who's content contains a lot of

I think it should be "whose"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1577363523

From jpai at openjdk.org  Wed Apr 24 06:55:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 Apr 2024 06:55:29 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v2]
In-Reply-To: <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
 <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
Message-ID: <1UlswfmF0DqPr0gfzNpypDlz9fzaDiMbZ-D4gnd1mz0=.ef95f066-e3e2-4715-b8c5-f9da9e698361@github.com>

On Tue, 23 Apr 2024 08:39:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> While working in that area I found some potential for cleanup of a few tests.
>> 
>> Most notably:
>> 
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free resources
>> 
>> B8291637.java:
>> - use just one instead of two test VM invocations
>> KeepAliveTimerThread.java:
>> call to grp.destroy() at the end is pointless (API is void & deprecated for removal)
>> 
>> Generally:
>> The deprecated URL constructor is used. It can be switched to the handy URIBuilder
>> Some more try with resources here and there
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 73:

> 71:     public static void startHttpServer() {
> 72:         try {
> 73:             server = HttpServer.create(new InetSocketAddress(InetAddress.getLocalHost(), 0), 10, "/", new SimpleHttpTransactionHandler());

While we are changing this test, can you change this to `InetAddress.getLoopbackAddress()` and then when constructing the requet URI, use `URIBuilder.loopback()`?

test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 91:

> 89:             uncaught.add(ex);
> 90:         });
> 91:         System.out.println("http server listens on: " + server.getAddress().getPort());

Maybe move this log message to the line after where we call server.start() and perhaps print the `server.getAddress()` instead of just the port.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1577368917
PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1577366679

From jpai at openjdk.org  Wed Apr 24 07:04:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 Apr 2024 07:04:29 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v2]
In-Reply-To: <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
 <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
Message-ID: <CuZE52vxUNtlN8opChupVxRzbOfB4gQxC-QSnNqUnGo=.185f641b-8486-4e46-90a6-1c3835f37489@github.com>

On Tue, 23 Apr 2024 08:39:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> While working in that area I found some potential for cleanup of a few tests.
>> 
>> Most notably:
>> 
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free resources
>> 
>> B8291637.java:
>> - use just one instead of two test VM invocations
>> KeepAliveTimerThread.java:
>> call to grp.destroy() at the end is pointless (API is void & deprecated for removal)
>> 
>> Generally:
>> The deprecated URL constructor is used. It can be switched to the handy URIBuilder
>> Some more try with resources here and there
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 154:

> 152: 
> 153:                     // if Keep-Alive-SocketCleaner consumes more than 50% of cpu then we
> 154:                     // can assume a recursive loop.

Interesting test case. I'm a bit surprised we haven't seen this intermittently fail. Speaking of which, I see that the change to this test proposes to remove it from `/othervm` and potentially run it in agent vm mode. Given the kind of checks this test is doing, I think it's better to let it run as a `othervm` test to keep the test as isolated as possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1577380954

From michaelm at openjdk.org  Wed Apr 24 08:33:29 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 24 Apr 2024 08:33:29 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <UaxwDtZq-0uihevw1dGyjs9Anoj0f2gqkD5oy0CO_9A=.e1608fb0-c9f7-425a-916c-0c8ffde693ec@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
 <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
 <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>
 <YpvmCHWo1csew9zv81wH2lK4_C5bgDjzOcDqeZZLoEg=.c88b3070-9f3f-4093-a6a7-92ce954bda5f@github.com>
 <taVZalykq-yOezCpnKDt7lZbFd7BM3WqHNpOVDCee9k=.d7864035-974f-4018-bb18-bb21cafe6f9c@github.com>
 <uXIBthbqrYPsTQYbWdy8N2jmY3-g4zAf9yZsYQY9pB8=.15ee48f1-6fee-428a-bd57-bc736e25c751@github.com>
 <lHHmwMe1ukpYdHVWdUlv-D976q3a9szgwc_sQT91fTA=.81283681-aad0-468c-9f18-b078314a4d06@github.com>
 <lzSz1lU8VJKfhcl1U8RxwpCWdweH22BMVpgLRt_ZaSg=.a286abf9-9bcb-4cb8-8c05-55f82ad0a327@github.com>
 <UaxwDtZq-0uihevw1dGyjs9Anoj0f2gqkD5oy0CO_9A=.e1608fb0-c9f7-425a-916c-0c8ffde693ec@github.com>
Message-ID: <ekyjU1iV9NzRDk92ADMc9R8dqH9FT8Qjercx5cc-5L0=.b69b3468-1b44-4a17-8147-6da0b032d5c2@github.com>

On Tue, 23 Apr 2024 19:31:03 GMT, robert engels <duke at openjdk.org> wrote:

>> The PR has been updated to fix the tests.
>
> By the way, as an x-Googler I am familiar with Hyrum and have seen the link. 
> 
> Since the api allows for async handling - validating that an arbitrary handler closes the stream doesn't seem possible other than by testing that the client receives the data it expects, and that the connection does not hang when keep alive with multiple requests is enabled. So I don't think runtime checks could have caught it either.
> 
> If someone wrote a handler that relied on the fact that headers were sent "early", and/or that streams were flushed even though the api specification states the handler must close the stream - they would be coding to the sun implementation - and if they lacked access to the source code they would never be able to determine that is what was happening.
> 
> The sun tests in this regard are incorrectly testing/expecting behavior that the published api specifically prohibits.

> If the handler sends headers(code,0) and doesn't close the stream, the connection is dead. If what you are saying is that the old behavior was to send the headers at this point, the client would see it and terminate the connection - that feels like a lot of ifs.
> 
> but as I mentioned, adding the flush after the exchange handler chain call is safe and would catch this scenario - even if the handler returns the data synchronously - as the buffered output stream at the top of the stream is fully synchronized.

Yes, the connection is dead, but what I'm saying is sometimes that doesn't matter, because the client (if it is HttpURLConnection) is going to close it anyway. I agree this is not a common scenario we need to worry about, and a simple release note flag should be enough to cover it. So, I don't think we are disagreeing on anything substantive here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1577503119

From duke at openjdk.org  Wed Apr 24 10:43:31 2024
From: duke at openjdk.org (robert engels)
Date: Wed, 24 Apr 2024 10:43:31 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <ekyjU1iV9NzRDk92ADMc9R8dqH9FT8Qjercx5cc-5L0=.b69b3468-1b44-4a17-8147-6da0b032d5c2@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
 <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
 <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>
 <YpvmCHWo1csew9zv81wH2lK4_C5bgDjzOcDqeZZLoEg=.c88b3070-9f3f-4093-a6a7-92ce954bda5f@github.com>
 <taVZalykq-yOezCpnKDt7lZbFd7BM3WqHNpOVDCee9k=.d7864035-974f-4018-bb18-bb21cafe6f9c@github.com>
 <uXIBthbqrYPsTQYbWdy8N2jmY3-g4zAf9yZsYQY9pB8=.15ee48f1-6fee-428a-bd57-bc736e25c751@github.com>
 <lHHmwMe1ukpYdHVWdUlv-D976q3a9szgwc_sQT91fTA=.81283681-aad0-468c-9f18-b078314a4d06@github.com>
 <lzSz1lU8VJKfhcl1U8RxwpCWdweH22BMVpgLRt_ZaSg=.a286abf9-9bcb-4cb8-8c05-55f82ad0a327@github.com>
 <UaxwDtZq-0uihevw1dGyjs9Anoj0f2gqkD5oy0CO_9A=.e1608fb0-c9f7-425a-916c-0c8ffde693ec@github.com>
 <ekyjU1iV9NzRDk92ADMc9R8dqH9FT8Qjercx5cc-5L0=.b69b3468-1b44-4a17-8147-6da0b032d5c2@github.com>
Message-ID: <uFQ_8PW4Ij-rS7h9FyHqy5ftPMFtLR-QZSDNF2pMIJc=.a9f2bc8c-fe44-413b-8566-a19c31d5a4d5@github.com>

On Wed, 24 Apr 2024 08:31:14 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> By the way, as an x-Googler I am familiar with Hyrum and have seen the link. 
>> 
>> Since the api allows for async handling - validating that an arbitrary handler closes the stream doesn't seem possible other than by testing that the client receives the data it expects, and that the connection does not hang when keep alive with multiple requests is enabled. So I don't think runtime checks could have caught it either.
>> 
>> If someone wrote a handler that relied on the fact that headers were sent "early", and/or that streams were flushed even though the api specification states the handler must close the stream - they would be coding to the sun implementation - and if they lacked access to the source code they would never be able to determine that is what was happening.
>> 
>> The sun tests in this regard are incorrectly testing/expecting behavior that the published api specifically prohibits.
>
>> If the handler sends headers(code,0) and doesn't close the stream, the connection is dead. If what you are saying is that the old behavior was to send the headers at this point, the client would see it and terminate the connection - that feels like a lot of ifs.
>> 
>> but as I mentioned, adding the flush after the exchange handler chain call is safe and would catch this scenario - even if the handler returns the data synchronously - as the buffered output stream at the top of the stream is fully synchronized.
> 
> Yes, the connection is dead, but what I'm saying is sometimes that doesn't matter, because the client (if it is HttpURLConnection) is going to close it anyway. I agree this is not a common scenario we need to worry about, and a simple release note flag should be enough to cover it. So, I don't think we are disagreeing on anything substantive here.

Yep. Just let me know if there is anything else you need me to do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1577677619

From djelinski at openjdk.org  Wed Apr 24 11:20:29 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 24 Apr 2024 11:20:29 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v3]
In-Reply-To: <99jN8b2P3kZeY9Pc_Zmvf-oKfGnWoVs2M1RdqcQb_b4=.911978ac-bb25-4d90-a306-e56e9b245b50@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <99jN8b2P3kZeY9Pc_Zmvf-oKfGnWoVs2M1RdqcQb_b4=.911978ac-bb25-4d90-a306-e56e9b245b50@github.com>
Message-ID: <uUaQ4aj4aihQ1JR4a7xPu0mjkRbiIjMy-6iINsVZHvk=.374e84cd-c942-4758-993c-b1fa33d16d3a@github.com>

On Sat, 20 Apr 2024 23:13:48 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
>> 
>> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
>> 
>> E.g. on my developer laptop runtime went down from ~100s to ~10s.
>> 
>> I also made additional cleanups/refactoring in the test.
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Simplify the test further
>  - Merge branch 'master' into JDK-8330523
>  - Small further cleanup
>  - JDK-8330523

This looks reasonable.

test/jdk/sun/net/www/http/HttpClient/KeepAliveTest.java line 112:

> 110:     private volatile boolean isProxySet;
> 111: 
> 112:     private CountDownLatch serverLatch = new CountDownLatch(1);

CountDownLatch is not reusable; consider using a Semaphore here

test/jdk/sun/net/www/http/HttpClient/KeepAliveTest.java line 113:

> 111: 
> 112:     private CountDownLatch serverLatch = new CountDownLatch(1);
> 113:     private Thread server;

this can be converted to a local variable easily

test/jdk/sun/net/www/http/HttpClient/KeepAliveTest.java line 315:

> 313:         keepAliveKeyClassconstructor.setAccessible(true);
> 314: 
> 315:         Logger logger = Logger.getLogger("sun.net.www.protocol.http.HttpURLConnection");

the logger was a static field for a reason; we don't want it to be GCed in the middle of the test

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

PR Review: https://git.openjdk.org/jdk/pull/18817#pullrequestreview-2019394795
PR Review Comment: https://git.openjdk.org/jdk/pull/18817#discussion_r1577641489
PR Review Comment: https://git.openjdk.org/jdk/pull/18817#discussion_r1577643840
PR Review Comment: https://git.openjdk.org/jdk/pull/18817#discussion_r1577600648

From clanger at openjdk.org  Wed Apr 24 13:27:30 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 24 Apr 2024 13:27:30 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v3]
In-Reply-To: <uUaQ4aj4aihQ1JR4a7xPu0mjkRbiIjMy-6iINsVZHvk=.374e84cd-c942-4758-993c-b1fa33d16d3a@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <99jN8b2P3kZeY9Pc_Zmvf-oKfGnWoVs2M1RdqcQb_b4=.911978ac-bb25-4d90-a306-e56e9b245b50@github.com>
 <uUaQ4aj4aihQ1JR4a7xPu0mjkRbiIjMy-6iINsVZHvk=.374e84cd-c942-4758-993c-b1fa33d16d3a@github.com>
Message-ID: <MXTy9cmSbuPWKCH5SoIVvy-crx52Em1tYQO48otZ0YA=.c45d0634-190c-4651-99a4-0c4118b27945@github.com>

On Wed, 24 Apr 2024 09:39:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Simplify the test further
>>  - Merge branch 'master' into JDK-8330523
>>  - Small further cleanup
>>  - JDK-8330523
>
> test/jdk/sun/net/www/http/HttpClient/KeepAliveTest.java line 315:
> 
>> 313:         keepAliveKeyClassconstructor.setAccessible(true);
>> 314: 
>> 315:         Logger logger = Logger.getLogger("sun.net.www.protocol.http.HttpURLConnection");
> 
> the logger was a static field for a reason; we don't want it to be GCed in the middle of the test

correct. Will change it back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18817#discussion_r1577886527

From clanger at openjdk.org  Wed Apr 24 13:32:31 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 24 Apr 2024 13:32:31 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v3]
In-Reply-To: <uUaQ4aj4aihQ1JR4a7xPu0mjkRbiIjMy-6iINsVZHvk=.374e84cd-c942-4758-993c-b1fa33d16d3a@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <99jN8b2P3kZeY9Pc_Zmvf-oKfGnWoVs2M1RdqcQb_b4=.911978ac-bb25-4d90-a306-e56e9b245b50@github.com>
 <uUaQ4aj4aihQ1JR4a7xPu0mjkRbiIjMy-6iINsVZHvk=.374e84cd-c942-4758-993c-b1fa33d16d3a@github.com>
Message-ID: <i4ioYtSAug-VE-LwefLwNWV076WhMFZB5WvPtJLgn4A=.8787f84c-24fe-48b7-b01b-a04b1a26c36e@github.com>

On Wed, 24 Apr 2024 10:11:03 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Simplify the test further
>>  - Merge branch 'master' into JDK-8330523
>>  - Small further cleanup
>>  - JDK-8330523
>
> test/jdk/sun/net/www/http/HttpClient/KeepAliveTest.java line 112:
> 
>> 110:     private volatile boolean isProxySet;
>> 111: 
>> 112:     private CountDownLatch serverLatch = new CountDownLatch(1);
> 
> CountDownLatch is not reusable; consider using a Semaphore here

Yes, but there's always new instance per test. One could certainly change it to use a global static semaphore...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18817#discussion_r1577895205

From djelinski at openjdk.org  Wed Apr 24 14:07:29 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 24 Apr 2024 14:07:29 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v3]
In-Reply-To: <i4ioYtSAug-VE-LwefLwNWV076WhMFZB5WvPtJLgn4A=.8787f84c-24fe-48b7-b01b-a04b1a26c36e@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <99jN8b2P3kZeY9Pc_Zmvf-oKfGnWoVs2M1RdqcQb_b4=.911978ac-bb25-4d90-a306-e56e9b245b50@github.com>
 <uUaQ4aj4aihQ1JR4a7xPu0mjkRbiIjMy-6iINsVZHvk=.374e84cd-c942-4758-993c-b1fa33d16d3a@github.com>
 <i4ioYtSAug-VE-LwefLwNWV076WhMFZB5WvPtJLgn4A=.8787f84c-24fe-48b7-b01b-a04b1a26c36e@github.com>
Message-ID: <aMuCTtTSGyCx7KVnQrsEkX6USKbdFFTfmC830NxGqQo=.6df91975-7b80-4c05-a3c9-6c05a23bb706@github.com>

On Wed, 24 Apr 2024 13:30:09 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> test/jdk/sun/net/www/http/HttpClient/KeepAliveTest.java line 112:
>> 
>>> 110:     private volatile boolean isProxySet;
>>> 111: 
>>> 112:     private CountDownLatch serverLatch = new CountDownLatch(1);
>> 
>> CountDownLatch is not reusable; consider using a Semaphore here
>
> Yes, but there's always new instance per test. One could certainly change it to use a global static semaphore...

Ah, good point, missed that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18817#discussion_r1577954607

From djelinski at openjdk.org  Wed Apr 24 17:53:48 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 24 Apr 2024 17:53:48 GMT
Subject: RFR: 8331063: Some HttpClient tests don't report leaks
Message-ID: <tiITLCplsaarDbE8obiNQgyWMJ683s_4K6uEpE38Tx0=.57c6ff8a-7198-48a5-aca5-0c3e10316e4a@github.com>

This patch fixes leak reporting in `ForbiddenHeadTest.java` and `ProxySelectorTest.java`.

The tests were checking for leaks, but the detected problems were not reported to the test harness. Additionally, `ForbiddenHeadTest.java` was holding references to the clients, preventing them from being collected by GC.

The tests continue to pass.

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

Commit messages:
 - Fix leak tracking

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

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

From dfuchs at openjdk.org  Wed Apr 24 18:01:27 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 24 Apr 2024 18:01:27 GMT
Subject: RFR: 8331063: Some HttpClient tests don't report leaks
In-Reply-To: <tiITLCplsaarDbE8obiNQgyWMJ683s_4K6uEpE38Tx0=.57c6ff8a-7198-48a5-aca5-0c3e10316e4a@github.com>
References: <tiITLCplsaarDbE8obiNQgyWMJ683s_4K6uEpE38Tx0=.57c6ff8a-7198-48a5-aca5-0c3e10316e4a@github.com>
Message-ID: <nohBur5tSGJ0VNxkfPTmMDfUOORogUbkouXLKD7OaEM=.0dfd75d0-c3d9-44dd-9b1b-247f3aa96e81@github.com>

On Wed, 24 Apr 2024 16:21:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes leak reporting in `ForbiddenHeadTest.java` and `ProxySelectorTest.java`.
> 
> The tests were checking for leaks, but the detected problems were not reported to the test harness. Additionally, `ForbiddenHeadTest.java` was holding references to the clients, preventing them from being collected by GC.
> 
> The tests continue to pass.

LGTM. Thanks for finding the issue and fixing it.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18938#pullrequestreview-2020579069

From vtewari at openjdk.org  Thu Apr 25 05:05:37 2024
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 25 Apr 2024 05:05:37 GMT
Subject: RFR: 8331063: Some HttpClient tests don't report leaks
In-Reply-To: <tiITLCplsaarDbE8obiNQgyWMJ683s_4K6uEpE38Tx0=.57c6ff8a-7198-48a5-aca5-0c3e10316e4a@github.com>
References: <tiITLCplsaarDbE8obiNQgyWMJ683s_4K6uEpE38Tx0=.57c6ff8a-7198-48a5-aca5-0c3e10316e4a@github.com>
Message-ID: <eGWmWFbf5BjU4kl6zqLERfze-k3U5miC-0NTQmAh0uQ=.51ea6973-7187-470a-8a38-97d62bdd8765@github.com>

On Wed, 24 Apr 2024 16:21:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes leak reporting in `ForbiddenHeadTest.java` and `ProxySelectorTest.java`.
> 
> The tests were checking for leaks, but the detected problems were not reported to the test harness. Additionally, `ForbiddenHeadTest.java` was holding references to the clients, preventing them from being collected by GC.
> 
> The tests continue to pass.

Looks IK to me.

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

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18938#pullrequestreview-2021495526

From clanger at openjdk.org  Thu Apr 25 06:58:32 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 06:58:32 GMT
Subject: Integrated: 8330815: Use pattern matching for instanceof in
 KeepAliveCache
In-Reply-To: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>
References: <c_Hp2LI02jOYioKHVBPYNxy7EboDNOk7U_bOgkXWWro=.b07b274c-e092-44e8-b765-9274f5b903a4@github.com>
Message-ID: <hxUz9rDg90tUx4X_AtULbyunBosDWEeQXN8UnrL_800=.e51503df-fd69-48d0-b88f-71e4d716df1c@github.com>

On Mon, 22 Apr 2024 11:23:59 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> In su.net.www.http.KeepAliveCache we could use pattern matching for instanceof.

This pull request has now been integrated.

Changeset: e818ab60
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e818ab60a0c1dac277b8b15301cdfb7d439ed26c
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8330815: Use pattern matching for instanceof in KeepAliveCache

Reviewed-by: jpai, djelinski

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

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

From clanger at openjdk.org  Thu Apr 25 07:19:45 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 07:19:45 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v4]
In-Reply-To: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
Message-ID: <Gj4phJa6h6WuBglVtF5vYXQ-WzCYUEFr8PeMANY5nuA=.cda878d1-3dda-4b45-b9d9-e25d36e2cf25@github.com>

> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
> 
> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
> 
> E.g. on my developer laptop runtime went down from ~100s to ~10s.
> 
> I also made additional cleanups/refactoring in the test.

Christoph Langer 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 six additional commits since the last revision:

 - Review Feedback Daniel
 - Merge branch 'master' into JDK-8330523
 - Simplify the test further
 - Merge branch 'master' into JDK-8330523
 - Small further cleanup
 - JDK-8330523

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18817/files
  - new: https://git.openjdk.org/jdk/pull/18817/files/eae78eca..88572af1

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

  Stats: 2204 lines in 100 files changed: 1867 ins; 173 del; 164 mod
  Patch: https://git.openjdk.org/jdk/pull/18817.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18817/head:pull/18817

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

From clanger at openjdk.org  Thu Apr 25 07:19:45 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 07:19:45 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v3]
In-Reply-To: <aMuCTtTSGyCx7KVnQrsEkX6USKbdFFTfmC830NxGqQo=.6df91975-7b80-4c05-a3c9-6c05a23bb706@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <99jN8b2P3kZeY9Pc_Zmvf-oKfGnWoVs2M1RdqcQb_b4=.911978ac-bb25-4d90-a306-e56e9b245b50@github.com>
 <uUaQ4aj4aihQ1JR4a7xPu0mjkRbiIjMy-6iINsVZHvk=.374e84cd-c942-4758-993c-b1fa33d16d3a@github.com>
 <i4ioYtSAug-VE-LwefLwNWV076WhMFZB5WvPtJLgn4A=.8787f84c-24fe-48b7-b01b-a04b1a26c36e@github.com>
 <aMuCTtTSGyCx7KVnQrsEkX6USKbdFFTfmC830NxGqQo=.6df91975-7b80-4c05-a3c9-6c05a23bb706@github.com>
Message-ID: <KAnpYZUiRiUzXyNcta0jw_Ca1DbghiSKfd149gHkoEA=.6705174d-1a61-4b04-9cc5-4c5fcff42585@github.com>

On Wed, 24 Apr 2024 14:04:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Yes, but there's always new instance per test. One could certainly change it to use a global static semaphore...
>
> Ah, good point, missed that.

Nevertheless, I changed synchronization to a static Phaser in my newest version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18817#discussion_r1578996144

From clanger at openjdk.org  Thu Apr 25 07:19:46 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 07:19:46 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v3]
In-Reply-To: <uUaQ4aj4aihQ1JR4a7xPu0mjkRbiIjMy-6iINsVZHvk=.374e84cd-c942-4758-993c-b1fa33d16d3a@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <99jN8b2P3kZeY9Pc_Zmvf-oKfGnWoVs2M1RdqcQb_b4=.911978ac-bb25-4d90-a306-e56e9b245b50@github.com>
 <uUaQ4aj4aihQ1JR4a7xPu0mjkRbiIjMy-6iINsVZHvk=.374e84cd-c942-4758-993c-b1fa33d16d3a@github.com>
Message-ID: <8nV_HfS86YVBZSrdEc75KiAMKSWpQ7BnIMVf2m97lxE=.ec58a788-2764-4e75-a497-5a967b098410@github.com>

On Wed, 24 Apr 2024 10:12:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Simplify the test further
>>  - Merge branch 'master' into JDK-8330523
>>  - Small further cleanup
>>  - JDK-8330523
>
> test/jdk/sun/net/www/http/HttpClient/KeepAliveTest.java line 113:
> 
>> 111: 
>> 112:     private CountDownLatch serverLatch = new CountDownLatch(1);
>> 113:     private Thread server;
> 
> this can be converted to a local variable easily

OK, did this and using virtual threads now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18817#discussion_r1578996480

From clanger at openjdk.org  Thu Apr 25 08:02:32 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 08:02:32 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v2]
In-Reply-To: <UJvA_CmhhauBANP5Hyo_QTmY1lA0L-99iQK2uLy0iiY=.6ed4d703-eca7-4ae0-9948-b0d0eb2a5e3f@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
 <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
 <UJvA_CmhhauBANP5Hyo_QTmY1lA0L-99iQK2uLy0iiY=.6ed4d703-eca7-4ae0-9948-b0d0eb2a5e3f@github.com>
Message-ID: <mLGL8A7lnduugaLjlfk8BlJsWA9jP49QD4vJ9go24nM=.76c441e2-9a9f-4e6c-96d7-e55bd18c6ac6@github.com>

On Wed, 24 Apr 2024 06:47:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 55:
> 
>> 53: 
>> 54: /* Part 1:
>> 55:  * The http client makes a connection to a URL who's content contains a lot of
> 
> I think it should be "whose"

Fixed

> test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 73:
> 
>> 71:     public static void startHttpServer() {
>> 72:         try {
>> 73:             server = HttpServer.create(new InetSocketAddress(InetAddress.getLocalHost(), 0), 10, "/", new SimpleHttpTransactionHandler());
> 
> While we are changing this test, can you change this to `InetAddress.getLoopbackAddress()` and then when constructing the requet URI, use `URIBuilder.loopback()`?

Done

> test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 91:
> 
>> 89:             uncaught.add(ex);
>> 90:         });
>> 91:         System.out.println("http server listens on: " + server.getAddress().getPort());
> 
> Maybe move this log message to the line after where we call server.start() and perhaps print the `server.getAddress()` instead of just the port.

Done

> test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java line 142:
> 
>> 140:                 .port(port)
>> 141:                 .path("/firstCall")
>> 142:                 .toURL();
> 
> Hello Christoph, what's the significance of changing the path from `/` to `/firstCall` in this test?

Good catch, copy&paste error.

> test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java line 148:
> 
>> 146:             int c;
>> 147:             byte[] buf = new byte[256];
>> 148:             while ((c=i.read(buf)) != -1) {
> 
> Nit: needs a space before and after the `=`

Fixed.

> test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java line 149:
> 
>> 147:             byte[] buf = new byte[256];
>> 148:             while ((c=i.read(buf)) != -1) {
>> 149:                 count+=c;
> 
> Same here, needs a space before/after `+=`

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1579046291
PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1579047929
PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1579049163
PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1579042706
PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1579043468
PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1579043659

From clanger at openjdk.org  Thu Apr 25 08:11:11 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 08:11:11 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v3]
In-Reply-To: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
Message-ID: <F1I4ehwsEKh8eanWn5jlNEBm7FvbIdyWewOAqxj-2Rs=.ea5dae5e-5f72-4f42-8ea3-7d387f278fda@github.com>

> While working in that area I found some potential for cleanup of a few tests.
> 
> Most notably:
> 
> B5045306.java:
> - does not need to run in othervm
> - the executor service that it uses should be shut down eventually to free resources
> 
> B8291637.java:
> - use just one instead of two test VM invocations
> KeepAliveTimerThread.java:
> call to grp.destroy() at the end is pointless (API is void & deprecated for removal)
> 
> Generally:
> The deprecated URL constructor is used. It can be switched to the handy URIBuilder
> Some more try with resources here and there

Christoph Langer 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 five additional commits since the last revision:

 - Merge branch 'master' into keepalivetests
 - Jaikiran's comments
 - Update test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Copyright year
 - JDK-8330814

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18884/files
  - new: https://git.openjdk.org/jdk/pull/18884/files/92bddff8..a89416f0

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

  Stats: 9885 lines in 316 files changed: 6019 ins; 2755 del; 1111 mod
  Patch: https://git.openjdk.org/jdk/pull/18884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18884/head:pull/18884

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

From clanger at openjdk.org  Thu Apr 25 08:11:11 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 08:11:11 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v2]
In-Reply-To: <CuZE52vxUNtlN8opChupVxRzbOfB4gQxC-QSnNqUnGo=.185f641b-8486-4e46-90a6-1c3835f37489@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
 <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
 <CuZE52vxUNtlN8opChupVxRzbOfB4gQxC-QSnNqUnGo=.185f641b-8486-4e46-90a6-1c3835f37489@github.com>
Message-ID: <NGjeBHbeDj257yNh8grTAwBZr0oPtwCA92_mRm-fduI=.8892170a-981e-451a-af94-d4c73686c6ee@github.com>

On Wed, 24 Apr 2024 07:01:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 154:
> 
>> 152: 
>> 153:                     // if Keep-Alive-SocketCleaner consumes more than 50% of cpu then we
>> 154:                     // can assume a recursive loop.
> 
> Interesting test case. I'm a bit surprised we haven't seen this intermittently fail. Speaking of which, I see that the change to this test proposes to remove it from `/othervm` and potentially run it in agent vm mode. Given the kind of checks this test is doing, I think it's better to let it run as a `othervm` test to keep the test as isolated as possible.

I've thought about this, too. However, I see the only critical point why it could merit a `/othervm` test is this thing with querying the thread CPU time of the Keep-Alive-SocketCleaner thread. But I think the likelihood of this failing is the same within standard test and `/othervm`. So I'd prefer to change to standard test, since this is one of the improvements of this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1579054775

From clanger at openjdk.org  Thu Apr 25 08:11:53 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 08:11:53 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v5]
In-Reply-To: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
Message-ID: <PT25DVguRcmfyoF6BjRMBM1F-V55qJeChc_6_ECsIT0=.4a68a235-fac9-4b31-a92e-73aca3be40bd@github.com>

> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
> 
> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
> 
> E.g. on my developer laptop runtime went down from ~100s to ~10s.
> 
> I also made additional cleanups/refactoring in the test.

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

 - Merge branch 'master' into JDK-8330523
 - Review Feedback Daniel
 - Merge branch 'master' into JDK-8330523
 - Simplify the test further
 - Merge branch 'master' into JDK-8330523
 - Small further cleanup
 - JDK-8330523

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18817/files
  - new: https://git.openjdk.org/jdk/pull/18817/files/88572af1..b141813a

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

  Stats: 9876 lines in 314 files changed: 6018 ins; 2754 del; 1104 mod
  Patch: https://git.openjdk.org/jdk/pull/18817.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18817/head:pull/18817

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

From djelinski at openjdk.org  Thu Apr 25 08:11:53 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 25 Apr 2024 08:11:53 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v5]
In-Reply-To: <PT25DVguRcmfyoF6BjRMBM1F-V55qJeChc_6_ECsIT0=.4a68a235-fac9-4b31-a92e-73aca3be40bd@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <PT25DVguRcmfyoF6BjRMBM1F-V55qJeChc_6_ECsIT0=.4a68a235-fac9-4b31-a92e-73aca3be40bd@github.com>
Message-ID: <BYgUqFloyXIuAncug2asUr6A3X52eG-Mfr5E8aVhQoU=.463d9688-0067-44cb-93e6-ad06aec0772e@github.com>

On Thu, 25 Apr 2024 08:09:28 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
>> 
>> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
>> 
>> E.g. on my developer laptop runtime went down from ~100s to ~10s.
>> 
>> I also made additional cleanups/refactoring in the test.
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8330523
>  - Review Feedback Daniel
>  - Merge branch 'master' into JDK-8330523
>  - Simplify the test further
>  - Merge branch 'master' into JDK-8330523
>  - Small further cleanup
>  - JDK-8330523

LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18817#pullrequestreview-2021828068

From clanger at openjdk.org  Thu Apr 25 08:14:29 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 08:14:29 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v5]
In-Reply-To: <BYgUqFloyXIuAncug2asUr6A3X52eG-Mfr5E8aVhQoU=.463d9688-0067-44cb-93e6-ad06aec0772e@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <PT25DVguRcmfyoF6BjRMBM1F-V55qJeChc_6_ECsIT0=.4a68a235-fac9-4b31-a92e-73aca3be40bd@github.com>
 <BYgUqFloyXIuAncug2asUr6A3X52eG-Mfr5E8aVhQoU=.463d9688-0067-44cb-93e6-ad06aec0772e@github.com>
Message-ID: <2C1GSNM6OmNMt8lSOFzFlTKETTciJsn7HLksyBb9fAc=.20ec9002-8308-4d30-b36b-be8569b669f9@github.com>

On Thu, 25 Apr 2024 08:09:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> LGTM. Thanks!

Thanks for the review. Will you give it another spin in your test system? Otherwise, I'll integrate tomorrow after we have another run in ours.

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

PR Comment: https://git.openjdk.org/jdk/pull/18817#issuecomment-2076620221

From djelinski at openjdk.org  Thu Apr 25 11:33:32 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 25 Apr 2024 11:33:32 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
Message-ID: <0wloWCE1fUeivZZM6AWxX4sibJUaSMbMeI8MGmbf6G4=.d07c27f0-921d-4d3d-b19f-4fb2e019deca@github.com>

On Tue, 23 Apr 2024 19:10:48 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix broken test cases

LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18667#pullrequestreview-2022242466

From clanger at openjdk.org  Thu Apr 25 11:59:56 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 11:59:56 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v6]
In-Reply-To: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
Message-ID: <7TQ26zvjQ2P1AEhENIhnKrwWdzFrOop7PFIurvzcnf4=.ab676355-cfbb-4a63-804c-5b7640b64aeb@github.com>

> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
> 
> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
> 
> E.g. on my developer laptop runtime went down from ~100s to ~10s.
> 
> I also made additional cleanups/refactoring in the test.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Use platform thread for server instead of virtual. Seems to be faster

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18817/files
  - new: https://git.openjdk.org/jdk/pull/18817/files/b141813a..6dc20dc5

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

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

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

From jpai at openjdk.org  Thu Apr 25 12:05:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 Apr 2024 12:05:32 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <Lqw3bQnhfdQXF_TmhEW9eEkycAfrl95bb5E5rAiHYgE=.3d53e971-c1b1-44d2-a257-a7bf386f8e98@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <Lqw3bQnhfdQXF_TmhEW9eEkycAfrl95bb5E5rAiHYgE=.3d53e971-c1b1-44d2-a257-a7bf386f8e98@github.com>
Message-ID: <TYRLAMxAgoz6wwTceFbsMo2GSEcW7zHpnzzUUEv_-3w=.ba52f986-9a15-4187-ae9d-366f2e2c1a50@github.com>

On Thu, 25 Apr 2024 12:01:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix broken test cases
>
> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2005, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Hello @robaho, since this is a new test file, the copyright year should be `Copyright (c) 2024, Oracle ....`

Additionally, the other files that have been updated in this PR will need an copyright year update. The `ChunkedOutputStream.java` for example, will have to be changed from `2005, 2023,` to `2005, 2024,`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579352477

From jpai at openjdk.org  Thu Apr 25 12:05:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 Apr 2024 12:05:31 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
Message-ID: <Lqw3bQnhfdQXF_TmhEW9eEkycAfrl95bb5E5rAiHYgE=.3d53e971-c1b1-44d2-a257-a7bf386f8e98@github.com>

On Tue, 23 Apr 2024 19:10:48 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix broken test cases

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2023, Oracle and/or its affiliates. All rights reserved.

Hello @robaho, since this is a new test file, the copyright year should be `Copyright (c) 2024, Oracle ....`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579350778

From jpai at openjdk.org  Thu Apr 25 12:14:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 Apr 2024 12:14:32 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
Message-ID: <AaFKbSIn3Wij02eW2gF6Jt6PcJplharNGIo7W2VBIFk=.530eb9a0-463c-459c-9f8d-fd57ca9d8d23@github.com>

On Tue, 23 Apr 2024 19:10:48 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix broken test cases

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 29:

> 27:  * @summary  tcp no delay not required for small payloads
> 28:  * @library /test/lib
> 29:  * @run main/othervm/timeout=5 -Dsun.net.httpserver.nodelay=false  TcpNoDelayNotRequired

I think we should remove the `timeout=5` here. In the past we have seen that such timeouts have contributed to intermittent failures in the CI. jtreg itself has a (sufficiently large) timeout and if the test doesn't complete by then, then jtreg errors that test as timed out. Relying on jtreg timeout handling will avoid guessing the right timeout value here in the test definition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579362839

From jpai at openjdk.org  Thu Apr 25 12:20:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 Apr 2024 12:20:32 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
Message-ID: <mhZUf4S1Xt5cr0WmVsf0sg-9uqxZwDtukkmV6q7uyGE=.71abf24c-2633-4bfd-8051-a3cf87260ea9@github.com>

On Tue, 23 Apr 2024 19:10:48 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix broken test cases

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 32:

> 30:  */
> 31: 
> 32: import com.sun.net.httpserver.*;

It would be better to use exact imports instead of wildcard.

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 44:

> 42: import java.util.concurrent.ExecutorService;
> 43: import java.util.concurrent.Executors;
> 44: import java.util.logging.*;

Same here, exact imports instead of wildcard.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579370001
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579370366

From jpai at openjdk.org  Thu Apr 25 12:23:33 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 Apr 2024 12:23:33 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
Message-ID: <4FY5riST-8-tN3ltUSyhbLIAK5UdDVBirKuKS2b6TnI=.f2393b8c-65e5-4f5a-bd78-6e11b22e80e6@github.com>

On Tue, 23 Apr 2024 19:10:48 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix broken test cases

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 84:

> 82:         System.out.println("time "+time);
> 83:         server.stop(0);
> 84:         executor.shutdown();

Please use a try/finally block to stop the `server`. The `try` can start immediately after the `server.start()` call.

Similarly, for the `executor` and the `HttpClient`, you can use a try-with-resource block to close them too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579374672

From jpai at openjdk.org  Thu Apr 25 12:33:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 Apr 2024 12:33:31 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
Message-ID: <CG61hGNkXuzkuWXgWnSo_t_7Hag-zmbgLgs31g8olY4=.21e33a7d-7bac-4bb5-9903-9578d988f8f8@github.com>

On Tue, 23 Apr 2024 19:10:48 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix broken test cases

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 60:

> 58:         InetAddress loopback = InetAddress.getLoopbackAddress();
> 59:         InetSocketAddress addr = new InetSocketAddress (loopback, 0);
> 60:         HttpServer server = HttpServer.create (addr, 0);

Given the change we are doing, I think it would be good to even include a test (within this same test class) which tests the `HttpsServer`.

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 74:

> 72:             var uri = URIBuilder.newBuilder().scheme("http").loopback().port(server.getAddress().getPort()).path("/test").build();
> 73:             var response = client.send(HttpRequest.newBuilder(uri).build(), HttpResponse.BodyHandlers.ofString());
> 74:             if(!response.body().equals("hello")) throw new IllegalStateException("incorrect body");

It helps during debugging if the response body which failed the checked would either be logged or included as part of the exception that's being thrown. Perhaps:


throw new IllegalStateException("unexpected response body: " + response.body());

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 79:

> 77:             var uri = URIBuilder.newBuilder().scheme("http").loopback().port(server.getAddress().getPort()).path("/chunked").build();
> 78:             var response = client.send(HttpRequest.newBuilder(uri).build(), HttpResponse.BodyHandlers.ofString());
> 79:             if(!response.body().equals("hello")) throw new IllegalStateException("incorrect body");

Same applies here, it would be better to include the failing response body in the exception message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579386619
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579389263
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579390252

From jpai at openjdk.org  Thu Apr 25 12:48:33 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 Apr 2024 12:48:33 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
Message-ID: <towYQknCWAXmwgXg0rE5bU7uqQXIh36CeLpWvFTdOvE=.12e7535e-b3c9-4dec-8e26-8024f88653d6@github.com>

On Tue, 23 Apr 2024 19:10:48 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix broken test cases

I think it might be better to move out the new test from `test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java` to `test/jdk/com/sun/net/httpserver/TcpNoDelayNotRequired.java`. We haven't been using the `bugs` directory (or the bug number as the file name) for a while now.

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 99:

> 97:             t.sendResponseHeaders(200,5);
> 98:             t.getResponseBody().write("hello".getBytes(StandardCharsets.ISO_8859_1));
> 99:             t.getResponseBody().close();

I don't have a strong preference, but would you be open to updating this (and the ChunkedHandler) to:


try (InputStream is = t.getRequestBody()) {
    is.readAllBytes();
}
Headers reqHeaders = t.getRequestHeaders();
Headers respHeaders = t.getResponseHeaders();
respHeaders.add("content-type", "text/plain");
t.sendResponseHeaders(200,5);
try (OutputStream os = t.getResponseBody()) {
    os.write("hello".getBytes(StandardCharsets.ISO_8859_1));
}


(I haven't compiled it or done any testing with the proposed snippet)

test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 112:

> 110:             is.close();
> 111:             rmap.add("content-type","text/plain");
> 112:             t.sendResponseHeaders(200,0);

The value 0 and -1 have been a constant confusion in our tests when calling `sendResponseHeaders`. Can you update this line to:


t.sendResponseHeaders(200, 0 /* chunked */);

so that it's immediately obvious what the intent here is.

test/jdk/java/net/Authenticator/B4769350.java line 358:

> 356:         {
> 357:             exchange.getResponseHeaders().add("Proxy-Authenticate", reply);
> 358:             exchange.sendResponseHeaders(407, -1);

Similarly here:


exchange.sendResponseHeaders(407, -1 /* no response body */);

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2077092241
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579399205
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579400959
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579402251

From duke at openjdk.org  Thu Apr 25 12:48:34 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 12:48:34 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <AaFKbSIn3Wij02eW2gF6Jt6PcJplharNGIo7W2VBIFk=.530eb9a0-463c-459c-9f8d-fd57ca9d8d23@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <AaFKbSIn3Wij02eW2gF6Jt6PcJplharNGIo7W2VBIFk=.530eb9a0-463c-459c-9f8d-fd57ca9d8d23@github.com>
Message-ID: <m_sDWkrvPOnkwQSmQ54KsUprB6Hje0i05SRgZUC4eao=.c5bf6a92-fcd4-4de5-8bbd-9d77842b525e@github.com>

On Thu, 25 Apr 2024 12:11:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix broken test cases
>
> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 29:
> 
>> 27:  * @summary  tcp no delay not required for small payloads
>> 28:  * @library /test/lib
>> 29:  * @run main/othervm/timeout=5 -Dsun.net.httpserver.nodelay=false  TcpNoDelayNotRequired
> 
> I think we should remove the `timeout=5` here. In the past we have seen that such timeouts have contributed to intermittent failures in the CI. jtreg itself has a (sufficiently large) timeout and if the test doesn't complete by then, then jtreg errors that test as timed out. Relying on jtreg timeout handling will avoid guessing the right timeout value here in the test definition.

The timeout is the test. These changes fix the performance by an order of 100x. The timeout is the only way I know to test this.

> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 99:
> 
>> 97:             t.sendResponseHeaders(200,5);
>> 98:             t.getResponseBody().write("hello".getBytes(StandardCharsets.ISO_8859_1));
>> 99:             t.getResponseBody().close();
> 
> I don't have a strong preference, but would you be open to updating this (and the ChunkedHandler) to:
> 
> 
> try (InputStream is = t.getRequestBody()) {
>     is.readAllBytes();
> }
> Headers reqHeaders = t.getRequestHeaders();
> Headers respHeaders = t.getResponseHeaders();
> respHeaders.add("content-type", "text/plain");
> t.sendResponseHeaders(200,5);
> try (OutputStream os = t.getResponseBody()) {
>     os.write("hello".getBytes(StandardCharsets.ISO_8859_1));
> }
> 
> 
> (I haven't compiled it or done any testing with the proposed snippet)

Isn?t consistency in the code base more important. I like the change but it seems there should be a single PR that changes all of the test cases to this format.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579405001
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579409863

From jpai at openjdk.org  Thu Apr 25 12:57:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 Apr 2024 12:57:36 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <m_sDWkrvPOnkwQSmQ54KsUprB6Hje0i05SRgZUC4eao=.c5bf6a92-fcd4-4de5-8bbd-9d77842b525e@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <AaFKbSIn3Wij02eW2gF6Jt6PcJplharNGIo7W2VBIFk=.530eb9a0-463c-459c-9f8d-fd57ca9d8d23@github.com>
 <m_sDWkrvPOnkwQSmQ54KsUprB6Hje0i05SRgZUC4eao=.c5bf6a92-fcd4-4de5-8bbd-9d77842b525e@github.com>
Message-ID: <YrU68etEmilYVEWzBwpPovzKkxEaZUwNelk9aYRE05k=.8aee3fe8-6365-4c1a-ac22-a229301ede37@github.com>

On Thu, 25 Apr 2024 12:45:28 GMT, robert engels <duke at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 99:
>> 
>>> 97:             t.sendResponseHeaders(200,5);
>>> 98:             t.getResponseBody().write("hello".getBytes(StandardCharsets.ISO_8859_1));
>>> 99:             t.getResponseBody().close();
>> 
>> I don't have a strong preference, but would you be open to updating this (and the ChunkedHandler) to:
>> 
>> 
>> try (InputStream is = t.getRequestBody()) {
>>     is.readAllBytes();
>> }
>> Headers reqHeaders = t.getRequestHeaders();
>> Headers respHeaders = t.getResponseHeaders();
>> respHeaders.add("content-type", "text/plain");
>> t.sendResponseHeaders(200,5);
>> try (OutputStream os = t.getResponseBody()) {
>>     os.write("hello".getBytes(StandardCharsets.ISO_8859_1));
>> }
>> 
>> 
>> (I haven't compiled it or done any testing with the proposed snippet)
>
> Isn?t consistency in the code base more important. I like the change but it seems there should be a single PR that changes all of the test cases to this format.

We have been using these newer constructs whenever a new test gets added, but we don't update all tests in one go for such changes. If/when old tests are updated for some bug fix relevant to that test, depending on the complexity we either decide to let them stay as-is or update them to use these newer constructs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579417278

From duke at openjdk.org  Thu Apr 25 12:57:38 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 12:57:38 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <towYQknCWAXmwgXg0rE5bU7uqQXIh36CeLpWvFTdOvE=.12e7535e-b3c9-4dec-8e26-8024f88653d6@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <towYQknCWAXmwgXg0rE5bU7uqQXIh36CeLpWvFTdOvE=.12e7535e-b3c9-4dec-8e26-8024f88653d6@github.com>
Message-ID: <9dYpMKxWDf4xqtNJGFgcg7zCrlPhKWjJRtxyBXIpQBI=.66b2e47f-ddc7-4a71-9d0b-cdd6ee3976d3@github.com>

On Thu, 25 Apr 2024 12:39:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix broken test cases
>
> test/jdk/java/net/Authenticator/B4769350.java line 358:
> 
>> 356:         {
>> 357:             exchange.getResponseHeaders().add("Proxy-Authenticate", reply);
>> 358:             exchange.sendResponseHeaders(407, -1);
> 
> Similarly here:
> 
> 
> exchange.sendResponseHeaders(407, -1 /* no response body */);

I think a better solution would be to add a constant to the api class - rather than adding comments everywhere. E.g NO_CONTENT=-1 and UNLIMITED_CONTENT=0 or INDETERMINENT_CONTENT=0, or CHUNKED_CONTENT=0

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579419796

From duke at openjdk.org  Thu Apr 25 13:01:33 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 13:01:33 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <YrU68etEmilYVEWzBwpPovzKkxEaZUwNelk9aYRE05k=.8aee3fe8-6365-4c1a-ac22-a229301ede37@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <AaFKbSIn3Wij02eW2gF6Jt6PcJplharNGIo7W2VBIFk=.530eb9a0-463c-459c-9f8d-fd57ca9d8d23@github.com>
 <m_sDWkrvPOnkwQSmQ54KsUprB6Hje0i05SRgZUC4eao=.c5bf6a92-fcd4-4de5-8bbd-9d77842b525e@github.com>
 <YrU68etEmilYVEWzBwpPovzKkxEaZUwNelk9aYRE05k=.8aee3fe8-6365-4c1a-ac22-a229301ede37@github.com>
Message-ID: <TmWp0P0rQJUwTCAqN8x54PIWlKfgbJi2LBS6h39yBA0=.f6695fb5-9afd-4a08-8fc4-56f2d78270a9@github.com>

On Thu, 25 Apr 2024 12:50:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Isn?t consistency in the code base more important. I like the change but it seems there should be a single PR that changes all of the test cases to this format.
>
> We have been using these newer constructs whenever a new test gets added, but we don't update all tests in one go for such changes. If/when old tests are updated for some bug fix relevant to that test, depending on the complexity we either decide to let them stay as-is or update them to use these newer constructs.

Personally, I think that is not the correct choice. I think consistency is more important - especially in a code base this large. 

But I?ll do whatever you want. This is getting a bit frustrating. The PR review is 1% content and 99% personal nits. 

This is certainly a different approach than Google uses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579429149

From michaelm at openjdk.org  Thu Apr 25 13:35:40 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 25 Apr 2024 13:35:40 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v14]
In-Reply-To: <uFQ_8PW4Ij-rS7h9FyHqy5ftPMFtLR-QZSDNF2pMIJc=.a9f2bc8c-fe44-413b-8566-a19c31d5a4d5@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <mgTMrHjMhjbKGkBjvw7cA14MNYKGo0cOaoEwRJROoyw=.c084dbea-af14-4d46-81fb-34dc1d954b0a@github.com>
 <osw4klqqzqdl4bgfVOwAIvj-alz96R1ejwK-jnY2pEE=.ffe31d69-a12d-4772-9b59-dec79a6054a9@github.com>
 <kQW3-E55txCm66b1SWxM4CAeuqkJO0oYBIu1SUytWEE=.0d7e8f20-3e5e-430b-ba2e-c0cc39d16b3e@github.com>
 <ep5DTs2G5Vm8OjM3AZTsfGJSMVbf3fzl-Mm2c8cCOto=.d52fc69e-45dc-4bc4-9079-aa800e4ab4d2@github.com>
 <-Pr42I5YoK2PTrQ6JcQbkdnLPW4QA0_yWrdgKf9Jv5c=.d9da3a0c-73d0-44b2-9187-43abd9ba0181@github.com>
 <NXe8Rukqt6n6b95Pd2gPY5OMpOpJQ4rDRoOOBloe3uY=.eb57c2a5-0ac7-4d37-9030-0fe8e47aefa4@github.com>
 <TKdsCGtyzfcnho0zzfsDZ2W3qY41um44xDJdiITtyqY=.665b7034-d335-45dd-9c2b-58da6daa88b4@github.com>
 <T1uzcIYlwmqGs4r-WpaiRAae8UrOQlOqhwhhZV8kJnw=.c4af7c57-33c9-4e6a-9481-a7da0a481e52@github.com>
 <FdFJiF25Qe5bO_uzZUVoHa-BdwolT4YKUZakt-olcwU=.222972bb-499c-4d39-8ee4-6530c29ac17b@github.com>
 <12aSJ-5tArE2Wy7VBqLEvUhWg5OGkf0EwT4
 AU9NlGdA=.5a1e6fa1-ecc9-4e23-ad78-9b9ab627942d@github.com>
 <tPZjqzWlcvbWDus6663XibTaphoCBG8zrBWDgGE1T58=.90a40a7e-81c5-4cd5-b69e-5c0bc982e5af@github.com>
 <ZVNGVkEamEhamU9rTGm2tfiUnq8-AAQTE0Od6ajVH1k=.be9d83fa-4e74-44d9-9a5a-20a2c082a3de@github.com>
 <YpvmCHWo1csew9zv81wH2lK4_C5bgDjzOcDqeZZLoEg=.c88b3070-9f3f-4093-a6a7-92ce954bda5f@github.com>
 <taVZalykq-yOezCpnKDt7lZbFd7BM3WqHNpOVDCee9k=.d7864035-974f-4018-bb18-bb21cafe6f9c@github.com>
 <uXIBthbqrYPsTQYbWdy8N2jmY3-g4zAf9yZsYQY9pB8=.15ee48f1-6fee-428a-bd57-bc736e25c751@github.com>
 <lHHmwMe1ukpYdHVWdUlv-D976q3a9szgwc_sQT91fTA=.81283681-aad0-468c-9f18-b078314a4d06@github.com>
 <lzSz1lU8VJKfhcl1U8RxwpCWdweH22BMVpgLRt_ZaSg=.a286abf9-9bcb-4cb8-8c05-55f82ad0a327@github.com>
 <UaxwDtZq-0uihevw1dGyjs9Anoj0f2gqkD5oy0CO_9A=.e1608fb0-c9f7-425a-916c-0c8ffde693ec@github.com>
 <ekyjU1iV9NzRDk92ADMc9R8dqH9FT8Qjercx5cc-5L0=.b69b3468-1b44-4a17-8147-6da0b032d5c2@github.com>
 <uFQ_8PW4Ij-rS7h9FyHqy5ftPMFtLR-QZSDNF2pMIJc=.a9f2bc8c-fe44-413b-8566-a19c31d5a4d5@
 github.com>
Message-ID: <aGAcmATR0JZLg1jR-LnB9ffXbk-32_lddzUIpL8sbq8=.f56d06e4-44b6-4b48-9b97-cd7a4d278ec7@github.com>

On Wed, 24 Apr 2024 10:41:19 GMT, robert engels <duke at openjdk.org> wrote:

> Yep. Just let me know if there is anything else you need me to do.

Thats ok. I'll take care of the release note.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579475193

From duke at openjdk.org  Thu Apr 25 13:35:41 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 13:35:41 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <TmWp0P0rQJUwTCAqN8x54PIWlKfgbJi2LBS6h39yBA0=.f6695fb5-9afd-4a08-8fc4-56f2d78270a9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <AaFKbSIn3Wij02eW2gF6Jt6PcJplharNGIo7W2VBIFk=.530eb9a0-463c-459c-9f8d-fd57ca9d8d23@github.com>
 <m_sDWkrvPOnkwQSmQ54KsUprB6Hje0i05SRgZUC4eao=.c5bf6a92-fcd4-4de5-8bbd-9d77842b525e@github.com>
 <YrU68etEmilYVEWzBwpPovzKkxEaZUwNelk9aYRE05k=.8aee3fe8-6365-4c1a-ac22-a229301ede37@github.com>
 <TmWp0P0rQJUwTCAqN8x54PIWlKfgbJi2LBS6h39yBA0=.f6695fb5-9afd-4a08-8fc4-56f2d78270a9@github.com>
Message-ID: <wwWcweFbAUMM-IQoXZO4nMENBlDby8Zc1PAseiTR18E=.76be29fc-3051-45ad-b3e8-7e2388b1e813@github.com>

On Thu, 25 Apr 2024 12:58:36 GMT, robert engels <duke at openjdk.org> wrote:

>> We have been using these newer constructs whenever a new test gets added, but we don't update all tests in one go for such changes. If/when old tests are updated for some bug fix relevant to that test, depending on the complexity we either decide to let them stay as-is or update them to use these newer constructs.
>
> Personally, I think that is not the correct choice. I think consistency is more important - especially in a code base this large. 
> 
> But I?ll do whatever you want. This is getting a bit frustrating. The PR review is 1% content and 99% personal nits. 
> 
> This is certainly a different approach than Google uses.

To clarify the above. The standard should be - does this PR improve the code base. After which, if someone wishes to create a refactoring PR that addresses other issues - go for it. But don?t drag out someone?s already considerable effort in diagnosing and fixing the problem to satisfy other goals.

Clearly there is a lot of test code that could use cleanup - but this is not the way to go about doing that - holding up important fixes as an example. 

Most developers are going to look to existing code when implementing changes - if you have a ?bunch of stuff in your head? you?d really like it to adhere to it is going to be a frustrating process and people won?t bother.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579479267

From michaelm at openjdk.org  Thu Apr 25 13:35:42 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 25 Apr 2024 13:35:42 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <9dYpMKxWDf4xqtNJGFgcg7zCrlPhKWjJRtxyBXIpQBI=.66b2e47f-ddc7-4a71-9d0b-cdd6ee3976d3@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <towYQknCWAXmwgXg0rE5bU7uqQXIh36CeLpWvFTdOvE=.12e7535e-b3c9-4dec-8e26-8024f88653d6@github.com>
 <9dYpMKxWDf4xqtNJGFgcg7zCrlPhKWjJRtxyBXIpQBI=.66b2e47f-ddc7-4a71-9d0b-cdd6ee3976d3@github.com>
Message-ID: <bnbR1B3NPLVeBk1N6X1ojdXuV6kbVHX6lgb7FySyjmI=.a90fa916-10af-427d-915a-b4a4a709385c@github.com>

On Thu, 25 Apr 2024 12:52:14 GMT, robert engels <duke at openjdk.org> wrote:

> I think a better solution would be to add a constant to the api class - rather than adding comments everywhere. E.g NO_CONTENT=-1 and UNLIMITED_CONTENT=0 or INDETERMINENT_CONTENT=0, or CHUNKED_CONTENT=0

That's not a bad idea. I am doing a small update to the API under another bug id and I might include that in it. I kind of agree that adding comments might be overkill. We could probably update a lot of the tests mechanically to use these symbolic names afterwards.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579472954

From duke at openjdk.org  Thu Apr 25 13:40:37 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 13:40:37 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <bnbR1B3NPLVeBk1N6X1ojdXuV6kbVHX6lgb7FySyjmI=.a90fa916-10af-427d-915a-b4a4a709385c@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <towYQknCWAXmwgXg0rE5bU7uqQXIh36CeLpWvFTdOvE=.12e7535e-b3c9-4dec-8e26-8024f88653d6@github.com>
 <9dYpMKxWDf4xqtNJGFgcg7zCrlPhKWjJRtxyBXIpQBI=.66b2e47f-ddc7-4a71-9d0b-cdd6ee3976d3@github.com>
 <bnbR1B3NPLVeBk1N6X1ojdXuV6kbVHX6lgb7FySyjmI=.a90fa916-10af-427d-915a-b4a4a709385c@github.com>
Message-ID: <gyADz_N5Kw19PXSNVil5sStCs99MNW59mkSWCAjWuJA=.77922f92-9ccc-4bac-82bc-e847d43bb320@github.com>

On Thu, 25 Apr 2024 13:29:25 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I think a better solution would be to add a constant to the api class - rather than adding comments everywhere. E.g NO_CONTENT=-1 and UNLIMITED_CONTENT=0 or INDETERMINENT_CONTENT=0, or CHUNKED_CONTENT=0
>
>> I think a better solution would be to add a constant to the api class - rather than adding comments everywhere. E.g NO_CONTENT=-1 and UNLIMITED_CONTENT=0 or INDETERMINENT_CONTENT=0, or CHUNKED_CONTENT=0
> 
> That's not a bad idea. I am doing a small update to the API under another bug id and I might include that in it. I kind of agree that adding comments might be overkill. We could probably update a lot of the tests mechanically to use these symbolic names afterwards.

I?m on mobile now so I haven?t looked at the api - but I think adding default methods like

sendResponseHeadersNoContent(int code)

and OutputStream sendResponseHeadersChunked(int code) 

would also make the api easier to use.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579486672

From duke at openjdk.org  Thu Apr 25 14:23:57 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 14:23:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v18]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <QQTXw79chPaRD7GWGF6gsDDHuNuti08Ph4DK6bfU5tM=.0a0825dc-230d-49f2-9123-0696cedf681a@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  update copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/4060575b..207a3a92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=16-17

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

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

From djelinski at openjdk.org  Thu Apr 25 14:37:39 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 25 Apr 2024 14:37:39 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v6]
In-Reply-To: <7TQ26zvjQ2P1AEhENIhnKrwWdzFrOop7PFIurvzcnf4=.ab676355-cfbb-4a63-804c-5b7640b64aeb@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <7TQ26zvjQ2P1AEhENIhnKrwWdzFrOop7PFIurvzcnf4=.ab676355-cfbb-4a63-804c-5b7640b64aeb@github.com>
Message-ID: <PWVrq6Gq8SQaYfMKP5FZXxFQ10I0TJHt-_zcw0u8DgE=.dd3249e8-4237-407c-8f6c-9f70a00f46cf@github.com>

On Thu, 25 Apr 2024 11:59:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
>> 
>> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
>> 
>> E.g. on my developer laptop runtime went down from ~100s to ~10s.
>> 
>> I also made additional cleanups/refactoring in the test.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use platform thread for server instead of virtual. Seems to be faster

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18817#pullrequestreview-2022700508

From duke at openjdk.org  Thu Apr 25 14:38:18 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 14:38:18 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v19]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <5QzKMEkJMDhQI1urIFs2x6gy2CLe-RwGbFygM1HND20=.7d2ca494-2eb1-4714-9d42-2a9e6058d355@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  clean and move test based on PR review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/207a3a92..3fe66dc3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=17-18

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

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

From duke at openjdk.org  Thu Apr 25 14:43:38 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 14:43:38 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <gyADz_N5Kw19PXSNVil5sStCs99MNW59mkSWCAjWuJA=.77922f92-9ccc-4bac-82bc-e847d43bb320@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <towYQknCWAXmwgXg0rE5bU7uqQXIh36CeLpWvFTdOvE=.12e7535e-b3c9-4dec-8e26-8024f88653d6@github.com>
 <9dYpMKxWDf4xqtNJGFgcg7zCrlPhKWjJRtxyBXIpQBI=.66b2e47f-ddc7-4a71-9d0b-cdd6ee3976d3@github.com>
 <bnbR1B3NPLVeBk1N6X1ojdXuV6kbVHX6lgb7FySyjmI=.a90fa916-10af-427d-915a-b4a4a709385c@github.com>
 <gyADz_N5Kw19PXSNVil5sStCs99MNW59mkSWCAjWuJA=.77922f92-9ccc-4bac-82bc-e847d43bb320@github.com>
Message-ID: <8WU9R8wRfzcesJh1aMb05npa0q5Sc6zCAqRoWNbJYC0=.639ed5fb-a478-4f3a-8b1c-8512050e22d3@github.com>

On Thu, 25 Apr 2024 13:36:53 GMT, robert engels <duke at openjdk.org> wrote:

>>> I think a better solution would be to add a constant to the api class - rather than adding comments everywhere. E.g NO_CONTENT=-1 and UNLIMITED_CONTENT=0 or INDETERMINENT_CONTENT=0, or CHUNKED_CONTENT=0
>> 
>> That's not a bad idea. I am doing a small update to the API under another bug id and I might include that in it. I kind of agree that adding comments might be overkill. We could probably update a lot of the tests mechanically to use these symbolic names afterwards.
>
> I?m on mobile now so I haven?t looked at the api - but I think adding default methods like
> 
> sendResponseHeadersNoContent(int code)
> 
> and OutputStream sendResponseHeadersChunked(int code)
> 
> possibly sendResponeWithContent(int code, byte[] data) would also be helpful and cut down to n a lot of usage problems. 
> 
> would also make the api easier to use.

I am more than willing to work on an API change PR to add these methods. It is an abstract class, so they could collide with existing code, but I am guessing it is a trivial fix if it does, and it would break at compile time not runtime.

adding protected constants to the HttpExchange abstract class seems trivially safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579595951

From duke at openjdk.org  Thu Apr 25 14:48:57 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 14:48:57 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v20]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <wKdtW3jbiihTkeabLRuyBaSiulw1YVZ68_IazYSSYzE=.d1786682-2464-44d0-9739-f93e0bb5d919@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  document chunk handing explicitly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/3fe66dc3..e31f4879

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=18-19

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

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

From clanger at openjdk.org  Thu Apr 25 14:58:59 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 25 Apr 2024 14:58:59 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v7]
In-Reply-To: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
Message-ID: <t8k5fRZW6E48CQcFee43I4AqtmZD4CBHPwx2-rU_bHs=.e5151d7e-6a93-402f-998a-fa44e4e330c5@github.com>

> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
> 
> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
> 
> E.g. on my developer laptop runtime went down from ~100s to ~10s.
> 
> I also made additional cleanups/refactoring in the test.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Write server thread code more concisely

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18817/files
  - new: https://git.openjdk.org/jdk/pull/18817/files/6dc20dc5..12702b8a

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

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

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

From duke at openjdk.org  Thu Apr 25 14:59:37 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 14:59:37 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <mhZUf4S1Xt5cr0WmVsf0sg-9uqxZwDtukkmV6q7uyGE=.71abf24c-2633-4bfd-8051-a3cf87260ea9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <mhZUf4S1Xt5cr0WmVsf0sg-9uqxZwDtukkmV6q7uyGE=.71abf24c-2633-4bfd-8051-a3cf87260ea9@github.com>
Message-ID: <jOKEFfmkhcReZIJz2F_f7ojY6-6mr8yqnp4hivM1bXs=.4160be4b-0fa5-4419-b73d-2b83f2c1c01e@github.com>

On Thu, 25 Apr 2024 12:17:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix broken test cases
>
> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 32:
> 
>> 30:  */
>> 31: 
>> 32: import com.sun.net.httpserver.*;
> 
> It would be better to use exact imports instead of wildcard.

done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579639301

From duke at openjdk.org  Thu Apr 25 15:24:12 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 15:24:12 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v21]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <UNtfmAVfx8ThR66CbTqhPLKufjOA0Y_LtINx6wjg8-M=.63947c8d-aa72-4632-bc95-7f89f4922f82@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  add https testing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/e31f4879..f9bc4e4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=19-20

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

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

From duke at openjdk.org  Thu Apr 25 15:24:13 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 15:24:13 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <CG61hGNkXuzkuWXgWnSo_t_7Hag-zmbgLgs31g8olY4=.21e33a7d-7bac-4bb5-9903-9578d988f8f8@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <CG61hGNkXuzkuWXgWnSo_t_7Hag-zmbgLgs31g8olY4=.21e33a7d-7bac-4bb5-9903-9578d988f8f8@github.com>
Message-ID: <p2ybyhLaZGn-g0c0FaywGgsRKOB5r9e3cvXcYI3l3wc=.084ccb7a-6348-4e78-8e79-1d1a08829d9b@github.com>

On Thu, 25 Apr 2024 12:28:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix broken test cases
>
> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 60:
> 
>> 58:         InetAddress loopback = InetAddress.getLoopbackAddress();
>> 59:         InetSocketAddress addr = new InetSocketAddress (loopback, 0);
>> 60:         HttpServer server = HttpServer.create (addr, 0);
> 
> Given the change we are doing, I think it would be good to even include a test (within this same test class) which tests the `HttpsServer`.

done

> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 79:
> 
>> 77:             var uri = URIBuilder.newBuilder().scheme("http").loopback().port(server.getAddress().getPort()).path("/chunked").build();
>> 78:             var response = client.send(HttpRequest.newBuilder(uri).build(), HttpResponse.BodyHandlers.ofString());
>> 79:             if(!response.body().equals("hello")) throw new IllegalStateException("incorrect body");
> 
> Same applies here, it would be better to include the failing response body in the exception message.

done

> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 112:
> 
>> 110:             is.close();
>> 111:             rmap.add("content-type","text/plain");
>> 112:             t.sendResponseHeaders(200,0);
> 
> The value 0 and -1 have been a constant confusion in our tests when calling `sendResponseHeaders`. Can you update this line to:
> 
> 
> t.sendResponseHeaders(200, 0 /* chunked */);
> 
> so that it's immediately obvious what the intent here is.

we can fix the test cases with constants after the api change

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579699401
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579698757
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579700904

From dfuchs at openjdk.org  Thu Apr 25 15:52:37 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 25 Apr 2024 15:52:37 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v21]
In-Reply-To: <UNtfmAVfx8ThR66CbTqhPLKufjOA0Y_LtINx6wjg8-M=.63947c8d-aa72-4632-bc95-7f89f4922f82@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <UNtfmAVfx8ThR66CbTqhPLKufjOA0Y_LtINx6wjg8-M=.63947c8d-aa72-4632-bc95-7f89f4922f82@github.com>
Message-ID: <O5H0Aqwn1YheWZipTiizIzn9QZeyRz7f3wMCBe03iao=.308f45d1-b9fe-49c3-9692-3a2d71f3a78e@github.com>

On Thu, 25 Apr 2024 15:24:12 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add https testing

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved.

Is there a reason for changing the copyright year here? I don't see any other change in this file.

src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java line 145:

> 143:             * calling flush to avoid sending small packets
> 144:             */
> 145:             if(count>0) {

Suggestion:

            if (count > 0) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579739244
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579736689

From duke at openjdk.org  Thu Apr 25 15:58:59 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 15:58:59 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v22]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <gF33PEz4aoKRrFac22-blRYfZDFPkmQSd_WoU87hK4E=.b5df1697-749e-49b0-b3e2-792e7aed6543@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/f9bc4e4d..97dc7c22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=20-21

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

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

From duke at openjdk.org  Thu Apr 25 15:58:59 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 15:58:59 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <8WU9R8wRfzcesJh1aMb05npa0q5Sc6zCAqRoWNbJYC0=.639ed5fb-a478-4f3a-8b1c-8512050e22d3@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <towYQknCWAXmwgXg0rE5bU7uqQXIh36CeLpWvFTdOvE=.12e7535e-b3c9-4dec-8e26-8024f88653d6@github.com>
 <9dYpMKxWDf4xqtNJGFgcg7zCrlPhKWjJRtxyBXIpQBI=.66b2e47f-ddc7-4a71-9d0b-cdd6ee3976d3@github.com>
 <bnbR1B3NPLVeBk1N6X1ojdXuV6kbVHX6lgb7FySyjmI=.a90fa916-10af-427d-915a-b4a4a709385c@github.com>
 <gyADz_N5Kw19PXSNVil5sStCs99MNW59mkSWCAjWuJA=.77922f92-9ccc-4bac-82bc-e847d43bb320@github.com>
 <8WU9R8wRfzcesJh1aMb05npa0q5Sc6zCAqRoWNbJYC0=.639ed5fb-a478-4f3a-8b1c-8512050e22d3@github.com>
Message-ID: <e2TH9QK-zM6VMG2LwUe2xg816epEIeTe6LtnJ1-asus=.e57cbd7f-73aa-4f94-a98e-bcf70964c52b@github.com>

On Thu, 25 Apr 2024 14:40:36 GMT, robert engels <duke at openjdk.org> wrote:

>> I?m on mobile now so I haven?t looked at the api - but I think adding default methods like
>> 
>> sendResponseHeadersNoContent(int code)
>> 
>> and OutputStream sendResponseHeadersChunked(int code)
>> 
>> possibly sendResponeWithContent(int code, byte[] data) would also be helpful and cut down to n a lot of usage problems. 
>> 
>> would also make the api easier to use.
>
> I am more than willing to work on an API change PR to add these methods. It is an abstract class, so they could collide with existing code, but I am guessing it is a trivial fix if it does, and it would break at compile time not runtime.
> 
> adding protected constants to the HttpExchange abstract class seems trivially safe.

I created a PR for the api changes https://github.com/openjdk/jdk/pull/18955

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579747981

From duke at openjdk.org  Thu Apr 25 16:02:06 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 16:02:06 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v23]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <91ksqpVNnXAvChubwREBbE3bD9-_YOTVuEBhTZep1S4=.de50976e-a4cc-41b1-8f0d-2e32452b435b@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  use try with resource for HttpClient

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/97dc7c22..61d3f657

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=21-22

  Stats: 24 lines in 1 file changed: 9 ins; 8 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/18667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18667/head:pull/18667

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

From duke at openjdk.org  Thu Apr 25 16:12:13 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 16:12:13 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v24]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <jfvCbnKUJ5t7ZHHa1N36DsJBswiVzr8J9v0e695GPMY=.e8208e3f-256a-4b49-a618-2c36dd967b95@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Revert "update copyright date"
   
   This reverts commit 207a3a92022a38843b340f6a021b74f7e9b50fa6.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/61d3f657..e9ab3a70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=22-23

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

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

From duke at openjdk.org  Thu Apr 25 16:12:14 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 16:12:14 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v23]
In-Reply-To: <91ksqpVNnXAvChubwREBbE3bD9-_YOTVuEBhTZep1S4=.de50976e-a4cc-41b1-8f0d-2e32452b435b@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <91ksqpVNnXAvChubwREBbE3bD9-_YOTVuEBhTZep1S4=.de50976e-a4cc-41b1-8f0d-2e32452b435b@github.com>
Message-ID: <qfc091RePEw-czU5rB7teSb02prVzg4cOa9i3BmS1TU=.3fa485e6-485c-46d9-9299-a20d32bec23f@github.com>

On Thu, 25 Apr 2024 16:02:06 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use try with resource for HttpClient

I created a PR for the related proposed api changes https://github.com/openjdk/jdk/pull/18955

> I created a PR for the related proposed api changes #18955

I don't think I have the ability to create issues, so I can't create one for the api changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2077654265
PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2077657547

From duke at openjdk.org  Thu Apr 25 16:12:15 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 16:12:15 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v21]
In-Reply-To: <O5H0Aqwn1YheWZipTiizIzn9QZeyRz7f3wMCBe03iao=.308f45d1-b9fe-49c3-9692-3a2d71f3a78e@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <UNtfmAVfx8ThR66CbTqhPLKufjOA0Y_LtINx6wjg8-M=.63947c8d-aa72-4632-bc95-7f89f4922f82@github.com>
 <O5H0Aqwn1YheWZipTiizIzn9QZeyRz7f3wMCBe03iao=.308f45d1-b9fe-49c3-9692-3a2d71f3a78e@github.com>
Message-ID: <7RK21ZbTjJgttQXPwV_iG0rvbfX47ICFj3si3pSKX4k=.4b91eba2-417b-4ac7-abbc-f62886748262@github.com>

On Thu, 25 Apr 2024 15:49:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add https testing
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Is there a reason for changing the copyright year here? I don't see any other change in this file.

reverted mistake.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1579759154

From duke at openjdk.org  Thu Apr 25 16:54:55 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 16:54:55 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v25]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <FxsSW7agK9FqGE0U3kWmFIjj3Xs-hEz7QLsGMKbj-Os=.7d6b5368-0f9a-40d4-b472-b8a72723a4c9@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'robaho/B6968351' into B6968351
 - no need for tcp nodelay after this fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/e9ab3a70..e3b9b724

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=23-24

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

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

From duke at openjdk.org  Thu Apr 25 16:58:56 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 16:58:56 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v26]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <jCHqyb9uVBW8AYCwRX60Xthz0-m112PL7BPnfyDG08o=.3cad7a58-d73c-4542-bb1d-4f961a7861c6@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with two additional commits since the last revision:

 - update copyright date
 - update copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/e3b9b724..35a7883b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=24-25

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

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

From duke at openjdk.org  Thu Apr 25 17:01:52 2024
From: duke at openjdk.org (robert engels)
Date: Thu, 25 Apr 2024 17:01:52 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v27]
In-Reply-To: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
Message-ID: <7n50lgkHHIRtXPLa_04hteX1HWQdHT8P8Ti-oOH8QFc=.89d5df73-247f-4852-91ca-eb4b9cf98068@github.com>

> fix bug JDK-B6968351 by avoiding flush after response headers

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  update copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18667/files
  - new: https://git.openjdk.org/jdk/pull/18667/files/35a7883b..f385444f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=25-26

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

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

From michaelm at openjdk.org  Fri Apr 26 08:26:37 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 26 Apr 2024 08:26:37 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <e2TH9QK-zM6VMG2LwUe2xg816epEIeTe6LtnJ1-asus=.e57cbd7f-73aa-4f94-a98e-bcf70964c52b@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <towYQknCWAXmwgXg0rE5bU7uqQXIh36CeLpWvFTdOvE=.12e7535e-b3c9-4dec-8e26-8024f88653d6@github.com>
 <9dYpMKxWDf4xqtNJGFgcg7zCrlPhKWjJRtxyBXIpQBI=.66b2e47f-ddc7-4a71-9d0b-cdd6ee3976d3@github.com>
 <bnbR1B3NPLVeBk1N6X1ojdXuV6kbVHX6lgb7FySyjmI=.a90fa916-10af-427d-915a-b4a4a709385c@github.com>
 <gyADz_N5Kw19PXSNVil5sStCs99MNW59mkSWCAjWuJA=.77922f92-9ccc-4bac-82bc-e847d43bb320@github.com>
 <8WU9R8wRfzcesJh1aMb05npa0q5Sc6zCAqRoWNbJYC0=.639ed5fb-a478-4f3a-8b1c-8512050e22d3@github.com>
 <e2TH9QK-zM6VMG2LwUe2xg816epEIeTe6LtnJ1-asus=.e57cbd7f-73aa-4f94-a98e-bcf70964c52b@github.com>
Message-ID: <zjEABjluSHaWOSIxx8DKHND1IUCCyOgFKIYNNmA1e4Q=.b399c7c5-dd0f-4d70-a887-eb33cf94a654@github.com>

On Thu, 25 Apr 2024 15:55:38 GMT, robert engels <duke at openjdk.org> wrote:

>> I am more than willing to work on an API change PR to add these methods. It is an abstract class, so they could collide with existing code, but I am guessing it is a trivial fix if it does, and it would break at compile time not runtime.
>> 
>> adding protected constants to the HttpExchange abstract class seems trivially safe.
>
> I created a PR for the api changes https://github.com/openjdk/jdk/pull/18955

> I created a PR for the api changes #18955

I am working on a PR with some other API changes. I'd prefer to include this change in that one as well. API changes need to be approved through the CSR process as well as code review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1580665695

From jpai at openjdk.org  Fri Apr 26 09:04:45 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 26 Apr 2024 09:04:45 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <p2ybyhLaZGn-g0c0FaywGgsRKOB5r9e3cvXcYI3l3wc=.084ccb7a-6348-4e78-8e79-1d1a08829d9b@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <CG61hGNkXuzkuWXgWnSo_t_7Hag-zmbgLgs31g8olY4=.21e33a7d-7bac-4bb5-9903-9578d988f8f8@github.com>
 <p2ybyhLaZGn-g0c0FaywGgsRKOB5r9e3cvXcYI3l3wc=.084ccb7a-6348-4e78-8e79-1d1a08829d9b@github.com>
Message-ID: <23ELtIDsuvzyJfQccRZoR63-LcTHvc56VHPZ7azxJ5o=.d1b1c61e-01e8-4a30-a978-0557636009cc@github.com>

On Thu, 25 Apr 2024 15:20:34 GMT, robert engels <duke at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 60:
>> 
>>> 58:         InetAddress loopback = InetAddress.getLoopbackAddress();
>>> 59:         InetSocketAddress addr = new InetSocketAddress (loopback, 0);
>>> 60:         HttpServer server = HttpServer.create (addr, 0);
>> 
>> Given the change we are doing, I think it would be good to even include a test (within this same test class) which tests the `HttpsServer`.
>
> done

Thank you Robert for considering the review comments and updating several parts of this new test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1580717635

From jpai at openjdk.org  Fri Apr 26 09:04:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 26 Apr 2024 09:04:47 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v27]
In-Reply-To: <7n50lgkHHIRtXPLa_04hteX1HWQdHT8P8Ti-oOH8QFc=.89d5df73-247f-4852-91ca-eb4b9cf98068@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <7n50lgkHHIRtXPLa_04hteX1HWQdHT8P8Ti-oOH8QFc=.89d5df73-247f-4852-91ca-eb4b9cf98068@github.com>
Message-ID: <NVCv-j5om-IXApqMezxTz2pTyRxAI6MX78PzWDbjVbQ=.e410ee4c-55e1-4443-971b-209be8245b23@github.com>

On Thu, 25 Apr 2024 17:01:52 GMT, robert engels <duke at openjdk.org> wrote:

>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright date

test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java line 28:

> 26:  * @summary Test to stress directory listings
> 27:  * @library /test/lib
> 28:  * @run testng/othervm/timeout=180 StressDirListings

Hello Varada @varada1110, in https://github.com/openjdk/jdk/pull/17363 this `StressDirListings` test was updated to set the `-Dsun.net.httpserver.nodelay=true` because without it, the test was failing on AIX. The current PR here is proposing to fix the underlying issue in the HttpServer implementation and is rolling back the addition of this system property to this `StressDirListings` test. Could you or someone from the AIX team please build the latest mainline JDK and apply this current PR on top of it and rerun the test(s) to verify that this change is OK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1580714556

From michaelm at openjdk.org  Fri Apr 26 10:15:32 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 26 Apr 2024 10:15:32 GMT
Subject: RFR: 8331063: Some HttpClient tests don't report leaks
In-Reply-To: <tiITLCplsaarDbE8obiNQgyWMJ683s_4K6uEpE38Tx0=.57c6ff8a-7198-48a5-aca5-0c3e10316e4a@github.com>
References: <tiITLCplsaarDbE8obiNQgyWMJ683s_4K6uEpE38Tx0=.57c6ff8a-7198-48a5-aca5-0c3e10316e4a@github.com>
Message-ID: <jn503llmuelfWnA7frIxPvGYh1O8KMsRaRFxhR9waew=.c76c0cfe-2329-442c-9d47-dddcd3ee9f2e@github.com>

On Wed, 24 Apr 2024 16:21:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes leak reporting in `ForbiddenHeadTest.java` and `ProxySelectorTest.java`.
> 
> The tests were checking for leaks, but the detected problems were not reported to the test harness. Additionally, `ForbiddenHeadTest.java` was holding references to the clients, preventing them from being collected by GC.
> 
> The tests continue to pass.

Looks fine.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18938#pullrequestreview-2024668983

From djelinski at openjdk.org  Fri Apr 26 11:05:41 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 26 Apr 2024 11:05:41 GMT
Subject: Integrated: 8331063: Some HttpClient tests don't report leaks
In-Reply-To: <tiITLCplsaarDbE8obiNQgyWMJ683s_4K6uEpE38Tx0=.57c6ff8a-7198-48a5-aca5-0c3e10316e4a@github.com>
References: <tiITLCplsaarDbE8obiNQgyWMJ683s_4K6uEpE38Tx0=.57c6ff8a-7198-48a5-aca5-0c3e10316e4a@github.com>
Message-ID: <7wgiETaOVkaWAltPht4D70jg0AZjD6oZZ1-CfJ2zPL4=.95f50e7d-cbbb-4309-a765-2ce7946eb609@github.com>

On Wed, 24 Apr 2024 16:21:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes leak reporting in `ForbiddenHeadTest.java` and `ProxySelectorTest.java`.
> 
> The tests were checking for leaks, but the detected problems were not reported to the test harness. Additionally, `ForbiddenHeadTest.java` was holding references to the clients, preventing them from being collected by GC.
> 
> The tests continue to pass.

This pull request has now been integrated.

Changeset: e4ed7ced
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4ed7ced75c53cf5ff40c5dae4830b1ee2589802
Stats:     30 lines in 2 files changed: 7 ins; 0 del; 23 mod

8331063: Some HttpClient tests don't report leaks

Reviewed-by: dfuchs, vtewari, michaelm

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

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

From duke at openjdk.org  Fri Apr 26 12:53:36 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 26 Apr 2024 12:53:36 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <zjEABjluSHaWOSIxx8DKHND1IUCCyOgFKIYNNmA1e4Q=.b399c7c5-dd0f-4d70-a887-eb33cf94a654@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <towYQknCWAXmwgXg0rE5bU7uqQXIh36CeLpWvFTdOvE=.12e7535e-b3c9-4dec-8e26-8024f88653d6@github.com>
 <9dYpMKxWDf4xqtNJGFgcg7zCrlPhKWjJRtxyBXIpQBI=.66b2e47f-ddc7-4a71-9d0b-cdd6ee3976d3@github.com>
 <bnbR1B3NPLVeBk1N6X1ojdXuV6kbVHX6lgb7FySyjmI=.a90fa916-10af-427d-915a-b4a4a709385c@github.com>
 <gyADz_N5Kw19PXSNVil5sStCs99MNW59mkSWCAjWuJA=.77922f92-9ccc-4bac-82bc-e847d43bb320@github.com>
 <8WU9R8wRfzcesJh1aMb05npa0q5Sc6zCAqRoWNbJYC0=.639ed5fb-a478-4f3a-8b1c-8512050e22d3@github.com>
 <e2TH9QK-zM6VMG2LwUe2xg816epEIeTe6LtnJ1-asus=.e57cbd7f-73aa-4f94-a98e-bcf70964c52b@github.com>
 <zjEABjluSHaWOSIxx8DKHND1IUCCyOgFKIYNNmA1e4Q=.b399c7c5-dd0f-4d70-a887-eb33cf94a654@github.com>
Message-ID: <932N-_Oj__aI9-JKtF76aK3xRAp35ZpSHXfIjBbG5VA=.e1612da5-9d51-46ab-891a-28f59d0469cb@github.com>

On Fri, 26 Apr 2024 08:23:32 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I created a PR for the api changes https://github.com/openjdk/jdk/pull/18955
>
>> I created a PR for the api changes #18955
> 
> I am working on a PR with some other API changes. I'd prefer to include this change in that one as well. API changes need to be approved through the CSR process as well as code review.

Understood. I only wanted to get down on paper what I proposed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1580992026

From duke at openjdk.org  Fri Apr 26 12:56:42 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 26 Apr 2024 12:56:42 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v17]
In-Reply-To: <23ELtIDsuvzyJfQccRZoR63-LcTHvc56VHPZ7azxJ5o=.d1b1c61e-01e8-4a30-a978-0557636009cc@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <k7KCot3ToNNeOr8w2whnYy6baPGSyUnYqrRdBi5FuUc=.59989bd0-d78a-495c-891e-a716fd9d4aa9@github.com>
 <CG61hGNkXuzkuWXgWnSo_t_7Hag-zmbgLgs31g8olY4=.21e33a7d-7bac-4bb5-9903-9578d988f8f8@github.com>
 <p2ybyhLaZGn-g0c0FaywGgsRKOB5r9e3cvXcYI3l3wc=.084ccb7a-6348-4e78-8e79-1d1a08829d9b@github.com>
 <23ELtIDsuvzyJfQccRZoR63-LcTHvc56VHPZ7azxJ5o=.d1b1c61e-01e8-4a30-a978-0557636009cc@github.com>
Message-ID: <r3ZL0ehyO3j9bQQA34_pO7i783JKc5XANs1S233E8To=.3fb78751-ed50-419b-b4b7-f5e01b5f37d4@github.com>

On Fri, 26 Apr 2024 09:01:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> done
>
> Thank you Robert for considering the review comments and updating several parts of this new test.

You're welcome. Happy to help.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1580995713

From michaelm at openjdk.org  Fri Apr 26 13:33:27 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 26 Apr 2024 13:33:27 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v23]
In-Reply-To: <qfc091RePEw-czU5rB7teSb02prVzg4cOa9i3BmS1TU=.3fa485e6-485c-46d9-9299-a20d32bec23f@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <91ksqpVNnXAvChubwREBbE3bD9-_YOTVuEBhTZep1S4=.de50976e-a4cc-41b1-8f0d-2e32452b435b@github.com>
 <qfc091RePEw-czU5rB7teSb02prVzg4cOa9i3BmS1TU=.3fa485e6-485c-46d9-9299-a20d32bec23f@github.com>
Message-ID: <Mdo36MjvPXwI7VmKHeU8akKV9MUr0AD90RVw8ftHOR0=.ccd1eef2-0b4d-42c2-a6d6-2648203d4238@github.com>

On Thu, 25 Apr 2024 16:08:24 GMT, robert engels <duke at openjdk.org> wrote:

> > I created a PR for the related proposed api changes #18955
> 
> I don't think I have the ability to create issues, so I can't create one for the api changes.

I created a new Jira issue for this. It's at: https://bugs.openjdk.org/browse/JDK-8331195
Can you rename the PR using this issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2079391729

From duke at openjdk.org  Fri Apr 26 14:32:59 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 26 Apr 2024 14:32:59 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v23]
In-Reply-To: <Mdo36MjvPXwI7VmKHeU8akKV9MUr0AD90RVw8ftHOR0=.ccd1eef2-0b4d-42c2-a6d6-2648203d4238@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <91ksqpVNnXAvChubwREBbE3bD9-_YOTVuEBhTZep1S4=.de50976e-a4cc-41b1-8f0d-2e32452b435b@github.com>
 <qfc091RePEw-czU5rB7teSb02prVzg4cOa9i3BmS1TU=.3fa485e6-485c-46d9-9299-a20d32bec23f@github.com>
 <Mdo36MjvPXwI7VmKHeU8akKV9MUr0AD90RVw8ftHOR0=.ccd1eef2-0b4d-42c2-a6d6-2648203d4238@github.com>
Message-ID: <DQwvNWKRogutem9QX1DrwjxPNCrbAhUDg-vcgDNC4Gg=.aa3b3192-4f52-4a86-b78e-b1499c609610@github.com>

On Fri, 26 Apr 2024 13:24:08 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> > > I created a PR for the related proposed api changes #18955
> > 
> > 
> > I don't think I have the ability to create issues, so I can't create one for the api changes.
> 
> I created a new Jira issue for this. It's at: https://bugs.openjdk.org/browse/JDK-8331195 Can you rename the PR using this issue?

done.

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

PR Comment: https://git.openjdk.org/jdk/pull/18667#issuecomment-2079509379

From duke at openjdk.org  Fri Apr 26 14:35:56 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 26 Apr 2024 14:35:56 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange usability
Message-ID: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>

improve the HttpExchange api with documented constants and convenience methods to avoid common bugs

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

Commit messages:
 - improve HttpExchange response api

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

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

From michaelm at openjdk.org  Fri Apr 26 14:59:53 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 26 Apr 2024 14:59:53 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability
In-Reply-To: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
Message-ID: <Eefc_YYg72xucAicZbQkUflCXaG1VhNq6aEHj_hGllU=.bb1fc3cc-3dc8-4bc7-a68f-710ce79f2373@github.com>

On Thu, 25 Apr 2024 15:49:54 GMT, robert engels <duke at openjdk.org> wrote:

> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs

Changes requested by michaelm (Reviewer).

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 74:

> 72: public abstract class HttpExchange implements AutoCloseable, Request {
> 73:     /**
> 74:      * use in sendResponseHeaders() to signify no content in the response.

Suggestion:

     * Use in sendResponseHeaders() to signify no content in the response.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 80:

> 78:     /**
> 79:      * use in sendResponseHeaders() to signify an indeterminate response length. The caller must
> 80:      * close the getResponseBody() or this exchange.

Suggestion:

     * Use in sendResponseHeaders() to signify an indeterminate response length.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 219:

> 217: 
> 218:     /**
> 219:      * convenience method to send a "no content response"

Suggestion:

     * Convenience method to send the response headers with no response body.
     * The exchange is also closed.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 225:

> 223:      */
> 224:     public final void sendResponseHeadersNoContent(int code) throws IOException {
> 225:         sendResponseHeaders(code,NO_CONTENT);

Suggestion:

        sendResponseHeaders(code, NO_CONTENT);
        close();

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 228:

> 226:     }
> 227:     /**
> 228:      * convenience method to send a chunked response. the caller must close the returned output stream.

Suggestion:

     * Convenience method to send a chunked response. The caller must write the response
     * body to the returned output stream and then close it.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 246:

> 244:      * @see HttpExchange#sendResponseHeaders(int, long)
> 245:      */
> 246:     public final void sendResponseHeaders(int code,byte[] data) throws IOException {

I'd prefer to drop this method. Some time in the future we might come up with a better mechanism for handling request and response bodies and translating them to higher level types.

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

PR Review: https://git.openjdk.org/jdk/pull/18955#pullrequestreview-2025238367
PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1581152653
PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1581155836
PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1581146115
PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1581147127
PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1581149586
PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1581152077

From duke at openjdk.org  Fri Apr 26 15:32:15 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 26 Apr 2024 15:32:15 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v2]
In-Reply-To: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
Message-ID: <dN69oACKwVkt7kHBedyiLMU57jjtvIE7DuAWDfFXgXs=.34b1cef6-5b38-4906-8ea3-0bfbb4456e06@github.com>

> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs

robert engels has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
   
   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>
 - Update src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
   
   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>
 - Update src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
   
   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>
 - Update src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
   
   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18955/files
  - new: https://git.openjdk.org/jdk/pull/18955/files/a0a364dd..6bb8d511

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

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

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

From duke at openjdk.org  Fri Apr 26 15:37:13 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 26 Apr 2024 15:37:13 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
Message-ID: <rm4FbsQ1UBpl3308rgme_7CcC63azoPt5fI44wvC4DY=.f233150b-c368-4c6b-87a1-fe519a75d40f@github.com>

> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs

robert engels has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
  
  Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18955/files
  - new: https://git.openjdk.org/jdk/pull/18955/files/6bb8d511..3af58d0c

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

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

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

From duke at openjdk.org  Fri Apr 26 15:37:13 2024
From: duke at openjdk.org (robert engels)
Date: Fri, 26 Apr 2024 15:37:13 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <Eefc_YYg72xucAicZbQkUflCXaG1VhNq6aEHj_hGllU=.bb1fc3cc-3dc8-4bc7-a68f-710ce79f2373@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <Eefc_YYg72xucAicZbQkUflCXaG1VhNq6aEHj_hGllU=.bb1fc3cc-3dc8-4bc7-a68f-710ce79f2373@github.com>
Message-ID: <lJ0LWvOcAqqVYOX09K9eKAdRyAALi5wwLjP4IvHebac=.6aa5d92d-823f-4713-afd0-0989270a6130@github.com>

On Fri, 26 Apr 2024 14:54:30 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>>   
>>   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 246:
> 
>> 244:      * @see HttpExchange#sendResponseHeaders(int, long)
>> 245:      */
>> 246:     public final void sendResponseHeaders(int code,byte[] data) throws IOException {
> 
> I'd prefer to drop this method. Some time in the future we might come up with a better mechanism for handling request and response bodies and translating them to higher level types.

It seems like this is a common source of issues though. If the provided length does not match the actual length of the content sent, the connection is completely borked. Clearly this isn't suitable for large responses, and the chunked should be used in that case, so maybe a note around this?

Even if the higher level types became available it would seem trivial to map this to those - similar to how the BodyHandlers work in HttpClient - common ones are provided - this would use those in reverse.

I don't think it is something to hold up the other changes, but I think it warrants a bit more discussion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1581203326

From varadam at openjdk.org  Fri Apr 26 18:01:00 2024
From: varadam at openjdk.org (Varada M)
Date: Fri, 26 Apr 2024 18:01:00 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v27]
In-Reply-To: <NVCv-j5om-IXApqMezxTz2pTyRxAI6MX78PzWDbjVbQ=.e410ee4c-55e1-4443-971b-209be8245b23@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <7n50lgkHHIRtXPLa_04hteX1HWQdHT8P8Ti-oOH8QFc=.89d5df73-247f-4852-91ca-eb4b9cf98068@github.com>
 <NVCv-j5om-IXApqMezxTz2pTyRxAI6MX78PzWDbjVbQ=.e410ee4c-55e1-4443-971b-209be8245b23@github.com>
Message-ID: <iKwl0d1ICflo5ggOJ5wLKvGsXi31X53MyOA3hNUzy94=.80edc271-e7e3-4f4c-bea0-54f0944301ce@github.com>

On Fri, 26 Apr 2024 08:59:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright date
>
> test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java line 28:
> 
>> 26:  * @summary Test to stress directory listings
>> 27:  * @library /test/lib
>> 28:  * @run testng/othervm/timeout=180 StressDirListings
> 
> Hello Varada @varada1110, in https://github.com/openjdk/jdk/pull/17363 this `StressDirListings` test was updated to set the `-Dsun.net.httpserver.nodelay=true` because without it, the test was failing on AIX. The current PR here is proposing to fix the underlying issue in the HttpServer implementation and is rolling back the addition of this system property to this `StressDirListings` test. Could you or someone from the AIX team please build the latest mainline JDK and apply this current PR on top of it and rerun the test(s) to verify that this change is OK?

Hi @jaikiran, I have performed jtreg test on AIX and all the tests are passing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1581352209

From jpai at openjdk.org  Sat Apr 27 00:53:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 27 Apr 2024 00:53:11 GMT
Subject: RFR: 6968351: httpserver clashes with delayed TCP ACKs for low
 Content-Length [v27]
In-Reply-To: <iKwl0d1ICflo5ggOJ5wLKvGsXi31X53MyOA3hNUzy94=.80edc271-e7e3-4f4c-bea0-54f0944301ce@github.com>
References: <I4t-ojl855lDUKRpwk1DZPuHB3yTY4RWQSx-hfCH-gg=.bb9a49b9-7be1-439b-8e98-dfb04245d3d9@github.com>
 <7n50lgkHHIRtXPLa_04hteX1HWQdHT8P8Ti-oOH8QFc=.89d5df73-247f-4852-91ca-eb4b9cf98068@github.com>
 <NVCv-j5om-IXApqMezxTz2pTyRxAI6MX78PzWDbjVbQ=.e410ee4c-55e1-4443-971b-209be8245b23@github.com>
 <iKwl0d1ICflo5ggOJ5wLKvGsXi31X53MyOA3hNUzy94=.80edc271-e7e3-4f4c-bea0-54f0944301ce@github.com>
Message-ID: <smeyGGBqu8SPJtAe37Sn5J76m8Ok5DkHAwbh5EZMmwI=.9f7367e5-4a39-47d6-bf44-19a9dceeea52@github.com>

On Fri, 26 Apr 2024 17:57:57 GMT, Varada M <varadam at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java line 28:
>> 
>>> 26:  * @summary Test to stress directory listings
>>> 27:  * @library /test/lib
>>> 28:  * @run testng/othervm/timeout=180 StressDirListings
>> 
>> Hello Varada @varada1110, in https://github.com/openjdk/jdk/pull/17363 this `StressDirListings` test was updated to set the `-Dsun.net.httpserver.nodelay=true` because without it, the test was failing on AIX. The current PR here is proposing to fix the underlying issue in the HttpServer implementation and is rolling back the addition of this system property to this `StressDirListings` test. Could you or someone from the AIX team please build the latest mainline JDK and apply this current PR on top of it and rerun the test(s) to verify that this change is OK?
>
> Hi @jaikiran, I have performed jtreg test on AIX and all the tests are passing.

Thank you Varada for running the tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1581643227

From clanger at openjdk.org  Sat Apr 27 10:18:31 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 27 Apr 2024 10:18:31 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v4]
In-Reply-To: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
Message-ID: <SijR7GhkYnMPAYuMxgRWIRGM1T142miK8OHPSWhg84c=.bf411987-0d13-461c-9852-b2c1e3de3c52@github.com>

> While working in that area I found some potential for cleanup of a few tests.
> 
> Most notably:
> 
> B5045306.java:
> - does not need to run in othervm
> - the executor service that it uses should be shut down eventually to free resources
> 
> B8291637.java:
> - use just one instead of two test VM invocations
> KeepAliveTimerThread.java:
> call to grp.destroy() at the end is pointless (API is void & deprecated for removal)
> 
> Generally:
> The deprecated URL constructor is used. It can be switched to the handy URIBuilder
> Some more try with resources here and there

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Fix two URLs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18884/files
  - new: https://git.openjdk.org/jdk/pull/18884/files/a89416f0..42a55baa

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

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

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

From clanger at openjdk.org  Sat Apr 27 13:14:10 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 27 Apr 2024 13:14:10 GMT
Subject: RFR: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest [v7]
In-Reply-To: <t8k5fRZW6E48CQcFee43I4AqtmZD4CBHPwx2-rU_bHs=.e5151d7e-6a93-402f-998a-fa44e4e330c5@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
 <t8k5fRZW6E48CQcFee43I4AqtmZD4CBHPwx2-rU_bHs=.e5151d7e-6a93-402f-998a-fa44e4e330c5@github.com>
Message-ID: <n4H2hg2XokIkuIoVHdMePDL2FfYKutwlvDdmEraHkm0=.75dab225-9df4-4397-86b7-3c5f88eaf910@github.com>

On Thu, 25 Apr 2024 14:58:59 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
>> 
>> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
>> 
>> E.g. on my developer laptop runtime went down from ~100s to ~10s.
>> 
>> I also made additional cleanups/refactoring in the test.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Write server thread code more concisely

Testing looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/18817#issuecomment-2080623719

From clanger at openjdk.org  Sat Apr 27 13:14:12 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 27 Apr 2024 13:14:12 GMT
Subject: Integrated: 8330523: Reduce runtime and improve efficiency of
 KeepAliveTest
In-Reply-To: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
References: <GW-KmoChbaTFFwg5UfwwB-f_ZQX4VcRf499BGyxxZk0=.9194f90f-1383-4db7-a3fd-ac54bb16649f@github.com>
Message-ID: <wRaKVXu2IzA02NKlR0D4UGV2OOozwK7w7YOvw26xA6I=.52cb35e5-8f49-4e20-a297-ccb815400489@github.com>

On Wed, 17 Apr 2024 14:55:02 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more effective.
> 
> It tests a matrix of HTTP client settings and server behavior, resulting in 160 individual test scenarios. Each is tested in an own freshly spawned JVM via the `@run main/othervm` directive. The need for new VMs is due to the fact that the behavior of the HTTP client is determined at VM initialization and can not be changed later on. However, for each distinct type of client settings, one VM can be reused. This would lead us from 160 JVM instantiations down to 16 which has a factor 10 influence on test runtime.
> 
> E.g. on my developer laptop runtime went down from ~100s to ~10s.
> 
> I also made additional cleanups/refactoring in the test.

This pull request has now been integrated.

Changeset: 16c7dcdb
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16c7dcdb04a7c220684a20eb4a0da4505ae03813
Stats:     1230 lines in 1 file changed: 75 ins; 1012 del; 143 mod

8330523: Reduce runtime and improve efficiency of KeepAliveTest

Reviewed-by: djelinski

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

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

From clanger at openjdk.org  Sat Apr 27 13:15:37 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 27 Apr 2024 13:15:37 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v5]
In-Reply-To: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
Message-ID: <lB8KphEAtGUKPXxDx99B6ic4G3e-MVovOkh0bp6x3hk=.7f5ad2a4-4ec6-4d66-b552-305c594e8a09@github.com>

> While working in that area I found some potential for cleanup of a few tests.
> 
> Most notably:
> 
> B5045306.java:
> - does not need to run in othervm
> - the executor service that it uses should be shut down eventually to free resources
> 
> B8291637.java:
> - use just one instead of two test VM invocations
> KeepAliveTimerThread.java:
> call to grp.destroy() at the end is pointless (API is void & deprecated for removal)
> 
> Generally:
> The deprecated URL constructor is used. It can be switched to the handy URIBuilder
> Some more try with resources here and there

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

 - Merge branch 'master' into keepalivetests
 - Fix two URLs
 - Merge branch 'master' into keepalivetests
 - Jaikiran's comments
 - Update test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Copyright year
 - JDK-8330814

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18884/files
  - new: https://git.openjdk.org/jdk/pull/18884/files/42a55baa..4a85d5b8

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

  Stats: 10567 lines in 1231 files changed: 1631 ins; 5919 del; 3017 mod
  Patch: https://git.openjdk.org/jdk/pull/18884.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18884/head:pull/18884

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

From dfuchs at openjdk.org  Tue Apr 30 15:07:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Apr 2024 15:07:06 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v2]
In-Reply-To: <NGjeBHbeDj257yNh8grTAwBZr0oPtwCA92_mRm-fduI=.8892170a-981e-451a-af94-d4c73686c6ee@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
 <GOAuBQOIS7iK0xJda4elHAwNFn-afitGEivmy8d6kBY=.8a3ba309-76b0-44da-b7b1-2aef0a6ef077@github.com>
 <CuZE52vxUNtlN8opChupVxRzbOfB4gQxC-QSnNqUnGo=.185f641b-8486-4e46-90a6-1c3835f37489@github.com>
 <NGjeBHbeDj257yNh8grTAwBZr0oPtwCA92_mRm-fduI=.8892170a-981e-451a-af94-d4c73686c6ee@github.com>
Message-ID: <CC-CSi9J2CtgHCgdZ_HSxYkjqnpklm48w3Ng6gp60_s=.0d019373-a548-4ee6-8818-3a5bf7b02d10@github.com>

On Thu, 25 Apr 2024 08:04:16 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 154:
>> 
>>> 152: 
>>> 153:                     // if Keep-Alive-SocketCleaner consumes more than 50% of cpu then we
>>> 154:                     // can assume a recursive loop.
>> 
>> Interesting test case. I'm a bit surprised we haven't seen this intermittently fail. Speaking of which, I see that the change to this test proposes to remove it from `/othervm` and potentially run it in agent vm mode. Given the kind of checks this test is doing, I think it's better to let it run as a `othervm` test to keep the test as isolated as possible.
>
> I've thought about this, too. However, I see the only critical point why it could merit a `/othervm` test is this thing with querying the thread CPU time of the Keep-Alive-SocketCleaner thread. But I think the likelihood of this failing is the same within standard test and `/othervm`. So I'd prefer to change to standard test, since this is one of the improvements of this change.

The cache is global. Who knows what it might already contain when the test starts and what may be left behind when the test ends. So I agree that it may be prudent to keep `/othervm`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1584992784

From dfuchs at openjdk.org  Tue Apr 30 15:10:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Apr 2024 15:10:06 GMT
Subject: RFR: 8330814: Cleanups for KeepAliveCache tests [v5]
In-Reply-To: <lB8KphEAtGUKPXxDx99B6ic4G3e-MVovOkh0bp6x3hk=.7f5ad2a4-4ec6-4d66-b552-305c594e8a09@github.com>
References: <IG6mLh9VYAYMcfz5m-GVaKfJ0lhiZide7uNtgPifSYw=.46591485-f0b8-4a37-95d9-878f497652e1@github.com>
 <lB8KphEAtGUKPXxDx99B6ic4G3e-MVovOkh0bp6x3hk=.7f5ad2a4-4ec6-4d66-b552-305c594e8a09@github.com>
Message-ID: <gyxOYDDNQrg-XDGKQYMM9WBogb0d6SAl0GQ7kPdjhc8=.b00169a0-8e91-4005-ab7b-f8edd8278f4a@github.com>

On Sat, 27 Apr 2024 13:15:37 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> While working in that area I found some potential for cleanup of a few tests.
>> 
>> Most notably:
>> 
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free resources
>> 
>> B8291637.java:
>> - use just one instead of two test VM invocations
>> KeepAliveTimerThread.java:
>> call to grp.destroy() at the end is pointless (API is void & deprecated for removal)
>> 
>> Generally:
>> The deprecated URL constructor is used. It can be switched to the handy URIBuilder
>> Some more try with resources here and there
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into keepalivetests
>  - Fix two URLs
>  - Merge branch 'master' into keepalivetests
>  - Jaikiran's comments
>  - Update test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Copyright year
>  - JDK-8330814

test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java line 153:

> 151:         }
> 152:         System.out.println("Read " + count);
> 153:         try {

Maybe the `try {` line should be moved just after `server.start()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18884#discussion_r1584997690

From dfuchs at openjdk.org  Tue Apr 30 15:38:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Apr 2024 15:38:06 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <rm4FbsQ1UBpl3308rgme_7CcC63azoPt5fI44wvC4DY=.f233150b-c368-4c6b-87a1-fe519a75d40f@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <rm4FbsQ1UBpl3308rgme_7CcC63azoPt5fI44wvC4DY=.f233150b-c368-4c6b-87a1-fe519a75d40f@github.com>
Message-ID: <wz3_eGSoBOrAXoKtxs5SpVEQHEvm1cS6LDm7nm2rD1Y=.cdd0840b-e78a-4075-af37-6b017500227d@github.com>

On Fri, 26 Apr 2024 15:37:13 GMT, robert engels <duke at openjdk.org> wrote:

>> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>   
>   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 227:

> 225:         sendResponseHeaders(code, NO_CONTENT);
> 226:         close();
> 227:     }

I wonder if this method should better be called `sendResponseNoContent(int code)`; Maybe wait to see if you get further suggestions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1585019573

From dfuchs at openjdk.org  Tue Apr 30 15:38:07 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Apr 2024 15:38:07 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <Eefc_YYg72xucAicZbQkUflCXaG1VhNq6aEHj_hGllU=.bb1fc3cc-3dc8-4bc7-a68f-710ce79f2373@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <Eefc_YYg72xucAicZbQkUflCXaG1VhNq6aEHj_hGllU=.bb1fc3cc-3dc8-4bc7-a68f-710ce79f2373@github.com>
Message-ID: <X--slhwQeyzfLns3LjhgWDB8PBxHq8KYCYqV7PWKrn8=.e6e52101-442f-42eb-9a23-a9cdc6afc971@github.com>

On Fri, 26 Apr 2024 14:54:30 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>>   
>>   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 246:
> 
>> 244:      * @see HttpExchange#sendResponseHeaders(int, long)
>> 245:      */
>> 246:     public final void sendResponseHeaders(int code,byte[] data) throws IOException {
> 
> I'd prefer to drop this method. Some time in the future we might come up with a better mechanism for handling request and response bodies and translating them to higher level types.

If we keep this method then I think it should be named `sendResponse` since it sends the response (and not only the headers). It seems a bit limiting that it requires a single byte array - but on the other hand that's what we use in probably 80% of the tests. On the other hand it seems to promote a single `byte[]` array as first class citizen - and as @Michael-Mc-Mahon  says, that might not be the best choice. Agreed that we can discuss it though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1585055894

From dfuchs at openjdk.org  Tue Apr 30 15:43:07 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Apr 2024 15:43:07 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <rm4FbsQ1UBpl3308rgme_7CcC63azoPt5fI44wvC4DY=.f233150b-c368-4c6b-87a1-fe519a75d40f@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <rm4FbsQ1UBpl3308rgme_7CcC63azoPt5fI44wvC4DY=.f233150b-c368-4c6b-87a1-fe519a75d40f@github.com>
Message-ID: <rNoO3w_4-HJ2cw2x_vUeCMgaw7IHPmrDKOLh9c8NEm8=.f0f547b3-81c6-4d4f-a7be-ab9abaa47f65@github.com>

On Fri, 26 Apr 2024 15:37:13 GMT, robert engels <duke at openjdk.org> wrote:

>> improve the HttpExchange api with documented constants and convenience methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>   
>   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 237:

> 235:      */
> 236:     public final OutputStream sendResponseHeadersChunked(int code) throws IOException {
> 237:         sendResponseHeaders(code,CHUNKED_CONTENT);

I don't like the fact that this methor returns an `OutputStream` when other `sendResponseXxx` methods return `void`. IMO it should either be renamed or the return type changed to `void`, or maybe it should simply be dropped.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1585074446

From duke at openjdk.org  Tue Apr 30 15:58:07 2024
From: duke at openjdk.org (robert engels)
Date: Tue, 30 Apr 2024 15:58:07 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <rNoO3w_4-HJ2cw2x_vUeCMgaw7IHPmrDKOLh9c8NEm8=.f0f547b3-81c6-4d4f-a7be-ab9abaa47f65@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <rm4FbsQ1UBpl3308rgme_7CcC63azoPt5fI44wvC4DY=.f233150b-c368-4c6b-87a1-fe519a75d40f@github.com>
 <rNoO3w_4-HJ2cw2x_vUeCMgaw7IHPmrDKOLh9c8NEm8=.f0f547b3-81c6-4d4f-a7be-ab9abaa47f65@github.com>
Message-ID: <QQulOnNIxRXIBb6jdLwTWYXc1WHSA2SjTE359C3PdL8=.6eb13fbb-3dba-4148-940b-6c803481d14d@github.com>

On Tue, 30 Apr 2024 15:40:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> robert engels has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>>   
>>   Co-authored-by: Michael McMahon <70538289+Michael-Mc-Mahon at users.noreply.github.com>
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 237:
> 
>> 235:      */
>> 236:     public final OutputStream sendResponseHeadersChunked(int code) throws IOException {
>> 237:         sendResponseHeaders(code,CHUNKED_CONTENT);
> 
> I don't like the fact that this methor returns an `OutputStream` when other `sendResponseXxx` methods return `void`. IMO it should either be renamed or the return type changed to `void`, or maybe it should simply be dropped.

The purpose was that if you state you are sending a chunked response, you must close the output stream. By returning it - the linter will catch that it is closed, or used in a try-with-resources.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1585100616

From duke at openjdk.org  Tue Apr 30 16:03:05 2024
From: duke at openjdk.org (robert engels)
Date: Tue, 30 Apr 2024 16:03:05 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <X--slhwQeyzfLns3LjhgWDB8PBxHq8KYCYqV7PWKrn8=.e6e52101-442f-42eb-9a23-a9cdc6afc971@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <Eefc_YYg72xucAicZbQkUflCXaG1VhNq6aEHj_hGllU=.bb1fc3cc-3dc8-4bc7-a68f-710ce79f2373@github.com>
 <X--slhwQeyzfLns3LjhgWDB8PBxHq8KYCYqV7PWKrn8=.e6e52101-442f-42eb-9a23-a9cdc6afc971@github.com>
Message-ID: <GY4uC1OGmY8cD9T6SPsxZv8bKeNMyuw724zOX2ENdgA=.119f0e35-a54a-4c45-8293-381e0f58c39a@github.com>

On Tue, 30 Apr 2024 15:35:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 246:
>> 
>>> 244:      * @see HttpExchange#sendResponseHeaders(int, long)
>>> 245:      */
>>> 246:     public final void sendResponseHeaders(int code,byte[] data) throws IOException {
>> 
>> I'd prefer to drop this method. Some time in the future we might come up with a better mechanism for handling request and response bodies and translating them to higher level types.
>
> If we keep this method then I think it should be named `sendResponse` since it sends the response (and not only the headers). It seems a bit limiting that it requires a single byte array - but on the other hand that's what we use in probably 80% of the tests. On the other hand it seems to promote a single `byte[]` array as first class citizen - and as @Michael-Mc-Mahon  says, that might not be the best choice. Agreed that we can discuss it though.

I think sendResponse() make more sense to me. We could also add a OutputStream sendResponse(int code,int length), and/or add OutputStream sendResponseChunked(int code) and try to break the dependency on the sendResponseHeaders obtuse length parameter.

In reality though, it is either going to be a simple byte array/string, or it is probably best sent using an output stream - and using a fixed length stream for that rather than chunked is inefficient because you need to buffer the entire response (unless you know it ahead of time like in a file transfer) - so that should be avoided.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1585106831

From dfuchs at openjdk.org  Tue Apr 30 16:07:04 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 30 Apr 2024 16:07:04 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <QQulOnNIxRXIBb6jdLwTWYXc1WHSA2SjTE359C3PdL8=.6eb13fbb-3dba-4148-940b-6c803481d14d@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <rm4FbsQ1UBpl3308rgme_7CcC63azoPt5fI44wvC4DY=.f233150b-c368-4c6b-87a1-fe519a75d40f@github.com>
 <rNoO3w_4-HJ2cw2x_vUeCMgaw7IHPmrDKOLh9c8NEm8=.f0f547b3-81c6-4d4f-a7be-ab9abaa47f65@github.com>
 <QQulOnNIxRXIBb6jdLwTWYXc1WHSA2SjTE359C3PdL8=.6eb13fbb-3dba-4148-940b-6c803481d14d@github.com>
Message-ID: <TqF7d8--DEQjvJUH5ybanyqFJCfxZNZjm5pSizCB3w0=.ab780cf4-e463-4980-8906-a5a9dc5242dc@github.com>

On Tue, 30 Apr 2024 15:55:05 GMT, robert engels <duke at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 237:
>> 
>>> 235:      */
>>> 236:     public final OutputStream sendResponseHeadersChunked(int code) throws IOException {
>>> 237:         sendResponseHeaders(code,CHUNKED_CONTENT);
>> 
>> I don't like the fact that this methor returns an `OutputStream` when other `sendResponseXxx` methods return `void`. IMO it should either be renamed or the return type changed to `void`, or maybe it should simply be dropped.
>
> The purpose was that if you state you are sending a chunked response, you must close the output stream. By returning it - the linter will catch that it is closed, or used in a try-with-resources.

I understand - but in this case we need a different (better?) name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1585112476

From duke at openjdk.org  Tue Apr 30 16:32:04 2024
From: duke at openjdk.org (robert engels)
Date: Tue, 30 Apr 2024 16:32:04 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <TqF7d8--DEQjvJUH5ybanyqFJCfxZNZjm5pSizCB3w0=.ab780cf4-e463-4980-8906-a5a9dc5242dc@github.com>
References: <f0K5KXIHRS-zOHX3rnlqIZ-pmRLDhxElR_PW7LC49bc=.35916440-93d1-4f6f-8d44-1bce6f2e1ab4@github.com>
 <rm4FbsQ1UBpl3308rgme_7CcC63azoPt5fI44wvC4DY=.f233150b-c368-4c6b-87a1-fe519a75d40f@github.com>
 <rNoO3w_4-HJ2cw2x_vUeCMgaw7IHPmrDKOLh9c8NEm8=.f0f547b3-81c6-4d4f-a7be-ab9abaa47f65@github.com>
 <QQulOnNIxRXIBb6jdLwTWYXc1WHSA2SjTE359C3PdL8=.6eb13fbb-3dba-4148-940b-6c803481d14d@github.com>
 <TqF7d8--DEQjvJUH5ybanyqFJCfxZNZjm5pSizCB3w0=.ab780cf4-e463-4980-8906-a5a9dc5242dc@github.com>
Message-ID: <WAgNSCeW2cD7AWGoi_ML8bzr_dWA3P3cbCDHcAhNpUI=.44443459-0abe-420e-9ed1-bcf3eeb65145@github.com>

On Tue, 30 Apr 2024 16:04:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The purpose was that if you state you are sending a chunked response, you must close the output stream. By returning it - the linter will catch that it is closed, or used in a try-with-resources.
>
> I understand - but in this case we need a different (better?) name.

I suggested

OutputStream sendResponseChunked(int code)

in the other related comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18955#discussion_r1585166278