From wetmore at openjdk.org  Fri Aug  1 00:43:59 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 1 Aug 2025 00:43:59 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v3]
In-Reply-To: <v08wdQTDWFv-K1M6sGzKSvXh2o_D-We5rRo_UH_UFl0=.88163a58-117f-4121-8b0f-432739578d90@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <v08wdQTDWFv-K1M6sGzKSvXh2o_D-We5rRo_UH_UFl0=.88163a58-117f-4121-8b0f-432739578d90@github.com>
Message-ID: <EaQd4t6jdEt07jF2o51WeTOwtAtkABvmINUE-alL-Cg=.f0a6b2cf-3e22-4fed-b033-65e38a8e5177@github.com>

On Thu, 31 Jul 2025 18:53:20 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Brad's code review

A couple minor fixes.

I'll approve next round.

src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 1101:

> 1099:      * dependent. For example, in TLSv1.3 calling this method after the
> 1100:      * connection has been established will force a key update. For prior TLS
> 1101:      * versions it will force a renegotiation (re-handshake).

You should delete 1115-1116, as it's duplicating what you have here.

src/java.base/share/classes/javax/net/ssl/SSLSocket.java line 520:

> 518:      * to flow during this handshake.  When the handshake completes, this
> 519:      * will be signaled with an event.
> 520:      * <P>

On line 524, put inside a {@code IOException}

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

PR Review: https://git.openjdk.org/jdk/pull/26484#pullrequestreview-3077251110
PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2246633075
PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2246634901

From haosun at openjdk.org  Fri Aug  1 01:07:19 2025
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 1 Aug 2025 01:07:19 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v15]
In-Reply-To: <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
Message-ID: <pYr9JQYqPMwyzKQsUwMen4VUeRivQneH95nccE5T7_g=.aaf8cf9f-b327-4908-a004-6c04e259fc78@github.com>

On Tue, 29 Jul 2025 21:00:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

Hi I found that `test/jdk/javax/management/security/SecurityTest.java` failed after this patch on both AArch64 and x86_64. Filed in https://bugs.openjdk.org/browse/JDK-8364495. I was wondering if you could help take a look at this issue? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-3141799952

From abarashev at openjdk.org  Fri Aug  1 10:15:20 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 10:15:20 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v15]
In-Reply-To: <pYr9JQYqPMwyzKQsUwMen4VUeRivQneH95nccE5T7_g=.aaf8cf9f-b327-4908-a004-6c04e259fc78@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <HuXsWjY3SAI9z6YRIPJeWNJQznPcZPbkG8qgWqRHx70=.20a8dc3f-f721-4a2b-9126-d7cf4c1140ec@github.com>
 <pYr9JQYqPMwyzKQsUwMen4VUeRivQneH95nccE5T7_g=.aaf8cf9f-b327-4908-a004-6c04e259fc78@github.com>
Message-ID: <botxlK5QKf6vhN6fT0_40WWIfSN-8JD3WbHEDhPF_yg=.659ddced-659e-4138-b746-00148eda377d@github.com>

On Fri, 1 Aug 2025 01:04:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

> Hi I found that `test/jdk/javax/management/security/SecurityTest.java` failed after this patch on both AArch64 and x86_64. Filed in https://bugs.openjdk.org/browse/JDK-8364495. I was wondering if you could help take a look at this issue? Thanks.

Hi! It's already fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-3144021668

From abarashev at openjdk.org  Fri Aug  1 15:18:10 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 15:18:10 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v4]
In-Reply-To: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
Message-ID: <hCWwXOG2sFI3tJy8LpXttN51dQZ4j6wbknWX2sYnAis=.8b064316-85ab-42fa-9b0e-b8b3e3c53e25@github.com>

> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Address latest review commants

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26484/files
  - new: https://git.openjdk.org/jdk/pull/26484/files/8cf4e12f..5779ff34

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

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

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

From abarashev at openjdk.org  Fri Aug  1 15:18:11 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 1 Aug 2025 15:18:11 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v3]
In-Reply-To: <EaQd4t6jdEt07jF2o51WeTOwtAtkABvmINUE-alL-Cg=.f0a6b2cf-3e22-4fed-b033-65e38a8e5177@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <v08wdQTDWFv-K1M6sGzKSvXh2o_D-We5rRo_UH_UFl0=.88163a58-117f-4121-8b0f-432739578d90@github.com>
 <EaQd4t6jdEt07jF2o51WeTOwtAtkABvmINUE-alL-Cg=.f0a6b2cf-3e22-4fed-b033-65e38a8e5177@github.com>
Message-ID: <LptKwtgCONpcAkrkVNYkF82fGNmhn9TL54xqwpqHTZ4=.a7b519b5-856c-4fa3-85e3-0c2731cbe118@github.com>

On Fri, 1 Aug 2025 00:39:32 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Brad's code review
>
> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 1101:
> 
>> 1099:      * dependent. For example, in TLSv1.3 calling this method after the
>> 1100:      * connection has been established will force a key update. For prior TLS
>> 1101:      * versions it will force a renegotiation (re-handshake).
> 
> You should delete 1115-1116, as it's duplicating what you have here.

Good catch, done!

> src/java.base/share/classes/javax/net/ssl/SSLSocket.java line 520:
> 
>> 518:      * to flow during this handshake.  When the handshake completes, this
>> 519:      * will be signaled with an event.
>> 520:      * <P>
> 
> On line 524, put inside a {@code IOException}

Done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2248230395
PR Review Comment: https://git.openjdk.org/jdk/pull/26484#discussion_r2248233328

From spurn at amazon.com  Fri Aug  1 15:29:45 2025
From: spurn at amazon.com (Spurling, John)
Date: Fri, 1 Aug 2025 15:29:45 +0000
Subject: Handling multiple in-flight InetAddress.getByName queries for the
 same name at scale
Message-ID: <F82FFD7A-CF48-476D-96E5-A7C849524928@amazon.com>

Large, complicated DNS infrastructure setups coupled with varying application behavior, failure recovery scenarios, and long lived, large scale systems that are slow to migrate can lead to surprising, undesirable behavior when interacting with java.net.InetAddress's implementation of name resolution.

Multiple in-flight requests for the same host using InetAddress.NameServiceAddresses [0] are serialized on a lock [1]. The first request calls the system resolver [2]. Each additional request made before the resolver returns with a response shares the same instance of a NameServiceAddresses, each blocking in InetAdress.NameServiceAddresses.get until it gets the lock. Once all in-flight queries have completed, the InetAddress.NameServiceAddresses dies.

One potential difficulty lies in when the resolver takes longer to complete than the frequency at which name resolution requests are made. Normally, we expect subsequent name resolution requests to take less time than the first request, but that might not be the case. When it isn't, failures can become amplified due to the serialization of all queries on the same host.

Imagine that your DNS infrastructure requires that you disable the networkaddress caches since the minimum enabled value is 1 second, which is too large. If the system resolver takes 1 second, and subsequent resolver calls also take 1 second, and queries are made at a rate of more than one a second, each query will take longer and longer, since each call needs to wait for the resolver to complete, plus the time it spends waiting for the lock. One can see how this might lead to service outages.

There are multiple potential ways to deal with the NameServiceAddresses lock.

One way is to provide finer grained expiry for the cache. Instead of providing the cache timeouts in integer seconds, provide some hook to provide them in milliseconds. Leaving caching enabled but providing smaller timeouts could help provide the right level of control to avoid some of these complicated issues at scale.

Another way is to simply have all in-flight queries return the same result. NameServiceAddresses instances would die more quickly: only the first call to getAddressesFromNameService would be made, the result would be cached in the object. Each subsequent call made during that time would quickly return the result cached in the NameServiceAddresses instance, and the instance would quickly die. New getByName requests would create NameServiceAddresses instances as usual.

Other larger scale rewrites are also possible, but given how battle-tested the current implementation is and the potential dangers here, I imagine something smaller might be more acceptable.

Thoughts?

-john

[0] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/InetAddress.java#L1689C8-L1695C15
[1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/InetAddress.java#L1043
[2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/InetAddress.java#L1060


From ecki at zusammenkunft.net  Fri Aug  1 16:42:55 2025
From: ecki at zusammenkunft.net (ecki)
Date: Fri, 1 Aug 2025 18:42:55 +0200
Subject: Handling multiple in-flight InetAddress.getByName queries for
 the same name at scale
In-Reply-To: <F82FFD7A-CF48-476D-96E5-A7C849524928@amazon.com>
References: <F82FFD7A-CF48-476D-96E5-A7C849524928@amazon.com>
Message-ID: <8F76378C-1390-AB42-9FEC-33B1549D496E@hxcore.ol>

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

From wetmore at openjdk.org  Fri Aug  1 20:13:58 2025
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 1 Aug 2025 20:13:58 GMT
Subject: RFR: 8209992: Align SSLSocket and SSLEngine Javadocs [v4]
In-Reply-To: <hCWwXOG2sFI3tJy8LpXttN51dQZ4j6wbknWX2sYnAis=.8b064316-85ab-42fa-9b0e-b8b3e3c53e25@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
 <hCWwXOG2sFI3tJy8LpXttN51dQZ4j6wbknWX2sYnAis=.8b064316-85ab-42fa-9b0e-b8b3e3c53e25@github.com>
Message-ID: <K7wQuY_8jTVtDX2QMeB_gAqcfg26Y43EBkYszmCGUjU=.bc021f52-137c-4757-b913-bf968db3cb55@github.com>

On Fri, 1 Aug 2025 15:18:10 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address latest review commants

LGTM.  Thanks for the updates.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26484#pullrequestreview-3080451570

From jpai at openjdk.org  Mon Aug  4 12:32:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 4 Aug 2025 12:32:57 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v5]
In-Reply-To: <RtuN1tYoGPnhKaiz_mblX3DMcHWVPTDbF-lmDpFaoXo=.c5e35618-0979-4aa1-91ef-64ffca65ff2c@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <RtuN1tYoGPnhKaiz_mblX3DMcHWVPTDbF-lmDpFaoXo=.c5e35618-0979-4aa1-91ef-64ffca65ff2c@github.com>
Message-ID: <3T0ZQTcLX_nQ4oUiTzQ29txupSdnwn-HzqXUQorcqdY=.5878558f-749f-487d-9a54-40c8ca8ab92d@github.com>

On Wed, 30 Jul 2025 09:32:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review feedback for `FileChannelPublisherTest`

Hello Volkan, the test updates you have done look good to me. I'll need another day or two to go over the javadoc text and one final brief review of the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3150456938

From abarashev at openjdk.org  Mon Aug  4 13:59:03 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 4 Aug 2025 13:59:03 GMT
Subject: Integrated: 8209992: Align SSLSocket and SSLEngine Javadocs
In-Reply-To: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
References: <BSl13LQDEP63KMV3GnP8UnW3JRHyGeLpJyQpMyG_TEc=.08453f36-fbff-42df-af29-f529a19b712e@github.com>
Message-ID: <gxfNgJoKQIV5OanUNCP_fvHt_Zrc-xty888gAzN1knc=.46821ecf-24cb-4952-bd51-e3f267a27d88@github.com>

On Fri, 25 Jul 2025 16:27:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> Add a javadoc paragraph to SSLSocket.startHandshake() and SSLEngine.beginHandshake() methods explaining behavioral differences between TLSv1.3+ and TLSv1.2- versions.

This pull request has now been integrated.

Changeset: 6c52b734
Author:    Artur Barashev <abarashev at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c52b73465b0d0daeafc54c3c6cec3062bf490c5
Stats:     29 lines in 2 files changed: 17 ins; 3 del; 9 mod

8209992: Align SSLSocket and SSLEngine Javadocs

Reviewed-by: wetmore

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

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

From vyazici at openjdk.org  Tue Aug  5 10:33:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 5 Aug 2025 10:33:46 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v6]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <BNyl_bylEFuLmk6SzmvKujegcw-hOChFiqNdURvCyOM=.c60a91ee-875d-4a80-85b7-f6ac93c1e0b2@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Verify exceptions using both `send()` and `sendAsync()`
 - Replace usage of `CompletableFuture` with `Future`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/99503c0b..faa5d24d

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

  Stats: 108 lines in 1 file changed: 89 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/26155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26155/head:pull/26155

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

From vyazici at openjdk.org  Tue Aug  5 10:43:08 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 5 Aug 2025 10:43:08 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v4]
In-Reply-To: <nnyrhqHZXLgdqW13aYbz8puCM688BbdDLxZi0AwKGLQ=.8d5938ba-b88f-4b88-98af-71ae35253beb@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <ZoDc14hgR41eB1PCypu7ZuAv8zwVHGEhEja9FS3vE4U=.98b780a6-49a7-4f75-9517-ce82f06d8db4@github.com>
 <NQ8GkzuYvVUmP6CrBT61yjTt0B90nDKaPgX8rgG-zoE=.e56b58ef-1d46-4ba5-b413-7927bfbbf370@github.com>
 <iivI8nKd-hVeQbv0zFmP21yvLxFCGMBxMgbtpriiqlQ=.d0b9abe7-f6d3-4412-9177-281054c61c2a@github.com>
 <eXsopp9trwJc8k2e1uNXU_fLscncMF9g1MLiL4wXNJQ=.b9111198-bbf1-41e6-900f-9852eb8178eb@github.com>
 <7j14xvrLzetod3mICHEFATv0_oAB101fSyPCo8asYcc=.2775daeb-0166-4118-9cc4-b7a2345843b7@github.com>
 <nnyrhqHZXLgdqW13aYbz8puCM688BbdDLxZi0AwKGLQ=.8d5938ba-b88f-4b88-98af-71ae35253beb@github.com>
Message-ID: <Xbo6yctJXAJThffoCF5IBvsfryuUIpxplvlpn8QSnlY=.a897afa9-c5d5-43d2-bc31-cfe481f058e5@github.com>

On Thu, 31 Jul 2025 06:30:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> add a test which uses send()

@jaikiran, in faa5d24d831, I've adapted all exception verification tests to take both `send()` and `sendAsync()` into account.

>  both send() and sendAsync() should propagate the same exception

Right. I will discuss this with @dfuch and @Michael-Mc-Mahon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2253945179

From vyazici at openjdk.org  Tue Aug  5 11:27:16 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 5 Aug 2025 11:27:16 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v7]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Revert the last commit: faa5d24d831
  
  The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/faa5d24d..c8a0257a

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

  Stats: 104 lines in 1 file changed: 8 ins; 88 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26155.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26155/head:pull/26155

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

From dfuchs at openjdk.org  Tue Aug  5 14:35:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 5 Aug 2025 14:35:06 GMT
Subject: RFR: 8352502: Response message is null if expect 100 assertion
 fails with non 100 [v3]
In-Reply-To: <irAM7GphyMXZ5917QklArwZwvx7bTxb2-t0O0BHcp6Y=.d18d1a4a-bed5-4b4f-bc44-9e3d3cfd739c@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
 <irAM7GphyMXZ5917QklArwZwvx7bTxb2-t0O0BHcp6Y=.d18d1a4a-bed5-4b4f-bc44-9e3d3cfd739c@github.com>
Message-ID: <m9B4hrFKZUvMzzuV2z4SuRAdqomfQLdc5nWweQybnrs=.e5a0c19e-5b98-454b-8768-2f8c3046d451@github.com>

On Thu, 10 Jul 2025 13:28:26 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
>> 
>> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
>> 
>> I also added a test to cover some possible responses.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding salting and path verification to test

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25999#pullrequestreview-3088574176

From dfuchs at openjdk.org  Tue Aug  5 19:17:35 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 5 Aug 2025 19:17:35 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v12]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <SCsRMYq_YcUXak0vqS9nds-o8JCzef-RS8XmXCWqxkk=.422e19d8-d034-4bd4-a925-63f242f7734c@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 588 commits:

 - merge latest changes from master branch
 - qpack: modify Encoder.header to use DT lock, test headers cleanup.
 - merge latest from master branch
 - merge latest from master branch
 - Include peer's error information in exceptions thrown on connection close
 - Fix error IDs
 - Remove assertion error
 - Remove assertion errors from packet encryption
 - Remove assertion errors from retry packet handling
 - Remove assertion errors from initial key derivation
 - ... and 578 more: https://git.openjdk.org/jdk/compare/d906e450...83f8dad1

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

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=11
  Stats: 105164 lines in 470 files changed: 102303 ins; 1335 del; 1526 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

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

From jpai at openjdk.org  Fri Aug  8 07:00:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 07:00:29 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently fails
 - 24999 handled, expected 25000
Message-ID: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>

Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.

As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.

The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.

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

Commit messages:
 - close the server Executor and thus wait for the HttpHandler(s) to complete before asserting on the counter
 - general clean up and some logging

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

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

From alanb at openjdk.org  Fri Aug  8 07:41:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Aug 2025 07:41:12 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000
In-Reply-To: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
Message-ID: <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>

On Fri, 8 Aug 2025 06:52:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
> 
> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
> 
> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.

test/jdk/java/net/vthread/HttpALot.java line 36:

> 34: import java.util.concurrent.atomic.AtomicInteger;
> 35: import com.sun.net.httpserver.HttpServer;
> 36: import jdk.test.lib.net.URIBuilder;

Did you mean to move the imports? Just curious as I usually put the test description at the top to make it easy to find, I guess others prefer it after the imports.

test/jdk/java/net/vthread/HttpALot.java line 98:

> 96:         // go
> 97:         server.start();
> 98:         try (serverExecutor) {

This part looks good, as does checking that the task result is "Hello" as that adds more checking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262171408
PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262178653

From jpai at openjdk.org  Fri Aug  8 07:45:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 07:45:11 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000
In-Reply-To: <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
Message-ID: <4prrMb_Zq50pD9tSlXGQT78DNv8sTtJciKuxbyHvKuI=.3c629f78-97dd-41db-ba17-bcf44f88899b@github.com>

On Fri, 8 Aug 2025 07:34:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
>> 
>> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
>> 
>> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.
>
> test/jdk/java/net/vthread/HttpALot.java line 36:
> 
>> 34: import java.util.concurrent.atomic.AtomicInteger;
>> 35: import com.sun.net.httpserver.HttpServer;
>> 36: import jdk.test.lib.net.URIBuilder;
> 
> Did you mean to move the imports? Just curious as I usually put the test description at the top to make it easy to find, I guess others prefer it after the imports.

Hello Alan, I will undo that part. I usually prefer the test definition directly above the class declaration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262185675

From jpai at openjdk.org  Fri Aug  8 07:57:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 07:57:57 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v2]
In-Reply-To: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
Message-ID: <Gq52iVy41lubhPIc0VNBHOu1u3E1zhs_fVwlEGK6ewc=.c4453d83-2299-4f9c-8183-d8d325e753cf@github.com>

> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
> 
> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
> 
> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.

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

  Alan's review - move the test definition back to before the imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26686/files
  - new: https://git.openjdk.org/jdk/pull/26686/files/efdbbbb9..30044906

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

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

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

From alanb at openjdk.org  Fri Aug  8 07:57:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Aug 2025 07:57:57 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v2]
In-Reply-To: <4prrMb_Zq50pD9tSlXGQT78DNv8sTtJciKuxbyHvKuI=.3c629f78-97dd-41db-ba17-bcf44f88899b@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
 <4prrMb_Zq50pD9tSlXGQT78DNv8sTtJciKuxbyHvKuI=.3c629f78-97dd-41db-ba17-bcf44f88899b@github.com>
Message-ID: <7ek13N74iXl2ez8IHQuX4a5LLSSO0UbC_cu4nYtyjNc=.b156132d-6d23-4a75-a379-50cd5ddae67c@github.com>

On Fri, 8 Aug 2025 07:42:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/net/vthread/HttpALot.java line 36:
>> 
>>> 34: import java.util.concurrent.atomic.AtomicInteger;
>>> 35: import com.sun.net.httpserver.HttpServer;
>>> 36: import jdk.test.lib.net.URIBuilder;
>> 
>> Did you mean to move the imports? Just curious as I usually put the test description at the top to make it easy to find, I guess others prefer it after the imports.
>
> Hello Alan, I will undo that part. I usually prefer the test definition directly above the class declaration.

It's okay, I was just trying to see if the test description was changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262200974

From jpai at openjdk.org  Fri Aug  8 07:57:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 07:57:58 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v2]
In-Reply-To: <7ek13N74iXl2ez8IHQuX4a5LLSSO0UbC_cu4nYtyjNc=.b156132d-6d23-4a75-a379-50cd5ddae67c@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
 <4prrMb_Zq50pD9tSlXGQT78DNv8sTtJciKuxbyHvKuI=.3c629f78-97dd-41db-ba17-bcf44f88899b@github.com>
 <7ek13N74iXl2ez8IHQuX4a5LLSSO0UbC_cu4nYtyjNc=.b156132d-6d23-4a75-a379-50cd5ddae67c@github.com>
Message-ID: <gcYmchR1P84UXpFBxavUXwkJ1hRsWlfviLrd86dno-w=.3c2b8d1f-1485-4c23-a47a-0a1465af841e@github.com>

On Fri, 8 Aug 2025 07:48:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hello Alan, I will undo that part. I usually prefer the test definition directly above the class declaration.
>
> It's okay, I was just trying to see if the test description was changed.

I just happened to revert this part in the PR :) So I'll let it be before the imports, like it was before. No changes to the `@test` definition, except replacing `/**` with the recommended `/*`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262208088

From dfuchs at openjdk.org  Fri Aug  8 09:05:11 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 8 Aug 2025 09:05:11 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v2]
In-Reply-To: <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
Message-ID: <VJlvKHI5xWindjQETozq36wR4qwAHXa5j4UbZwG4n7U=.17ced730-aa3b-44ae-b4b5-6cd39d928fee@github.com>

On Fri, 8 Aug 2025 07:38:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alan's review - move the test definition back to before the imports
>
> test/jdk/java/net/vthread/HttpALot.java line 98:
> 
>> 96:         // go
>> 97:         server.start();
>> 98:         try (serverExecutor) {
> 
> This part looks good, as does checking that the task result is "Hello" as that adds more checking.

It would be more correct to close the server executor after server.stop() returns, to make sure the server will not try to use the executor after it's closed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262373491

From jpai at openjdk.org  Fri Aug  8 09:21:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 09:21:59 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
Message-ID: <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>

> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
> 
> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
> 
> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.

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

  Daniel's review - close the server Executor after server.stop()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26686/files
  - new: https://git.openjdk.org/jdk/pull/26686/files/30044906..fd5298ca

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

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

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

From jpai at openjdk.org  Fri Aug  8 09:21:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 09:21:59 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <VJlvKHI5xWindjQETozq36wR4qwAHXa5j4UbZwG4n7U=.17ced730-aa3b-44ae-b4b5-6cd39d928fee@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <Y4XcSFhve0NXCqC-DD9qHGL6mwuyEMVM1w1joSO8Ojc=.4588f331-a6a7-4e54-9a91-97748760514c@github.com>
 <VJlvKHI5xWindjQETozq36wR4qwAHXa5j4UbZwG4n7U=.17ced730-aa3b-44ae-b4b5-6cd39d928fee@github.com>
Message-ID: <q-2_RUFVzYMLUPXp4_YXM8--M6022P7NsIKPbK0aZ_0=.b396ca5f-f1f5-48c2-b1c9-5b4462c18af1@github.com>

On Fri, 8 Aug 2025 09:02:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/vthread/HttpALot.java line 98:
>> 
>>> 96:         // go
>>> 97:         server.start();
>>> 98:         try (serverExecutor) {
>> 
>> This part looks good, as does checking that the task result is "Hello" as that adds more checking.
>
> It would be more correct to close the server executor after server.stop() returns, to make sure the server will not try to use the executor after it's closed.

Done. I've updated the PR to close the executor after the server is stopped.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26686#discussion_r2262407890

From dfuchs at openjdk.org  Fri Aug  8 09:50:10 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 8 Aug 2025 09:50:10 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
Message-ID: <QBz73txRAswN3EFNWRm25i2rFQaK0wPAm_In3n5d7XQ=.844be743-7ec3-4eab-8b0b-985ea8646f3a@github.com>

On Fri, 8 Aug 2025 09:21:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
>> 
>> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
>> 
>> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - close the server Executor after server.stop()

Thanks Jaikiran! Looks good to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26686#pullrequestreview-3100176836

From alanb at openjdk.org  Fri Aug  8 10:32:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Aug 2025 10:32:11 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
Message-ID: <EcFjKANyVet1aYiRDaWCLGyxO3gAi3oxA_890R8DGYc=.3fa7843c-56ed-418b-8d97-c2c474c42531@github.com>

On Fri, 8 Aug 2025 09:21:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
>> 
>> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
>> 
>> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - close the server Executor after server.stop()

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26686#pullrequestreview-3100287567

From vyazici at openjdk.org  Fri Aug  8 12:12:16 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 8 Aug 2025 12:12:16 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
Message-ID: <4sleDanLsDaAWOPXMMQr97C-2BtimzsBBpnJgxYCcfQ=.908102c0-9f17-45db-abfc-d15b48653843@github.com>

On Fri, 8 Aug 2025 09:21:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
>> 
>> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
>> 
>> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - close the server Executor after server.stop()

Marked as reviewed by vyazici (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26686#pullrequestreview-3100570151

From jpai at openjdk.org  Fri Aug  8 13:34:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 13:34:52 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List
Message-ID: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>

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

`java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.

The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.

I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.

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

Commit messages:
 - 8365086: CookieStore.getURIs() and get(URI) should return an immutable List
 - 8365086: add a test

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

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

From vyazici at openjdk.org  Fri Aug  8 14:11:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 8 Aug 2025 14:11:11 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List
In-Reply-To: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
Message-ID: <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>

On Fri, 8 Aug 2025 13:28:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
> 
> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
> 
> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
> 
> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.

Marked as reviewed by vyazici (Committer).

test/jdk/java/net/CookieStoreTest.java line 45:

> 43:  * @run junit CookieStoreTest
> 44:  */
> 45: class CookieStoreTest {

Otherwise you get a warning that the comment block should start with a `/**`:

Suggestion:


class CookieStoreTest {

test/jdk/java/net/CookieStoreTest.java line 110:

> 108:         // an element must fail
> 109:         assertThrows(UnsupportedOperationException.class, () -> cookies.add(cookie));
> 110:         assertThrows(UnsupportedOperationException.class, () -> cookies.remove(cookie));

Nit: You can consider factoring this out to a `assertCookieStoreIsImmutable(CookieStore)` method.

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

PR Review: https://git.openjdk.org/jdk/pull/26698#pullrequestreview-3100989703
PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263087979
PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263088219

From jpai at openjdk.org  Fri Aug  8 14:21:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 14:21:13 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List
In-Reply-To: <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
Message-ID: <GFhyCQmZO3GS7VZM1iWHzmFyyonyczNC997YbSq6IA0=.fb64fcf0-f934-4a2a-9c60-d37cd906d67d@github.com>

On Fri, 8 Aug 2025 14:07:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
>> 
>> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
>> 
>> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
>> 
>> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.
>
> test/jdk/java/net/CookieStoreTest.java line 45:
> 
>> 43:  * @run junit CookieStoreTest
>> 44:  */
>> 45: class CookieStoreTest {
> 
> Otherwise you get a warning that the comment block should start with a `/**`:
> 
> Suggestion:
> 
> 
> class CookieStoreTest {

Hello Volkan, is that warning generated by a IDE? I don't see it in IntelliJ:

<img width="704" height="192" alt="ide" src="https://github.com/user-attachments/assets/b45345a2-343a-49ea-ab82-47bd40e6b87d" />

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263124441

From jpai at openjdk.org  Fri Aug  8 14:36:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 14:36:17 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
Message-ID: <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
> 
> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
> 
> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
> 
> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.

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

  Volkan's review - refactor assertions into a method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26698/files
  - new: https://git.openjdk.org/jdk/pull/26698/files/914fde9a..7b92b0a6

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

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

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

From jpai at openjdk.org  Fri Aug  8 14:36:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Aug 2025 14:36:18 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
Message-ID: <nb5_qJTv1PEHVPANPI9HmAAde22psPiLi3iBFYtUACs=.1b58b456-7d70-4526-bbd3-2227a00243a4@github.com>

On Fri, 8 Aug 2025 14:07:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Volkan's review - refactor assertions into a method
>
> test/jdk/java/net/CookieStoreTest.java line 110:
> 
>> 108:         // an element must fail
>> 109:         assertThrows(UnsupportedOperationException.class, () -> cookies.add(cookie));
>> 110:         assertThrows(UnsupportedOperationException.class, () -> cookies.remove(cookie));
> 
> Nit: You can consider factoring this out to a `assertCookieStoreIsImmutable(CookieStore)` method.

Done. I've moved couple of those assertions to a separate method to be called from each of these test methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263151177

From dfuchs at openjdk.org  Fri Aug  8 14:50:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 8 Aug 2025 14:50:15 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
Message-ID: <-wQhKp-Z2OMwDYlop0KiJUIznsIX1Gr3xJRtURrzXX8=.3320e978-4cd2-4f99-9ec9-2f57076c8664@github.com>

On Fri, 8 Aug 2025 14:36:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
>> 
>> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
>> 
>> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
>> 
>> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Volkan's review - refactor assertions into a method

LGTM. It may be useful to plan a release note, in case an application is depending on being able to add/remove stuff to/from the returned list, despite the documentation stating they should be immutable. For instance - an application may attempt to clear() the returned list.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26698#pullrequestreview-3101122892

From liach at openjdk.org  Fri Aug  8 17:21:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:21:19 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <GFhyCQmZO3GS7VZM1iWHzmFyyonyczNC997YbSq6IA0=.fb64fcf0-f934-4a2a-9c60-d37cd906d67d@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
 <GFhyCQmZO3GS7VZM1iWHzmFyyonyczNC997YbSq6IA0=.fb64fcf0-f934-4a2a-9c60-d37cd906d67d@github.com>
Message-ID: <VbnzY-bfsCQ9LL8NPyUUsV5MzCKyRmkUuwdo9KllhG4=.fd72a940-e302-4b22-b4fc-c26f9f93389d@github.com>

On Fri, 8 Aug 2025 14:18:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/net/CookieStoreTest.java line 45:
>> 
>>> 43:  * @run junit CookieStoreTest
>>> 44:  */
>>> 45: class CookieStoreTest {
>> 
>> Otherwise you get a warning that the comment block should start with a `/**`:
>> 
>> Suggestion:
>> 
>> 
>> class CookieStoreTest {
>
> Hello Volkan, is that warning generated by a IDE? I don't see it in IntelliJ:
> 
> <img width="704" height="192" alt="ide" src="https://github.com/user-attachments/assets/b45345a2-343a-49ea-ab82-47bd40e6b87d" />

I think we usually put the jtreg directive block before the imports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263621068

From liach at openjdk.org  Fri Aug  8 17:21:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:21:20 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
Message-ID: <X8PGgJJzisRXKIoWPIS56FW1hB2hsjfbBFKUME0V2vw=.5c92593f-e7f5-4c43-b54a-d298e6b91d65@github.com>

On Fri, 8 Aug 2025 14:36:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
>> 
>> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
>> 
>> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
>> 
>> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Volkan's review - refactor assertions into a method

test/jdk/java/net/CookieStoreTest.java line 107:

> 105:         // an element must fail
> 106:         assertThrows(UnsupportedOperationException.class, () -> list.add(elementToAddOrRemove));
> 107:         assertThrows(UnsupportedOperationException.class, () -> list.remove(elementToAddOrRemove));

I think trying `list.set` would be meaningful too, given `Arrays.asList` would pass these two tests but is actually mutable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2263622701

From jpai at openjdk.org  Sat Aug  9 02:04:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 9 Aug 2025 02:04:26 GMT
Subject: RFR: 8364786: Test java/net/vthread/HttpALot.java intermittently
 fails - 24999 handled, expected 25000 [v3]
In-Reply-To: <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
 <ieuUYCreTbw9DjOS7fjETMge_6rnrJqNmEWB13c0uL0=.ba9cc8e0-9f55-4cad-8917-724db280e3b1@github.com>
Message-ID: <x5yVGdewwDHTeU2tq3C8h7nxjLsI-n-RDOlZcxbtNDA=.bf3677bd-d849-4527-aae2-b01b9562c38a@github.com>

On Fri, 8 Aug 2025 09:21:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
>> 
>> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
>> 
>> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - close the server Executor after server.stop()

Thank you all for the reviews. tier testing and repeat testing of this change passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26686#issuecomment-3169642053

From jpai at openjdk.org  Sat Aug  9 02:04:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 9 Aug 2025 02:04:27 GMT
Subject: Integrated: 8364786: Test java/net/vthread/HttpALot.java
 intermittently fails - 24999 handled, expected 25000
In-Reply-To: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
References: <D_R3ctPGvWV-tUdHYE1_g-Dmn97Q_USDRC2QVC0lQE4=.a15ade46-8e46-46b6-b75c-2ebc30fbae60@github.com>
Message-ID: <KdvfPYhesxPa69HpZaXgiAc90ndFjQCvWtqBSgzSBhs=.93e62818-bc83-4d43-b62f-fd53f61190df@github.com>

On Fri, 8 Aug 2025 06:52:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to fix an intermittent failure in that test? This addresses https://bugs.openjdk.org/browse/JDK-8364786.
> 
> As noted in that issue, the test fails because the main thread doesn't wait for the server side HttpHandler instances to return from the handle() method. There are 2 commits in this PR - one is general clean up and additional logging and the second one is the actual fix where we `close()` the server side `Executor` before asserting a counter state in the main thread. Closing the server side `Executor` waits till the HttpHandler instances return from their handle() method and thus prevents these intermittent test failures.
> 
> The reporter of the JBS issue has tested this proposed fix in their setup and the test no longer fails. I have also triggered a test repeat (and tier testing) for this change in our CI.

This pull request has now been integrated.

Changeset: f83454cd
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f83454cd61538b653656ccf81759b3cc7286ed67
Stats:     33 lines in 1 file changed: 19 ins; 2 del; 12 mod

8364786: Test java/net/vthread/HttpALot.java intermittently fails - 24999 handled, expected 25000

Reviewed-by: dfuchs, alanb, vyazici

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

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

From vyazici at openjdk.org  Sat Aug  9 09:19:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Sat, 9 Aug 2025 09:19:11 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <VbnzY-bfsCQ9LL8NPyUUsV5MzCKyRmkUuwdo9KllhG4=.fd72a940-e302-4b22-b4fc-c26f9f93389d@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
 <GFhyCQmZO3GS7VZM1iWHzmFyyonyczNC997YbSq6IA0=.fb64fcf0-f934-4a2a-9c60-d37cd906d67d@github.com>
 <VbnzY-bfsCQ9LL8NPyUUsV5MzCKyRmkUuwdo9KllhG4=.fd72a940-e302-4b22-b4fc-c26f9f93389d@github.com>
Message-ID: <woBZ0kFiXUbvKdKddVi6jBaQZKWqtZRwkjonFSvTOro=.754a6851-d4a3-4294-9d0e-2a96cee36936@github.com>

On Fri, 8 Aug 2025 17:17:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hello Volkan, is that warning generated by a IDE? I don't see it in IntelliJ:
>> 
>> <img width="704" height="192" alt="ide" src="https://github.com/user-attachments/assets/b45345a2-343a-49ea-ab82-47bd40e6b87d" />
>
> I think we usually put the jtreg directive block before the imports.

> Is that warning generated by a IDE? I don't see it in IntelliJ:

@jaikiran, I remember seeing it highlighted somewhere, but apparently I am mistaken. Nevermind. It is all good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2264622780

From jpai at openjdk.org  Sat Aug  9 12:07:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 9 Aug 2025 12:07:00 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v3]
In-Reply-To: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
Message-ID: <ZpPMfMjL6gj-GULeNKOSrpdvADsMRQB-BaYX77tzgTQ=.4ddaf66f-a296-40bf-b339-2e3c17498023@github.com>

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
> 
> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
> 
> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
> 
> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.

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

  Chen's review - verify List.set() fails too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26698/files
  - new: https://git.openjdk.org/jdk/pull/26698/files/7b92b0a6..f6ff8fa0

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

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

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

From jpai at openjdk.org  Sat Aug  9 12:07:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 9 Aug 2025 12:07:01 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v3]
In-Reply-To: <woBZ0kFiXUbvKdKddVi6jBaQZKWqtZRwkjonFSvTOro=.754a6851-d4a3-4294-9d0e-2a96cee36936@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <Cr7F97rkzkAAfC0pqMiI8IgMVPr7-mSOyrX2ocNHMUQ=.e8e5ce6b-f090-4181-ae67-11d7f3124700@github.com>
 <GFhyCQmZO3GS7VZM1iWHzmFyyonyczNC997YbSq6IA0=.fb64fcf0-f934-4a2a-9c60-d37cd906d67d@github.com>
 <VbnzY-bfsCQ9LL8NPyUUsV5MzCKyRmkUuwdo9KllhG4=.fd72a940-e302-4b22-b4fc-c26f9f93389d@github.com>
 <woBZ0kFiXUbvKdKddVi6jBaQZKWqtZRwkjonFSvTOro=.754a6851-d4a3-4294-9d0e-2a96cee36936@github.com>
Message-ID: <gJdi42BHTkz2okVYtN9NvCdxuyCMTvYHd5DKQamXFC0=.6a41ca6f-92f9-4675-9523-55e323d2deb9@github.com>

On Sat, 9 Aug 2025 09:16:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> I think we usually put the jtreg directive block before the imports.
>
>> Is that warning generated by a IDE? I don't see it in IntelliJ:
> 
> @jaikiran, I remember seeing it highlighted somewhere, but apparently I am mistaken. Nevermind. It is all good.

Hello Chen,

> I think we usually put the jtreg directive block before the imports.

It's a mix of before imports and above the class declaration in the JDK repo. I personally prefer just above the class since it's easily visible. Several of the tests in the networking area follow this currently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2264684264

From jpai at openjdk.org  Sat Aug  9 12:07:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 9 Aug 2025 12:07:01 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <X8PGgJJzisRXKIoWPIS56FW1hB2hsjfbBFKUME0V2vw=.5c92593f-e7f5-4c43-b54a-d298e6b91d65@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
 <X8PGgJJzisRXKIoWPIS56FW1hB2hsjfbBFKUME0V2vw=.5c92593f-e7f5-4c43-b54a-d298e6b91d65@github.com>
Message-ID: <qfcYiSLocxiWaLfwSDqCx53oyAVazxXhknyeYFmQubk=.08b8c723-0441-46d7-bca5-e49c86d356e5@github.com>

On Fri, 8 Aug 2025 17:18:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Volkan's review - refactor assertions into a method
>
> test/jdk/java/net/CookieStoreTest.java line 107:
> 
>> 105:         // an element must fail
>> 106:         assertThrows(UnsupportedOperationException.class, () -> list.add(elementToAddOrRemove));
>> 107:         assertThrows(UnsupportedOperationException.class, () -> list.remove(elementToAddOrRemove));
> 
> I think trying `list.set` would be meaningful too, given `Arrays.asList` would pass these two tests but is actually mutable.

Done. I've updated the PR to include that additional check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26698#discussion_r2264683740

From swen at openjdk.org  Sat Aug  9 13:03:13 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 13:03:13 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v7]
In-Reply-To: <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
Message-ID: <YF_peW1FnQw4S6PccLilUtHw8i0tYRtiy3Fqun00Z6Q=.b6523457-db6d-40ae-ae5a-2baea10f1806@github.com>

On Tue, 5 Aug 2025 11:27:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the last commit: faa5d24d831
>   
>   The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.

src/java.net.http/share/classes/java/net/http/HttpRequest.java line 755:

> 753:          */
> 754:         public static BodyPublisher ofFileChannel(FileChannel channel, long offset, long length) throws IOException {
> 755:             Objects.requireNonNull(channel, "channel");

public FileChannelPublisher(FileChannel channel, long offset, long length) throws IOException {
            this.channel = Objects.requireNonNull(channel, "channel");
            // ...

The FileChannelPublisher constructor already has a null value check for the parameter channel, which is redundant

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2264700495

From swen at openjdk.org  Sat Aug  9 13:06:12 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 13:06:12 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v7]
In-Reply-To: <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
Message-ID: <DUILTpCU-z6q2hgVyS80iNQfz5-IIaLhfyeL2p-4e40=.41dc9020-350f-47c2-b6fe-eb959045b202@github.com>

On Tue, 5 Aug 2025 11:27:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the last commit: faa5d24d831
>   
>   The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.

src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 368:

> 366: 
> 367:     public static IllegalArgumentException newIAE(String message, Object... args) {
> 368:         return new IllegalArgumentException(format(message, args));

Suggestion:

        return new IllegalArgumentException(message.formatted(args));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2264701010

From swen at openjdk.org  Sat Aug  9 13:10:15 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 9 Aug 2025 13:10:15 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v7]
In-Reply-To: <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
Message-ID: <pv7A3zwuvix5P9yKLBbbwNstHVsOsHyTxSxnffHkVag=.d2b62a8d-fdfd-4230-8623-7cfaddae77d3@github.com>

On Tue, 5 Aug 2025 11:27:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the last commit: faa5d24d831
>   
>   The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.

test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 105:

> 103:     private static final ServerRequestPair HTTP2 = ServerRequestPair.of(Version.HTTP_2, false);
> 104: 
> 105:     private static final ServerRequestPair HTTPS2 = ServerRequestPair.of(Version.HTTP_2, true);

Suggestion:

    private static final ServerRequestPair 
            HTTP1  = ServerRequestPair.of(Version.HTTP_1_1, false), 
            HTTPS1 = ServerRequestPair.of(Version.HTTP_1_1, true),
            HTTP2  = ServerRequestPair.of(Version.HTTP_2, false),
            HTTPS2 = ServerRequestPair.of(Version.HTTP_2, true);

This coding style can be considered for declaring multiple consecutive fields of the same type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2264701902

From liach at openjdk.org  Sat Aug  9 13:13:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 9 Aug 2025 13:13:11 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v3]
In-Reply-To: <ZpPMfMjL6gj-GULeNKOSrpdvADsMRQB-BaYX77tzgTQ=.4ddaf66f-a296-40bf-b339-2e3c17498023@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <ZpPMfMjL6gj-GULeNKOSrpdvADsMRQB-BaYX77tzgTQ=.4ddaf66f-a296-40bf-b339-2e3c17498023@github.com>
Message-ID: <QuDJ57zfKor2PosrVzRlWOqZiNJyDYqOmiDJSgKTF_I=.67b8a46c-a9a3-464c-abfc-6de12f961265@github.com>

On Sat, 9 Aug 2025 12:07:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
>> 
>> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
>> 
>> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
>> 
>> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's review - verify List.set() fails too

Code alone looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26698#pullrequestreview-3102952053

From jpai at openjdk.org  Sun Aug 10 04:18:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 10 Aug 2025 04:18:17 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v2]
In-Reply-To: <-wQhKp-Z2OMwDYlop0KiJUIznsIX1Gr3xJRtURrzXX8=.3320e978-4cd2-4f99-9ec9-2f57076c8664@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <_5JgON9h8m_NG0bn0V2mSO0qGQRuHG4WeK4X-4tIGy0=.499d6c41-2043-4e0e-b546-43e04c07377a@github.com>
 <-wQhKp-Z2OMwDYlop0KiJUIznsIX1Gr3xJRtURrzXX8=.3320e978-4cd2-4f99-9ec9-2f57076c8664@github.com>
Message-ID: <htmBs7DL04WkUDOdmRqynXi-rvY8WHoJqLUZvNiNguY=.6a679df9-871a-45dc-ac79-5e80c1c8f8ed@github.com>

On Fri, 8 Aug 2025 14:47:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> It may be useful to plan a release note, in case an application is depending on being able to add/remove stuff to/from the returned list, despite the documentation stating they should be immutable. For instance - an application may attempt to clear() the returned list.

I've now marked the issue with `release-note=yes`. I'll create one shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26698#issuecomment-3172353023

From jpai at openjdk.org  Sun Aug 10 04:22:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 10 Aug 2025 04:22:15 GMT
Subject: RFR: 8365086: CookieStore.getURIs() and get(URI) should return an
 immutable List [v3]
In-Reply-To: <ZpPMfMjL6gj-GULeNKOSrpdvADsMRQB-BaYX77tzgTQ=.4ddaf66f-a296-40bf-b339-2e3c17498023@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
 <ZpPMfMjL6gj-GULeNKOSrpdvADsMRQB-BaYX77tzgTQ=.4ddaf66f-a296-40bf-b339-2e3c17498023@github.com>
Message-ID: <L9YlTNHP2tkVJDH8DOSt8BplyYjmS8MUb9nq4EzdGbg=.9c425e4b-3efc-4a4b-8f46-058e02086899@github.com>

On Sat, 9 Aug 2025 12:07:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
>> 
>> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
>> 
>> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
>> 
>> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's review - verify List.set() fails too

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26698#issuecomment-3172355060

From jpai at openjdk.org  Sun Aug 10 04:25:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 10 Aug 2025 04:25:22 GMT
Subject: Integrated: 8365086: CookieStore.getURIs() and get(URI) should return
 an immutable List
In-Reply-To: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
References: <xa_D4jTrNLuvIm65ssfvgtnAGX3Mo73BZ3UmRQd_OPE=.36a099df-c2b0-449a-92f4-56a0be5af03f@github.com>
Message-ID: <a7pa2GOG9f1QU3zxKJ-zJejUidXPZRF8DPCezqUF1MM=.7f1c1251-d673-4e04-bac1-3ce31957dc72@github.com>

On Fri, 8 Aug 2025 13:28:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8365086?
> 
> `java.net.CookieStore` has some APIs which return a `java.util.List`. These API are specified to return an immutable `List`. The JDK ships an implementation of the `CookieStore` - the `java.net.InMemoryCookieStore`. The implementations of the `getURIs()` and `get(URI)` methods  in the `InMemoryCookieStore` currently return a `List` which is modifiable.
> 
> The changes in this PR fix those two method to return an immutable `List` to match the specification. A new regression test has been introduced to reproduce the issue and verify the fix.
> 
> I think this may not require a CSR since this fixes the implementation to match the already existing specification in `CookieStore`. I will create one if anyone suggests we should.

This pull request has now been integrated.

Changeset: 022e29a7
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/022e29a77533aacabd56820d00ecffa9646a8362
Stats:     127 lines in 2 files changed: 119 ins; 4 del; 4 mod

8365086: CookieStore.getURIs() and get(URI) should return an immutable List

Reviewed-by: liach, vyazici, dfuchs

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

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

From vyazici at openjdk.org  Mon Aug 11 07:47:03 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 07:47:03 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v8]
In-Reply-To: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
Message-ID: <rRmsqMqDtcwMpU52rkou98OEkEDQZGEIK1bFAVdBijA=.38b6db88-cf6c-4a35-904a-eb36dbf8e4c3@github.com>

> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
> 
>> The file channel will not be closed upon completion. The caller is
>> expected to manage the life cycle of the channel, and close it
>> appropriately when not needed anymore.
> 
> ### Implementation notes
> 
> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Improve style for declaring multiple consecutive fields of the same type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26155/files
  - new: https://git.openjdk.org/jdk/pull/26155/files/c8a0257a..91d3422c

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

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

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

From vyazici at openjdk.org  Mon Aug 11 07:47:07 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 11 Aug 2025 07:47:07 GMT
Subject: RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel
 method [v7]
In-Reply-To: <YF_peW1FnQw4S6PccLilUtHw8i0tYRtiy3Fqun00Z6Q=.b6523457-db6d-40ae-ae5a-2baea10f1806@github.com>
References: <mHxAEFIjVCVvcFb0ApzcbhU0OmO81F1btpg_b4U-1k8=.552f2da9-e7cb-4206-b995-e0fac61b4276@github.com>
 <-sb4AkUVzeIHUo_Aq30bpxunVrDgjEBseviicW_NHCo=.345046be-9fa2-4ca9-adc7-74800924783e@github.com>
 <YF_peW1FnQw4S6PccLilUtHw8i0tYRtiy3Fqun00Z6Q=.b6523457-db6d-40ae-ae5a-2baea10f1806@github.com>
Message-ID: <umPS0ggHDeGzyR_h4AG11OCnJQ_Ps0Zkzuo2B8ss8NI=.7d837c92-e1ec-434a-befa-48241bf3535e@github.com>

On Sat, 9 Aug 2025 13:00:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert the last commit: faa5d24d831
>>   
>>   The `send()`-vs-`sendAsync()` discrepancy will be addressed separately.
>
> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 755:
> 
>> 753:          */
>> 754:         public static BodyPublisher ofFileChannel(FileChannel channel, long offset, long length) throws IOException {
>> 755:             Objects.requireNonNull(channel, "channel");
> 
> public FileChannelPublisher(FileChannel channel, long offset, long length) throws IOException {
>             this.channel = Objects.requireNonNull(channel, "channel");
>             // ...
> 
> The FileChannelPublisher constructor already has a null value check for the parameter channel, which is redundant

We should raise an exception at the API boundary, hence this check. Why didn't I validate `offset` and `length` here too? Because doing so would expose implementation details in the interface. Why did I add an extra null check in `FCP::new`? That's also an API boundary, but an internal one. Naturally, these practices can vary depending on performance considerations.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 368:
> 
>> 366: 
>> 367:     public static IllegalArgumentException newIAE(String message, Object... args) {
>> 368:         return new IllegalArgumentException(format(message, args));
> 
> Suggestion:
> 
>         return new IllegalArgumentException(message.formatted(args));

While I agree with your reasoning, it is out of the scope of this work.

For the record, I really like `String::formatted`! Yet one should try to avoid it if the associated changes might need to be backported. ?

> test/jdk/java/net/httpclient/FileChannelPublisherTest.java line 105:
> 
>> 103:     private static final ServerRequestPair HTTP2 = ServerRequestPair.of(Version.HTTP_2, false);
>> 104: 
>> 105:     private static final ServerRequestPair HTTPS2 = ServerRequestPair.of(Version.HTTP_2, true);
> 
> Suggestion:
> 
>     private static final ServerRequestPair 
>             HTTP1  = ServerRequestPair.of(Version.HTTP_1_1, false), 
>             HTTPS1 = ServerRequestPair.of(Version.HTTP_1_1, true),
>             HTTP2  = ServerRequestPair.of(Version.HTTP_2, false),
>             HTTPS2 = ServerRequestPair.of(Version.HTTP_2, true);
> 
> This coding style can be considered for declaring multiple consecutive fields of the same type.

Applied in 91d3422. (Did not commit your suggestion due to the _"vertical alignment"_ you employed in the variable names. It is impossible to adhere to in the long run, see `vmIntrinsics.hpp` for an example.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2265922312
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2265925853
PR Review Comment: https://git.openjdk.org/jdk/pull/26155#discussion_r2265925993

From dclarke at openjdk.org  Mon Aug 11 12:00:28 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Mon, 11 Aug 2025 12:00:28 GMT
Subject: Integrated: 8352502: Response message is null if expect 100 assertion
 fails with non 100
In-Reply-To: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
Message-ID: <KqVh71p4CIDSuQtRizKMWpwVy7EbPFUzEl0uqLa0xuM=.36f1fd2c-0313-467a-b445-ac2463952e9e@github.com>

On Thu, 26 Jun 2025 10:48:56 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
> 
> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
> 
> I also added a test to cover some possible responses.

This pull request has now been integrated.

Changeset: 43cfd80c
Author:    Darragh Clarke <dclarke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43cfd80c1c0493f2f50ffd75461ca75a002e0127
Stats:     205 lines in 3 files changed: 205 ins; 0 del; 0 mod

8352502: Response message is null if expect 100 assertion fails with non 100

Reviewed-by: dfuchs

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

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

From myankelevich at openjdk.org  Mon Aug 11 15:45:17 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Mon, 11 Aug 2025 15:45:17 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v5]
In-Reply-To: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
Message-ID: <aeHaJTVJlvrY6CCK0qfFSFxaq_nBa0N97mX497y7azk=.9c2ab6bc-e9d8-4de9-8dba-1ff272ccae81@github.com>

> * fully automated the test
> * removed the race condition
> * client on a thread and server on a thread options are now run together automatically

Mikhail Yankelevich 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 JDK-8249824
 - cleanup and update of the code to the current style
 - minor comment changes
 - Apply suggestions from cr
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - JDK-8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid
   
   * fully automated the test
   * removed the race condition
   * client on a thread and server on a thread options are now run together automatically

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23469/files
  - new: https://git.openjdk.org/jdk/pull/23469/files/2bff4a34..ad0e7f3b

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

  Stats: 792793 lines in 10957 files changed: 358230 ins; 363171 del; 71392 mod
  Patch: https://git.openjdk.org/jdk/pull/23469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23469/head:pull/23469

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

From duke at openjdk.org  Tue Aug 12 03:09:22 2025
From: duke at openjdk.org (jwilliams990)
Date: Tue, 12 Aug 2025 03:09:22 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

Hi, Which version of OpenJDK is this change available in? I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177373009

From jpai at openjdk.org  Tue Aug 12 03:52:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Aug 2025 03:52:18 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
Message-ID: <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>

On Tue, 12 Aug 2025 01:13:57 GMT, jwilliams990 <duke at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - include a test for AsynchronousServerSocketChannel
>>  - System.err instead of System.out
>>  - trim down code comment
>>  -  > 200 instead of >= 200
>
> Hi, Which version of OpenJDK is this change available in? I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).

Hello @jwilliams990 

> Hi, Which version of OpenJDK is this change available in?

This change is currently in the unreleased Java 26 version. It's only available in 26 early access builds https://jdk.java.net/26/ or one has to manually build this JDK repo to use this feature. 

> I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).

Linux too has a limit on the number of backlog connections. I don't know the details of the issue you are running into but it could be unrelated to trying to use a backlog value greater than 200 on Windows, when creating a `ServerSocket`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177598778

From duke at openjdk.org  Tue Aug 12 03:59:24 2025
From: duke at openjdk.org (jwilliams990)
Date: Tue, 12 Aug 2025 03:59:24 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
 <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
Message-ID: <DYkbYAMHfryi3IeoXOSWR6qOc44I8XtFQE-jPvZBc-4=.64ede2db-a757-4d32-bbf1-76a3ee574ce3@github.com>

On Tue, 12 Aug 2025 03:49:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi, Which version of OpenJDK is this change available in? I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
>
> Hello @jwilliams990 
> 
>> Hi, Which version of OpenJDK is this change available in?
> 
> This change is currently in the unreleased Java 26 version. It's only available in 26 early access builds https://jdk.java.net/26/ or one has to manually build this JDK repo to use this feature. 
> 
>> I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
> 
> Linux too has a limit on the number of backlog connections. I don't know the details of the issue you are running into but it could be unrelated to trying to use a backlog value greater than 200 on Windows, when creating a `ServerSocket`.

Hi @jaikiran, Thanks for your response. Any chance this could be included in Java 21 LTS in the future? 

The default TCP backlog in Windows is 200. Linux has a default of 4096. The issue i am seeing is when running Apache Tomcat on Windows vs. Linux, Windows shows a very high percentage of connection refused errors vs. Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177608798

From jpai at openjdk.org  Tue Aug 12 04:27:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Aug 2025 04:27:16 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
 <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
Message-ID: <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>

On Tue, 12 Aug 2025 03:49:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi, Which version of OpenJDK is this change available in? I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
>
> Hello @jwilliams990 
> 
>> Hi, Which version of OpenJDK is this change available in?
> 
> This change is currently in the unreleased Java 26 version. It's only available in 26 early access builds https://jdk.java.net/26/ or one has to manually build this JDK repo to use this feature. 
> 
>> I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
> 
> Linux too has a limit on the number of backlog connections. I don't know the details of the issue you are running into but it could be unrelated to trying to use a backlog value greater than 200 on Windows, when creating a `ServerSocket`.

> Hi @jaikiran, Thanks for your response. Any chance this could be included in Java 21 LTS in the future?

Backports to OpenJDK are managed by a separate "jdk-updates" project https://openjdk.org/projects/jdk-updates/. Members of that project decide which changes should be backported (and when).

For this specific change, Java 26 release isn't scheduled for this year. Once it is released and after that version sees usage in real world applications, only then enhancements like these are usually considered for backports. So it's too early to say if/when this change will be backported.

In the meantime, what would be good is if you suspect that the backlog limit is indeed causing this issue on your setup, you could try to use the 26 early access build which is available here https://jdk.java.net/26/ and see if that helps you get past this issue. Are you creating a ServerSocket (or some other construct?) with some explicit value for backlog that is greater than 200?

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177649481

From duke at openjdk.org  Tue Aug 12 04:33:16 2025
From: duke at openjdk.org (jwilliams990)
Date: Tue, 12 Aug 2025 04:33:16 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
 <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
 <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>
Message-ID: <Ft4ycpQmPofFhAHzt_Jz1JtHNqQ1heFJoEcdxMTLfV8=.ca558ed0-26fe-494c-b2fd-39f414e1161c@github.com>

On Tue, 12 Aug 2025 04:24:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello @jwilliams990 
>> 
>>> Hi, Which version of OpenJDK is this change available in?
>> 
>> This change is currently in the unreleased Java 26 version. It's only available in 26 early access builds https://jdk.java.net/26/ or one has to manually build this JDK repo to use this feature. 
>> 
>>> I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
>> 
>> Linux too has a limit on the number of backlog connections. I don't know the details of the issue you are running into but it could be unrelated to trying to use a backlog value greater than 200 on Windows, when creating a `ServerSocket`.
>
>> Hi @jaikiran, Thanks for your response. Any chance this could be included in Java 21 LTS in the future?
> 
> Backports to OpenJDK are managed by a separate "jdk-updates" project https://openjdk.org/projects/jdk-updates/. Members of that project decide which changes should be backported (and when).
> 
> For this specific change, Java 26 release isn't scheduled for this year. Once it is released and after that version sees usage in real world applications, only then enhancements like these are usually considered for backports. So it's too early to say if/when this change will be backported.
> 
> In the meantime, what would be good is if you suspect that the backlog limit is indeed causing this issue on your setup, you could try to use the 26 early access build which is available here https://jdk.java.net/26/ and see if that helps you get past this issue. Are you creating a ServerSocket (or some other construct?) with some explicit value for backlog that is greater than 200?

Hi @jaikiran, I am running Apache Tomcat on Java. Tomcat has an acceptCount set to a large number (greater than 200). I believe Tomcat creates a ServerSocket with the configured acceptCount, and I suspect that it is not effective on Windows for the reasons mentioned above in this trail.

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177657942

From jpai at openjdk.org  Tue Aug 12 04:45:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Aug 2025 04:45:16 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
 <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
 <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>
Message-ID: <r8MGdbeP-bXkjYUbj2l5MVBqjL_N8FAZrS2LKlTbqBI=.d3145098-81b1-4586-a26c-065a87368442@github.com>

On Tue, 12 Aug 2025 04:24:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello @jwilliams990 
>> 
>>> Hi, Which version of OpenJDK is this change available in?
>> 
>> This change is currently in the unreleased Java 26 version. It's only available in 26 early access builds https://jdk.java.net/26/ or one has to manually build this JDK repo to use this feature. 
>> 
>>> I am running into a situation where Java on Windows drops TCP/HTTP connections, but i don't have this issue on Linux (I have tested with JDK 21.0.8+9).
>> 
>> Linux too has a limit on the number of backlog connections. I don't know the details of the issue you are running into but it could be unrelated to trying to use a backlog value greater than 200 on Windows, when creating a `ServerSocket`.
>
>> Hi @jaikiran, Thanks for your response. Any chance this could be included in Java 21 LTS in the future?
> 
> Backports to OpenJDK are managed by a separate "jdk-updates" project https://openjdk.org/projects/jdk-updates/. Members of that project decide which changes should be backported (and when).
> 
> For this specific change, Java 26 release isn't scheduled for this year. Once it is released and after that version sees usage in real world applications, only then enhancements like these are usually considered for backports. So it's too early to say if/when this change will be backported.
> 
> In the meantime, what would be good is if you suspect that the backlog limit is indeed causing this issue on your setup, you could try to use the 26 early access build which is available here https://jdk.java.net/26/ and see if that helps you get past this issue. Are you creating a ServerSocket (or some other construct?) with some explicit value for backlog that is greater than 200?

> Hi @jaikiran, I am running Apache Tomcat on Java. Tomcat has an acceptCount set to a large number (greater than 200). I believe Tomcat creates a ServerSocket with the configured acceptCount, and I suspect that it is not effective on Windows for the reasons mentioned above in this trail.

Thank you for that detail, that's useful to know. Based on what you note and what's documented of that Connector attribute in Tomcat docs - https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Attributes_Standard%20Implementation_acceptCount, I think what you are suggesting is correct - the backlog might be playing a role here.

If you get a chance to try this with Java 26 early access build, that would be a good experiment to verify that this change does indeed help this use case (I'll be curious to hear how that test goes).

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3177673220

From vyazici at openjdk.org  Tue Aug 12 08:51:25 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 12 Aug 2025 08:51:25 GMT
Subject: RFR: 8249824:
 s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o
 bugid [v5]
In-Reply-To: <aeHaJTVJlvrY6CCK0qfFSFxaq_nBa0N97mX497y7azk=.9c2ab6bc-e9d8-4de9-8dba-1ff272ccae81@github.com>
References: <CE8I1O5MaS9Uz4VL8x0j3Y-5X5-oUqrakWzxjDKAJSk=.00d6d7ab-02c1-4d46-b34d-b9a59da50c7e@github.com>
 <aeHaJTVJlvrY6CCK0qfFSFxaq_nBa0N97mX497y7azk=.9c2ab6bc-e9d8-4de9-8dba-1ff272ccae81@github.com>
Message-ID: <gn8O8KFqnSncx5RR95m6kT1a-5zUO1_E_kRDFLdnOKE=.9ca84ed4-484e-4dd7-a69d-9c05f21dd8ed@github.com>

On Mon, 11 Aug 2025 15:45:17 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> * fully automated the test
>> * removed the race condition
>> * client on a thread and server on a thread options are now run together automatically
>
> Mikhail Yankelevich 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 JDK-8249824
>  - cleanup and update of the code to the current style
>  - minor comment changes
>  - Apply suggestions from cr
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - JDK-8249824: s/n/w/p/https/HttpsURLConnection/CloseKeepAliveCached.java uses @ignore w/o bugid
>    
>    * fully automated the test
>    * removed the race condition
>    * client on a thread and server on a thread options are now run together automatically

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 32:

> 30:  *
> 31:  * @run main/othervm -Dtest.separateThreads=true CloseKeepAliveCached false
> 32:  * @run main/othervm -Dtest.separateThreads=true CloseKeepAliveCached true

If `test.separateThreads` is always `true`, can we remove this property completely?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 106:

> 104:          */
> 105:         serverReady = true;
> 106:         SSLSocket sslSocket = (SSLSocket) sslServerSocket.accept();

One can say it is a matter of preference, but wrapping all `AutoCloseable`'s (`SSLServerSocket`, `SSLSocket`, `InputStream`, etc.) in a try-with-resources will help with ensuring all resources are correctly closed.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 120:

> 118:             String x;
> 119:             while ((x = r.readLine()) != null) {
> 120:                 if (x.isEmpty()) {

I guess this can be simplified to `while ((x = r.readLine()) != null && !x.isEmpty())`.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 135:

> 133:             out.flush();
> 134: 
> 135:             Thread.sleep(50);

Curious: Why do we need this?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 164:

> 162:             HttpsURLConnection.setDefaultHostnameVerifier(new NameVerifier());
> 163:             http = (HttpsURLConnection) url.openConnection();
> 164:             InputStream is = http.getInputStream();

See my comment above regarding `InputStream` and try-with-resources.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java line 316:

> 314:     void startServer(boolean newThread) throws Exception {
> 315:         if (newThread) {
> 316:             serverThread = new Thread(() -> {

Nit: Unsolicited style changes can obstruct backporting and decrease version control hygiene. (This comment applies to changes starting from line 338 too.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269086136
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269093354
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269096196
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269097406
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269113381
PR Review Comment: https://git.openjdk.org/jdk/pull/23469#discussion_r2269149826

From duke at openjdk.org  Tue Aug 12 15:29:22 2025
From: duke at openjdk.org (jwilliams990)
Date: Tue, 12 Aug 2025 15:29:22 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <r8MGdbeP-bXkjYUbj2l5MVBqjL_N8FAZrS2LKlTbqBI=.d3145098-81b1-4586-a26c-065a87368442@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <dvC1yoBB4BGOI_mkI1HUChns0zahMyaB0--ZAUzT3vw=.f96e9628-e9c5-4409-ba40-8742e2007b43@github.com>
 <AZS4tsFgRD447rNUfoGNz45BJbXeEnvUWNxEFzxsTi0=.0f6d5066-8409-4fd8-928c-d9ff25bd015f@github.com>
 <KSv6nlwpBobDAmHtjePHjQZ76cy1A4eOVb6aiThRYoQ=.d19ce3f6-3303-4cc8-a5e7-f590891bb44e@github.com>
 <r8MGdbeP-bXkjYUbj2l5MVBqjL_N8FAZrS2LKlTbqBI=.d3145098-81b1-4586-a26c-065a87368442@github.com>
Message-ID: <_AytxIFrh0G0z7OHW1VfdBLoSvh6N-38vamSjR-GJRM=.7bbebcae-28a0-4caf-9e22-e0d7ba2b443b@github.com>

On Tue, 12 Aug 2025 04:41:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Hi @jaikiran, Thanks for your response. Any chance this could be included in Java 21 LTS in the future?
>> 
>> Backports to OpenJDK are managed by a separate "jdk-updates" project https://openjdk.org/projects/jdk-updates/. Members of that project decide which changes should be backported (and when).
>> 
>> For this specific change, Java 26 release isn't scheduled for this year. Once it is released and after that version sees usage in real world applications, only then enhancements like these are usually considered for backports. So it's too early to say if/when this change will be backported.
>> 
>> In the meantime, what would be good is if you suspect that the backlog limit is indeed causing this issue on your setup, you could try to use the 26 early access build which is available here https://jdk.java.net/26/ and see if that helps you get past this issue. Are you creating a ServerSocket (or some other construct?) with some explicit value for backlog that is greater than 200?
>
>> Hi @jaikiran, I am running Apache Tomcat on Java. Tomcat has an acceptCount set to a large number (greater than 200). I believe Tomcat creates a ServerSocket with the configured acceptCount, and I suspect that it is not effective on Windows for the reasons mentioned above in this trail.
> 
> Thank you for that detail, that's useful to know. Based on what you note and what's documented of that Connector attribute in Tomcat docs - https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Attributes_Standard%20Implementation_acceptCount, I think what you are suggesting is correct - the backlog might be playing a role here.
> 
> If you get a chance to try this with Java 26 early access build, that would be a good experiment to verify that this change does indeed help this use case (I'll be curious to hear how that test goes).

Hi @jaikiran - I have tested with the Java 26 early access build and can report that the issue i faced on Windows OS with TCP/HTTP connection refused errors even at relatively low concurrency has been resolved in this build. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3179832921

From jpai at openjdk.org  Tue Aug 12 15:38:24 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 12 Aug 2025 15:38:24 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <azFWNc1DtZlf8oZBzEiavOHQmiyoDnr5Zs_PA8RaaGk=.4c8b9f33-805e-4889-ba3b-29f4bf19c9f4@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

Thank you very much for running the test and reporting back. It's pleasing to hear that this enhancement addresses a genuine issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3179884608

From lkorinth at openjdk.org  Tue Aug 12 17:09:32 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 12 Aug 2025 17:09:32 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
Message-ID: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>

This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).

My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have ploughed through test cases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

After the review, I will update the copyrights.

I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

I got 4 timing related faults:
1) runtime/Thread/TestThreadDumpMonitorContention.java
   This is probably: https://bugs.openjdk.org/browse/JDK-8361370
2) sun/tools/jhsdb/BasicLauncherTest.java
   I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
3) gc/stress/TestReclaimStringsLeaksMemory.java
   I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
4) sun/security/ssl/X509KeyManager/CertChecking.java
   This is a new test that I got on last rebase. I have added a timeout of 480 to it.

In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.

>From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of default timeout factor", I have taken a few actions:
1) in testing(md|html): interpreted mode -> forced compilation mode
2) in MTTest.java: changed 1200 -> 400 (was 300 to begin with)

I am now re-running tier 1-8.

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

Commit messages:
 - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1

Changes: https://git.openjdk.org/jdk/pull/26749/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8260555
  Stats: 598 lines in 297 files changed: 49 ins; 91 del; 458 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

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

From cjplummer at openjdk.org  Tue Aug 12 17:54:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Aug 2025 17:54:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> sun/tools/jhsdb/BasicLauncherTest.java
> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.

@lkorinth Can you send me a link to the failure?

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3180396310

From syan at openjdk.org  Wed Aug 13 01:50:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:50:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Should we need to update the copyright year for the touch files

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271883564

From syan at openjdk.org  Wed Aug 13 01:54:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:54:16 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:

> 27:  * @requires vm.debug
> 28:  * @summary Test running with StressRecompilation enabled.
> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation

I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.


> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
55:elapsed time (seconds): 0.581
66:elapsed time (seconds): 0.575
116:elapsed time (seconds): 3.088
162:elapsed time (seconds): 0.001
173:elapsed time (seconds): 11.546

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271888024

From sspitsyn at openjdk.org  Wed Aug 13 07:29:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 07:29:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

I've reviewed the Serviceability related tweaks and I'm okay with them in general.
But I'm curious if you do not see any timeouts with this anymore.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3114280042

From aturbanov at openjdk.org  Wed Aug 13 09:47:17 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Aug 2025 09:47:17 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/langtools/tools/lib/toolbox/ToolBox.java line 480:

> 478: 
> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;

Suggestion:

    private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2272745651

From lkorinth at openjdk.org  Wed Aug 13 13:09:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:09:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
Message-ID: <RA6T2Udma4QM1EdTUlZ9Y4l6Wo1783yEKYgOPy8UOZY=.7938ce78-45a5-4607-9298-72cf19436662@github.com>

On Wed, 13 Aug 2025 01:47:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Should we need to update the copyright year for the touched files

`After the review, I will update the copyrights.`

It is IMO easier to review big changes without the noise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273410872

From lkorinth at openjdk.org  Wed Aug 13 13:21:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:21:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
Message-ID: <4q0047gChugbkkv-W0lis2E8nXVWh8YGVJiBehoojLY=.0b9055a2-f038-4247-82a9-7c60ee9f6637@github.com>

On Tue, 12 Aug 2025 17:52:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > sun/tools/jhsdb/BasicLauncherTest.java
> > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 
> @lkorinth Can you send me a link to the failure?

I sent it to you on email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3183896453

From erikj at openjdk.org  Wed Aug 13 13:28:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 13 Aug 2025 13:28:18 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

make/RunTests.gmk line 939:

> 937: 
> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.

I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273468852

From lkorinth at openjdk.org  Wed Aug 13 13:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
Message-ID: <jX2ocV7Rf3mYq7TYfPkxKQfgucnVdhEDYMB91LwhTtI=.8810fb03-295c-4be5-9771-d7e031390002@github.com>

On Wed, 13 Aug 2025 01:51:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:
> 
>> 27:  * @requires vm.debug
>> 28:  * @summary Test running with StressRecompilation enabled.
>> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation
> 
> I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.
> 
> 
>> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
> 55:elapsed time (seconds): 0.581
> 66:elapsed time (seconds): 0.575
> 116:elapsed time (seconds): 3.088
> 162:elapsed time (seconds): 0.001
> 173:elapsed time (seconds): 11.546

I have only (to my knowledge) updated test cases that has timed out for me. We have some not very modern test machines that is slower. That in combination with a debug build, in combination with a timeout factor of 0.7 might have made the test time out. Unfortunately I no longer have the logs for this failure so I can not check if the machine was failing because it was low on memory etc. I still think it is reasonable to keep the old timeout of 480. I have no intuitive feeling for how expensive `-XX:+StressRecompilation` is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273488236

From lkorinth at openjdk.org  Wed Aug 13 13:53:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:53:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
Message-ID: <5nc1SBXnwAOJJvnrbMyPIsre61u--GxMHSffdDf8qUU=.77100025-4b9e-4e0a-b71d-df590df5f9ba@github.com>

On Wed, 13 Aug 2025 07:26:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the Serviceability related tweaks and I'm okay with them in general. But I'm curious if you do not see any timeouts with this anymore.

I only got the four timeouts described in the description, I got a few other failures as well that was not timeout related. I sent you a link to the test results in an email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3184026177

From lkorinth at openjdk.org  Wed Aug 13 14:22:08 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:08 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  After suggestions from Erik and Andrey

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/ac47dbdc..dbe42964

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

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

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

From lkorinth at openjdk.org  Wed Aug 13 14:22:10 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:10 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
Message-ID: <imd2i-VIlFCbEytLUZDyy_1SEU8ebK39Eif8JbdQsTU=.fefa1e8d-027b-445d-be69-07f6c6a475fd@github.com>

On Wed, 13 Aug 2025 13:25:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> make/RunTests.gmk line 939:
> 
>> 937: 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.
> 
> I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

I updated it to "Please reach consensus before changing this. It was not easy changing it to a `1`. " I also did not break the comment as it was shorter than line 933 above it. Is it acceptable now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273621868

From lkorinth at openjdk.org  Wed Aug 13 14:22:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
Message-ID: <KRJUnB026z2YmEljJJCHz5JEklLTO2LJfpMvwvt6-5k=.8388ace4-c445-4fdc-a71d-dff5a53cbeb6@github.com>

On Wed, 13 Aug 2025 09:44:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> test/langtools/tools/lib/toolbox/ToolBox.java line 480:
> 
>> 478: 
>> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
>> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;
> 
> Suggestion:
> 
>     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

Fixed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273614076