From iris at openjdk.org  Sat Apr  1 02:51:21 2023
From: iris at openjdk.org (Iris Clark)
Date: Sat, 1 Apr 2023 02:51:21 GMT
Subject: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v3]
In-Reply-To: <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>
Message-ID: <9xeOR9nFP1Pv9OxHLOkbzYTOjIkJxOZnB9M4zKAxJgU=.1d896a82-0139-434b-a6a3-ce4650914727@github.com>

On Fri, 31 Mar 2023 22:07:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert removing @see tags where the URL was not the same as the @spec URL

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367798667

From jpai at openjdk.org  Mon Apr  3 05:08:31 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Apr 2023 05:08:31 GMT
Subject: RFR: 8288109: HttpExchangeImpl.setAttribute does not allow null
 value after JDK-8266897 [v2]
In-Reply-To: <jv24c65k-Vt0ehDfwOgekMTkbioZ5RiDtviZyLBrN-E=.bca04cf2-61d5-45fd-a631-9c9009795e18@github.com>
References: <Sstd-3RHE0VdfFnmWoZZmKObHC09_guONQJxSOAOskM=.be5c154a-b416-4cd1-931e-0795585f475b@github.com>
 <jv24c65k-Vt0ehDfwOgekMTkbioZ5RiDtviZyLBrN-E=.bca04cf2-61d5-45fd-a631-9c9009795e18@github.com>
Message-ID: <9gRjU3n8ySk3gF3mej3l-0V92m_0TJjp4KuMWPv197s=.b1d492af-4a0e-4c87-87c2-86d061c08c26@github.com>

On Fri, 31 Mar 2023 14:47:08 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this fix for a regression in HttpExchange's setAttribute method.
>> 
>> The specification of setAttribute explicitly states that null values are allowed.
>> JDK-8266897 changed `attributes` to `ConcurrentHashMap`, which does not allow null values.
>> 
>> This patch modifies `setAttribute` to remove the attribute from the map when null value is requested.
>> 
>> A new test was added to verify that setting attributes works as expected both for null and non-null values.
>> 
>> Tier1-3 clean.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use URIBuilder

The changes look good to me. I have added a trivial comment about the test inline.

test/jdk/com/sun/net/httpserver/ExchangeAttributeTest.java line 29:

> 27:  * @summary Tests for HttpExchange set/getAttribute
> 28:  * @library /test/lib
> 29:  * @run junit/othervm ExchangeAttributeTest

Hello Daniel, I didn't see anything specific in the test which would need `othervm`. Is this intentional?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13264#pullrequestreview-1368292029
PR Review Comment: https://git.openjdk.org/jdk/pull/13264#discussion_r1155484397

From serb at openjdk.org  Mon Apr  3 11:12:01 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Apr 2023 11:12:01 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
Message-ID: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>

I would like to get preliminary feedback about the provided patch.

Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html

One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection.

At the moment this cache can be configured by the application using the following two properties:
   (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups
   (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups

The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server".

But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server.

Possible solutions:
  1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more.
  2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer.
  3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout.

The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync.

For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds.


RFC 8767 Serving Stale Data to Improve DNS Resiliency:
https://www.rfc-editor.org/rfc/rfc8767

Comments about current and other possible implementations:
 * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much.
 * The refresh timeout includes the time spent on the server lookup. So if we have to refresh every 2 seconds, but in lookup, we spend 3 seconds then we will request the server on each lookup. Another implementation may spend 3 seconds on lookup and then additional use the cached value for two seconds.
 * The extended timeout is a kind of "maximum stale timer" from the RFC above, but it starts counting not from the moment the record expired, but from the moment we added it to the cache. Another possible implementation may start counting from the moment the TTL expired, so the overall usage of the value will be sum ttl+extended.
 * The extended timeout has a hard deadline which is never changed during execution, for example, if it sets for 1 day, then at the end of the day we should make a successful lookup to recache the value otherwise we will start to use the "negative" cache. Other implementations may shift the expiration time on every successful sync.

Any thoughts about other possibilities?

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

Commit messages:
 -  the suggested cap is 7 days
 - simplify
 - comments
 - Merge remote-tracking branch 'upstream/master' into JDK-8304885
 - 8304885: Reuse stale data to improve DNS resolver resiliency

Changes: https://git.openjdk.org/jdk/pull/13285/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304885
  Stats: 380 lines in 14 files changed: 316 ins; 45 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

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

From michaelm at openjdk.org  Mon Apr  3 11:33:59 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 3 Apr 2023 11:33:59 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v4]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <eKbBwwC-h8pOilKo3MxbWuvgfGUuO7UtVrB74RziGM4=.8125ea3f-50a0-41b9-b20c-1a94d382d477@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  updated implementation and reimpl of AuthenticatoKeys

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/91a9e4c7..610ef0bf

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

  Stats: 324 lines in 15 files changed: 38 ins; 181 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/13159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13159/head:pull/13159

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

From michaelm at openjdk.org  Mon Apr  3 11:34:02 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 3 Apr 2023 11:34:02 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v3]
In-Reply-To: <m_zlxbnkAvSVcFTXaGk46eLPkcrhhlZkAGM4zsJujXo=.93398fda-2a54-4471-857d-9e8088f0b7d8@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <m_zlxbnkAvSVcFTXaGk46eLPkcrhhlZkAGM4zsJujXo=.93398fda-2a54-4471-857d-9e8088f0b7d8@github.com>
Message-ID: <EQ5UT1yhjQnWltbWP4vXlRFAvwrwL-EPih9ql1oJBRc=.cd445e6d-38b1-4099-b852-ff271c970e78@github.com>

On Mon, 27 Mar 2023 09:05:17 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review updates

I've just pushed a re-implementation of the underlying authenticator keys mechanism together with this fix. There are still a few loose ends:
- behavior when the default Authenticator is changed (may need to be specified)
- serialization of AuthCacheImpl (doesn't seem to be possible for user code to do this. So, maybe consider removing)
- initialization of shared secrets usage (currently by instantiating a dummy Authenticator)

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

PR Comment: https://git.openjdk.org/jdk/pull/13159#issuecomment-1494152118

From djelinski at openjdk.org  Mon Apr  3 14:32:01 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 3 Apr 2023 14:32:01 GMT
Subject: RFR: 8288109: HttpExchangeImpl.setAttribute does not allow null
 value after JDK-8266897 [v2]
In-Reply-To: <9gRjU3n8ySk3gF3mej3l-0V92m_0TJjp4KuMWPv197s=.b1d492af-4a0e-4c87-87c2-86d061c08c26@github.com>
References: <Sstd-3RHE0VdfFnmWoZZmKObHC09_guONQJxSOAOskM=.be5c154a-b416-4cd1-931e-0795585f475b@github.com>
 <jv24c65k-Vt0ehDfwOgekMTkbioZ5RiDtviZyLBrN-E=.bca04cf2-61d5-45fd-a631-9c9009795e18@github.com>
 <9gRjU3n8ySk3gF3mej3l-0V92m_0TJjp4KuMWPv197s=.b1d492af-4a0e-4c87-87c2-86d061c08c26@github.com>
Message-ID: <Pb-twYUXh2Nj6hf8VlWoKo7SJ0Cb5u1BVccE5R4VW0k=.3811bb0c-62a3-4117-b99f-a35da639c1a6@github.com>

On Mon, 3 Apr 2023 05:05:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use URIBuilder
>
> test/jdk/com/sun/net/httpserver/ExchangeAttributeTest.java line 29:
> 
>> 27:  * @summary Tests for HttpExchange set/getAttribute
>> 28:  * @library /test/lib
>> 29:  * @run junit/othervm ExchangeAttributeTest
> 
> Hello Daniel, I didn't see anything specific in the test which would need `othervm`. Is it the use of `ConsoleHandler` against the `com.sun.net.httpserver` logger which prompted the use of `othervm`?

Actually, I wanted to make sure the HttpClient will be closed as soon as possible. And yes, the logger would also leak to other tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13264#discussion_r1156046156

From jpai at openjdk.org  Mon Apr  3 14:41:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Apr 2023 14:41:59 GMT
Subject: RFR: 8288109: HttpExchangeImpl.setAttribute does not allow null
 value after JDK-8266897 [v2]
In-Reply-To: <Pb-twYUXh2Nj6hf8VlWoKo7SJ0Cb5u1BVccE5R4VW0k=.3811bb0c-62a3-4117-b99f-a35da639c1a6@github.com>
References: <Sstd-3RHE0VdfFnmWoZZmKObHC09_guONQJxSOAOskM=.be5c154a-b416-4cd1-931e-0795585f475b@github.com>
 <jv24c65k-Vt0ehDfwOgekMTkbioZ5RiDtviZyLBrN-E=.bca04cf2-61d5-45fd-a631-9c9009795e18@github.com>
 <9gRjU3n8ySk3gF3mej3l-0V92m_0TJjp4KuMWPv197s=.b1d492af-4a0e-4c87-87c2-86d061c08c26@github.com>
 <Pb-twYUXh2Nj6hf8VlWoKo7SJ0Cb5u1BVccE5R4VW0k=.3811bb0c-62a3-4117-b99f-a35da639c1a6@github.com>
Message-ID: <AuESp_RN9iBz642fuiz-HWP3XR4YANqw07LipOGvZf4=.b742b302-3f4c-4edd-9f37-551a9d2bb5c3@github.com>

On Mon, 3 Apr 2023 14:29:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/ExchangeAttributeTest.java line 29:
>> 
>>> 27:  * @summary Tests for HttpExchange set/getAttribute
>>> 28:  * @library /test/lib
>>> 29:  * @run junit/othervm ExchangeAttributeTest
>> 
>> Hello Daniel, I didn't see anything specific in the test which would need `othervm`. Is it the use of `ConsoleHandler` against the `com.sun.net.httpserver` logger which prompted the use of `othervm`?
>
> Actually, I wanted to make sure the HttpClient will be closed as soon as possible. And yes, the logger would also leak to other tests.

Sounds fine to me then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13264#discussion_r1156058981

From djelinski at openjdk.org  Mon Apr  3 15:00:15 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 3 Apr 2023 15:00:15 GMT
Subject: Integrated: 8288109: HttpExchangeImpl.setAttribute does not allow null
 value after JDK-8266897
In-Reply-To: <Sstd-3RHE0VdfFnmWoZZmKObHC09_guONQJxSOAOskM=.be5c154a-b416-4cd1-931e-0795585f475b@github.com>
References: <Sstd-3RHE0VdfFnmWoZZmKObHC09_guONQJxSOAOskM=.be5c154a-b416-4cd1-931e-0795585f475b@github.com>
Message-ID: <CFpdjQgEbWg20oCo60ebPL8GfKq4QrWytn7AnF5khQ0=.e2d199a1-3125-49e3-9b07-ca0271342865@github.com>

On Fri, 31 Mar 2023 10:35:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this fix for a regression in HttpExchange's setAttribute method.
> 
> The specification of setAttribute explicitly states that null values are allowed.
> JDK-8266897 changed `attributes` to `ConcurrentHashMap`, which does not allow null values.
> 
> This patch modifies `setAttribute` to remove the attribute from the map when null value is requested.
> 
> A new test was added to verify that setting attributes works as expected both for null and non-null values.
> 
> Tier1-3 clean.

This pull request has now been integrated.

Changeset: f9827ad1
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9827ad17205ad1cec21bf76f8553f415439b38b
Stats:     120 lines in 2 files changed: 119 ins; 0 del; 1 mod

8288109: HttpExchangeImpl.setAttribute does not allow null value after JDK-8266897

Reviewed-by: dfuchs, jpai

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

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

From michaelm at openjdk.org  Mon Apr  3 15:52:01 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 3 Apr 2023 15:52:01 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v5]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <gXqvIhcrQyqlrBDbLjmitXkFf8S69I5J145FByLNyjM=.f7660456-9651-4caf-ab58-9ac6eaa6d485@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

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

 - update
 - Merge branch 'master' into auth
 - updated implementation and reimpl of AuthenticatoKeys
 - review updates
 - test update
 - revert removed methods (used in tests)
 - initial impl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/610ef0bf..db24a545

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

  Stats: 24931 lines in 678 files changed: 11918 ins; 8816 del; 4197 mod
  Patch: https://git.openjdk.org/jdk/pull/13159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13159/head:pull/13159

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

From serb at openjdk.org  Mon Apr  3 22:57:36 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Apr 2023 22:57:36 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v2]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <odnIU2CVVA3icR0FUru394X-P7SpQ5VRpx4hP6fbN-M=.bbea50dd-2a64-4c54-9023-d02a58e09791@github.com>

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

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

  Use "maximum stale timer" instead of the extended timeout, and bump it on each successful lookup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13285/files
  - new: https://git.openjdk.org/jdk/pull/13285/files/1b29c06f..c9b0d79b

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

  Stats: 428 lines in 19 files changed: 226 ins; 175 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

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

From serb at openjdk.org  Mon Apr  3 23:00:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 3 Apr 2023 23:00:49 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v2]
In-Reply-To: <odnIU2CVVA3icR0FUru394X-P7SpQ5VRpx4hP6fbN-M=.bbea50dd-2a64-4c54-9023-d02a58e09791@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <odnIU2CVVA3icR0FUru394X-P7SpQ5VRpx4hP6fbN-M=.bbea50dd-2a64-4c54-9023-d02a58e09791@github.com>
Message-ID: <LEymrT_hqI2JtkvRli63dwieULX1yX6mtLx3CpSG5Sc=.2558a074-1b9a-426e-961d-83e6d8137e81@github.com>

On Mon, 3 Apr 2023 22:57:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

After thinking about the initial proposal and description of how it should work according to RFC 8767, I decided to change the meaning of the new property. Instead of setting the overall cache timeout via extended property, the code now uses the  "maximum stale timer" -  It defines the length of time after a record expires that it should be retained in the cache. It means that the overall timeout now is s sum of ttl+stale.

Note that now the "stale timeout" is updated after each successful lookup.

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

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

From jjg at openjdk.org  Tue Apr  4 00:13:20 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 4 Apr 2023 00:13:20 GMT
Subject: Integrated: JDK-8305206: Add @spec tags in java.base/java.* (part 1)
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <cU6-hY-ZFAn7XQ83SgGaTT-BsgqIhTus_Sj-XdFSzPE=.21e82408-ae57-4f06-9e51-cebd10d1efa5@github.com>

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

This pull request has now been integrated.

Changeset: c6bd489c
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6bd489cc8d30fb6eec865b3dab1cf861e25c8d7
Stats:     270 lines in 60 files changed: 268 ins; 2 del; 0 mod

8305206: Add @spec tags in java.base/java.* (part 1)

Reviewed-by: alanb, naoto, darcy, lancea, dfuchs, iris, mchung

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

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

From jpai at openjdk.org  Tue Apr  4 05:53:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Apr 2023 05:53:08 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v2]
In-Reply-To: <LCUfUTqIySSPKdBzN035NvsQgzmDYVvj-fFxqyYQXN4=.483e5e1a-a710-4891-a5bc-e8c743b8753b@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <LCUfUTqIySSPKdBzN035NvsQgzmDYVvj-fFxqyYQXN4=.483e5e1a-a710-4891-a5bc-e8c743b8753b@github.com>
Message-ID: <n-gUsNZmd8AVLBDWt9sXXkZ2achp2tl8jA2UsAzS1R0=.e868e232-7909-458d-b3d5-d7ca4e511f28@github.com>

On Thu, 30 Mar 2023 16:05:08 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to copyright year

Hello Varada, overall the changes look OK to me. I missed it previously, but the `jdk/net/ExtendedSocketOptions.java` file will need an update to the copyright year.

Before integrating, please wait for another review from someone more experienced in this area. I lack experience in the native/C area, so I would like another Reviewer to take a look at this.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13240#pullrequestreview-1370236461

From dfuchs at openjdk.org  Tue Apr  4 13:22:24 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Apr 2023 13:22:24 GMT
Subject: RFR: 8267140: Support closing the HttpClient by making it
 auto-closable [v15]
In-Reply-To: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
References: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
Message-ID: <bMiVc7kI4Q47FQnNxrkOV8LwPf7789FVAx-hW2kVr34=.5554ee7e-f3f6-4808-b25a-44d68bb06f78@github.com>

> Please find here an RFE that makes the `java.net.HttpClient` auto-closeable.
> 
> The API has been modeled on `ExecutorService`.
> 
> HttpClient::close() is a graceful shutdown and will wait until all operations are terminated before returning.
> If a request is in progress, and the caller doesn't pull the corresponding data (for instance, the request was sent with a BodyHandler.ofInputStream(), but the caller stopped reading the input stream) then close() may never return.
> 
> Therefore, additional methods similar to those present in `ExecutorService` are also proposed. In summary:
> 
> - `shutdown()`: initiate a graceful shutdown, but doesn't wait for termination. 
> - `shutdownNow()`:  initiate an immediate shutdown, attempting to cancel all operations in progress. Doesn't wait for termination.
> - `awaitTermination(Duration)`: await for termination within the given delay
> - `isTerminated()` tells whether the client is terminated
> 
> New tests have been added to test the proposed behaviors.
> 
> HttpClient tests (new and old) are still stable.

Daniel Fuchs 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 23 additional commits since the last revision:

 - Merge branch 'master' into HttpClient-close-8267140
 - Included CSR review feedback
 - Merge branch 'master' into HttpClient-close-8267140
 - Fixed minor typos in test comments
 - Integrated feedback on tests
 - Minor updates. Added some links
 - Define operations. Clarify some of the things that may stall an orderly shutdown
 - Update src/java.net.http/share/classes/java/net/http/HttpClient.java
   
   Fixed typo
 - Add tests for default method implementations; Refactor HttpClientBuilderTest to close the clients it creates
 - Rephrase IOException in send/sendAsync
 - ... and 13 more: https://git.openjdk.org/jdk/compare/17ecac18...35c09a02

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13019/files
  - new: https://git.openjdk.org/jdk/pull/13019/files/e6abd08b..35c09a02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13019&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13019&range=13-14

  Stats: 19608 lines in 486 files changed: 8592 ins; 9163 del; 1853 mod
  Patch: https://git.openjdk.org/jdk/pull/13019.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13019/head:pull/13019

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

From jpai at openjdk.org  Tue Apr  4 13:23:29 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Apr 2023 13:23:29 GMT
Subject: RFR: 8267140: Support closing the HttpClient by making it
 auto-closable [v15]
In-Reply-To: <bMiVc7kI4Q47FQnNxrkOV8LwPf7789FVAx-hW2kVr34=.5554ee7e-f3f6-4808-b25a-44d68bb06f78@github.com>
References: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
 <bMiVc7kI4Q47FQnNxrkOV8LwPf7789FVAx-hW2kVr34=.5554ee7e-f3f6-4808-b25a-44d68bb06f78@github.com>
Message-ID: <3KaTep24hzSX9KjZ17kj-ptOUYjbgF4LF7Q_bHyxPZE=.5be6197f-5db3-487b-9750-126ed5df05d8@github.com>

On Tue, 4 Apr 2023 13:22:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here an RFE that makes the `java.net.HttpClient` auto-closeable.
>> 
>> The API has been modeled on `ExecutorService`.
>> 
>> HttpClient::close() is a graceful shutdown and will wait until all operations are terminated before returning.
>> If a request is in progress, and the caller doesn't pull the corresponding data (for instance, the request was sent with a BodyHandler.ofInputStream(), but the caller stopped reading the input stream) then close() may never return.
>> 
>> Therefore, additional methods similar to those present in `ExecutorService` are also proposed. In summary:
>> 
>> - `shutdown()`: initiate a graceful shutdown, but doesn't wait for termination. 
>> - `shutdownNow()`:  initiate an immediate shutdown, attempting to cancel all operations in progress. Doesn't wait for termination.
>> - `awaitTermination(Duration)`: await for termination within the given delay
>> - `isTerminated()` tells whether the client is terminated
>> 
>> New tests have been added to test the proposed behaviors.
>> 
>> HttpClient tests (new and old) are still stable.
>
> Daniel Fuchs 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 23 additional commits since the last revision:
> 
>  - Merge branch 'master' into HttpClient-close-8267140
>  - Included CSR review feedback
>  - Merge branch 'master' into HttpClient-close-8267140
>  - Fixed minor typos in test comments
>  - Integrated feedback on tests
>  - Minor updates. Added some links
>  - Define operations. Clarify some of the things that may stall an orderly shutdown
>  - Update src/java.net.http/share/classes/java/net/http/HttpClient.java
>    
>    Fixed typo
>  - Add tests for default method implementations; Refactor HttpClientBuilderTest to close the clients it creates
>  - Rephrase IOException in send/sendAsync
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/894567fc...35c09a02

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13019#pullrequestreview-1370967134

From duke at openjdk.org  Tue Apr  4 17:13:24 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 4 Apr 2023 17:13:24 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue and
 no chunking
Message-ID: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>

Currently it is possible for `HttpURLConnection` with the `Expect: 100-Continue` header to timeout awaiting for a server response. According to [RFC-7231](https://www.rfc-editor.org/rfc/rfc7231#section-5.1.1) a client `SHOULD NOT wait for an indefinite period before sending the message body`.

This PR changes the existing `expect100Continue` method to wait for a maximum of 5 seconds for a server response, this will be shorter if a timeout is set. If no response is received, the message is sent regardless.

Tests have been added to account for different scenarios that currently timeout, and the changes have been tested against tiers 1,2 and 3.

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

Commit messages:
 - further cleanup
 - cleanup and formatting
 - Fix for 100-continue hanging

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

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

From vtewari at openjdk.org  Tue Apr  4 17:51:14 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Tue, 4 Apr 2023 17:51:14 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v2]
In-Reply-To: <LCUfUTqIySSPKdBzN035NvsQgzmDYVvj-fFxqyYQXN4=.483e5e1a-a710-4891-a5bc-e8c743b8753b@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <LCUfUTqIySSPKdBzN035NvsQgzmDYVvj-fFxqyYQXN4=.483e5e1a-a710-4891-a5bc-e8c743b8753b@github.com>
Message-ID: <9mVvvz5dt3lPrjbrmUdxYYC-JkLUApxAJOZUBQLJbOw=.3b0ca641-9a71-46e7-a3df-108118d4636e@github.com>

On Thu, 30 Mar 2023 16:05:08 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to copyright year

Looks OK to me, the native code is same as Linux code with only difference is the socket options constants. Please update the copyright year as suggested.

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

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13240#pullrequestreview-1371490461

From rriggs at openjdk.org  Tue Apr  4 19:31:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 19:31:02 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
Message-ID: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>

With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
This PR exports jdk.internal.util to:
 - java.prefs,
 - java.security.jgss,
 - java.smartcardio,
 - jdk.charsets,
 - jdk.net,
 - jdk.zipfs

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

Commit messages:
 - In jdk.prefs module, Replace os.name with OperatingSystem enum
 - Use OperatingSystem methods instead of system property os.name

Changes: https://git.openjdk.org/jdk/pull/13335/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13335&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304911
  Stats: 131 lines in 13 files changed: 24 ins; 54 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/13335.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13335/head:pull/13335

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

From jjg at openjdk.org  Tue Apr  4 19:55:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 4 Apr 2023 19:55:14 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2)
Message-ID: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>

Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248)

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

Commit messages:
 - JDK-8305406: Add @spec tags in java.base/java.* (part 2)

Changes: https://git.openjdk.org/jdk/pull/13336/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13336&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305406
  Stats: 245 lines in 53 files changed: 238 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13336.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13336/head:pull/13336

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

From naoto at openjdk.org  Tue Apr  4 20:46:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 20:46:08 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <PLVQO12D6OpNUM1D631lpeCa-XG2ppj8-yFutinjzo4=.8419be80-c474-4f80-b348-9248b49f12fc@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371756979

From lancea at openjdk.org  Tue Apr  4 20:54:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 4 Apr 2023 20:54:09 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <jmYozHgCwkNFcK_M5EWxKGZ9iHABZ-RdMAOeDjBGNGk=.348c92c5-fb19-410f-9991-d7ab772ac914@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

The changes look good

Please add a Noreg-XXX label to the bug

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371768336

From iris at openjdk.org  Tue Apr  4 21:00:10 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 4 Apr 2023 21:00:10 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <w--1bkwl6V1e7G7aGwcv4NlboudQn_noNPCyD03SAYM=.0c98f3d4-d4a1-43ca-b239-20d6658172a5@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371776265

From jlu at openjdk.org  Wed Apr  5 05:08:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Apr 2023 05:08:10 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking
In-Reply-To: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
Message-ID: <8jy77WVmWS25nGyk2FqeWkF9Zz43J9G3HrETPWBCfhg=.c3385892-92a8-49e7-b8bf-87f02f460192@github.com>

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

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

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

> 191:         control.write100ContinueTwice = false;
> 192: 
> 193:         HttpURLConnection connection = (HttpURLConnection) url.openConnection();

Hi Darragh,

It looks like the tests share a lot of similar code, unless there is a reason not to, could they not share a similar function to reduce code duplication?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1158026653

From duke at openjdk.org  Wed Apr  5 05:11:08 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 05:11:08 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <aQYAwMrrJcqk4ATxMUuvnQswH8AxHgye4L34iE3UTG4=.5c1f5324-846f-4833-8828-16b3c6067a46@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 105:

> 103:                                 case WINDOWS -> // Full path needed, DLL is in jre/bin
> 104:                                         new String[]{StaticProperty.javaHome()
> 105:                                                 + "\\bin\\sspi_bridge.dll"};

Suggestion:

                                        new String[]{ StaticProperty.javaHome()
                                                + "\\bin\\sspi_bridge.dll" };

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158027900

From alanb at openjdk.org  Wed Apr  5 08:42:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 08:42:16 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java line 406:

> 404:                 case MACOS -> newInstance("jdk.net.MacOSXSocketOptions");
> 405:                 case WINDOWS -> newInstance("jdk.net.WindowsSocketOptions");
> 406:                 default -> new PlatformSocketOptions();

For another issue, but I assume this could be refactored to not need PlatformSocketOptions, in which case the mapping of OS name to implementation class would go away.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2882:

> 2880:                     elenNTFS = 36;           // total 36 bytes
> 2881:                 } else {                     // Extended Timestamp otherwise
> 2882:                     elenEXTT = 9;            // only mtime in cen

It might be better to drop ZipFileSystem from this patch and instead create a bug to re-examine this code. I would have expected it use NFTS when the timestamp is beyond the range of an extended timestamp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158209156
PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158206710

From djelinski at openjdk.org  Wed Apr  5 09:34:19 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Apr 2023 09:34:19 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking
In-Reply-To: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
Message-ID: <o-79ZzFBmMESYM6n_mZ2MF5op3pvuKtf_f6JJJoRJr0=.1c281a5f-d5dc-4c2c-9fd2-1fa326a1af72@github.com>

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

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

Changes requested by djelinski (Reviewer).

src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java line 1370:

> 1368:             }
> 1369: 
> 1370:             http.setIgnoreContinue(true);

Do you still need the `setIgnoreContinue(true)` in line 1339?

src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java line 1453:

> 1451: 
> 1452:             if (expectContinue) {
> 1453:                 http.setIgnoreContinue(false);

Do you still need the `setIgnoreContinue(false)` a few lines above?

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

> 1: /*

I noticed that you have tests for chunked streaming mode and for buffered mode; can you add tests for fixed length streaming mode as well? I.e. use `setFixedLengthStreamingMode`.

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

> 112:                         int contentLength = Integer.parseInt(substr.trim());
> 113: 
> 114:                         if (control.respondWith100Continue) {

this code is duplicated in the `if` and `else` branches; move it outside.

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

PR Review: https://git.openjdk.org/jdk/pull/13330#pullrequestreview-1372246778
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1158113297
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1158084804
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1158245845
PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1158237770

From duke at openjdk.org  Wed Apr  5 10:14:16 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 5 Apr 2023 10:14:16 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking
In-Reply-To: <o-79ZzFBmMESYM6n_mZ2MF5op3pvuKtf_f6JJJoRJr0=.1c281a5f-d5dc-4c2c-9fd2-1fa326a1af72@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
 <o-79ZzFBmMESYM6n_mZ2MF5op3pvuKtf_f6JJJoRJr0=.1c281a5f-d5dc-4c2c-9fd2-1fa326a1af72@github.com>
Message-ID: <SVajpjlJDRltjtkP4FvlvNEnE__rNAWl6Q68a-394lw=.3f9b355f-b235-439b-968e-fa44c23fa6fa@github.com>

On Wed, 5 Apr 2023 07:15:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Currently it is possible for `HttpURLConnection` with the `Expect: 100-Continue` header to timeout awaiting for a server response. According to [RFC-7231](https://www.rfc-editor.org/rfc/rfc7231#section-5.1.1) a client `SHOULD NOT wait for an indefinite period before sending the message body`.
>> 
>> This PR changes the existing `expect100Continue` method to wait for a maximum of 5 seconds for a server response, this will be shorter if a timeout is set. If no response is received, the message is sent regardless.
>> 
>> Tests have been added to account for different scenarios that currently timeout, and the changes have been tested against tiers 1,2 and 3.
>
> src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java line 1370:
> 
>> 1368:             }
>> 1369: 
>> 1370:             http.setIgnoreContinue(true);
> 
> Do you still need the `setIgnoreContinue(true)` in line 1339?

Thanks for pointing those out, I accidentally doubled up on `setIgnoreContinue` calls

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1158311150

From duke at openjdk.org  Wed Apr  5 10:14:21 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 5 Apr 2023 10:14:21 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking
In-Reply-To: <8jy77WVmWS25nGyk2FqeWkF9Zz43J9G3HrETPWBCfhg=.c3385892-92a8-49e7-b8bf-87f02f460192@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
 <8jy77WVmWS25nGyk2FqeWkF9Zz43J9G3HrETPWBCfhg=.c3385892-92a8-49e7-b8bf-87f02f460192@github.com>
Message-ID: <7yW7CrYI3SYNq9ciSsoFY2cVzuiFp082ZAV-NgU6Lhk=.916d26ba-c622-4c32-a659-b8eccb9c975a@github.com>

On Wed, 5 Apr 2023 05:05:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Currently it is possible for `HttpURLConnection` with the `Expect: 100-Continue` header to timeout awaiting for a server response. According to [RFC-7231](https://www.rfc-editor.org/rfc/rfc7231#section-5.1.1) a client `SHOULD NOT wait for an indefinite period before sending the message body`.
>> 
>> This PR changes the existing `expect100Continue` method to wait for a maximum of 5 seconds for a server response, this will be shorter if a timeout is set. If no response is received, the message is sent regardless.
>> 
>> Tests have been added to account for different scenarios that currently timeout, and the changes have been tested against tiers 1,2 and 3.
>
> test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 193:
> 
>> 191:         control.write100ContinueTwice = false;
>> 192: 
>> 193:         HttpURLConnection connection = (HttpURLConnection) url.openConnection();
> 
> Hi Darragh,
> 
> It looks like the tests share a lot of similar code, unless there is a reason not to, could they not share a similar function to reduce code duplication?

Hey, thanks for pointing that out, I'll try and reduce some of the duplication

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1158312342

From duke at openjdk.org  Wed Apr  5 12:23:10 2023
From: duke at openjdk.org (Varada M)
Date: Wed, 5 Apr 2023 12:23:10 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v3]
In-Reply-To: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
Message-ID: <QE6ST3-qCKq_WarGq2vLZtoqYUyGPDztqBuiZuleCZU=.ab42e5b5-1f85-4025-9d82-7deca21f6a87@github.com>

> Breaking this into two parts : 
> 
> 1. Implementing socket options for AIX 
> 2. DontFragmentTest failure 
> 
> - Implementing socket options for AIX :
> 
> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
> 
> - DontFragment test failure :
> 
> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
> 
> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13240/files
  - new: https://git.openjdk.org/jdk/pull/13240/files/154687d1..21a86820

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

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

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

From duke at openjdk.org  Wed Apr  5 12:23:11 2023
From: duke at openjdk.org (Varada M)
Date: Wed, 5 Apr 2023 12:23:11 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v2]
In-Reply-To: <9mVvvz5dt3lPrjbrmUdxYYC-JkLUApxAJOZUBQLJbOw=.3b0ca641-9a71-46e7-a3df-108118d4636e@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <LCUfUTqIySSPKdBzN035NvsQgzmDYVvj-fFxqyYQXN4=.483e5e1a-a710-4891-a5bc-e8c743b8753b@github.com>
 <9mVvvz5dt3lPrjbrmUdxYYC-JkLUApxAJOZUBQLJbOw=.3b0ca641-9a71-46e7-a3df-108118d4636e@github.com>
Message-ID: <SksDZlbsTwwfE-uFiVRQnDtnm5RVNwZy9S1iZDTdYPY=.cf0effd1-53d7-43e2-a320-1e63406910a0@github.com>

On Tue, 4 Apr 2023 17:48:18 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update to copyright year
>
> Looks OK to me, the native code is same as Linux code with only difference is the socket options constants. Please update the copyright year as suggested.

@vyommani @jaikiran Thanks for the review. I have updated the copyright year.

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

PR Comment: https://git.openjdk.org/jdk/pull/13240#issuecomment-1497394234

From djelinski at openjdk.org  Wed Apr  5 12:36:13 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Apr 2023 12:36:13 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v3]
In-Reply-To: <QE6ST3-qCKq_WarGq2vLZtoqYUyGPDztqBuiZuleCZU=.ab42e5b5-1f85-4025-9d82-7deca21f6a87@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <QE6ST3-qCKq_WarGq2vLZtoqYUyGPDztqBuiZuleCZU=.ab42e5b5-1f85-4025-9d82-7deca21f6a87@github.com>
Message-ID: <XXQIuVXd_bONLX1ETDmpwYg0NdHZdTFAVrVbIppipMI=.62fb6078-f552-419c-8f4a-075fff796674@github.com>

On Wed, 5 Apr 2023 12:23:10 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year

Hi, could you check if the value returned by [Java_sun_nio_ch_Net_shouldSetBothIPv4AndIPv6Options0](https://github.com/openjdk/jdk/blob/0deb648985b018653ccdaf193dc13b3cf21c088a/src/java.base/unix/native/libnio/ch/Net.c#L159-L167) is correct on AIX?

More specifically, this piece of code should throw an exception mentioning that the message is too big for the underlying transport:

DatagramChannel channel = DatagramChannel.open(StandardProtocolFamily.INET6);
channel.setOption(ExtendedSocketOptions.IP_DONTFRAGMENT, true);
channel.send(ByteBuffer.allocate(64000),
                    new InetSocketAddress("bugs.openjdk.org", 1234));

on Windows and Linux it works (i.e. throws) because `shouldSetBothIPv4AndIPv6Options0` returns `true`; on MacOSX it doesn't work even if `shouldSetBothIPv4AndIPv6Options0` returns `true`, so we return `false`; it would be interesting how AIX behaves here.

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

PR Comment: https://git.openjdk.org/jdk/pull/13240#issuecomment-1497413476

From rriggs at openjdk.org  Wed Apr  5 14:11:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:11:18 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
Message-ID: <F8Jr6kezM5OXPwzssO4GuD_FFHdkruuTw955hwPJ9Kc=.fb2ede42-7b0d-4221-9c87-bfa0df005123@github.com>

On Wed, 5 Apr 2023 08:39:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java line 406:
> 
>> 404:                 case MACOS -> newInstance("jdk.net.MacOSXSocketOptions");
>> 405:                 case WINDOWS -> newInstance("jdk.net.WindowsSocketOptions");
>> 406:                 default -> new PlatformSocketOptions();
> 
> For another issue, but I assume this could be refactored to not need PlatformSocketOptions, in which case the mapping of OS name to implementation class would go away.

Created an issue to track the possible refactoring, will keep this change until then.
https://bugs.openjdk.org/browse/JDK-8305661

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158574021

From rriggs at openjdk.org  Wed Apr  5 14:22:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:22:29 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
Message-ID: <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>

On Wed, 5 Apr 2023 08:37:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2882:
> 
>> 2880:                     elenNTFS = 36;           // total 36 bytes
>> 2881:                 } else {                     // Extended Timestamp otherwise
>> 2882:                     elenEXTT = 9;            // only mtime in cen
> 
> It might be better to drop ZipFileSystem from this patch and instead create a bug to re-examine this code. I would have expected it use NFTS when the timestamp is beyond the range of an extended timestamp. It shouldn't be looking at the current OS name.

Created [JDK-8305662](https://bugs.openjdk.org/browse/JDK-8305662) to track refactoring.
Will revert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158587949

From rriggs at openjdk.org  Wed Apr  5 14:32:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:32:03 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v2]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Revert chanes to ZipFileSystem to defer refactoring.
  Reformatted expression to match switch expression formatting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/72cff1ed..aadf5bbd

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

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

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

From alanb at openjdk.org  Wed Apr  5 14:36:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 14:36:16 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v2]
In-Reply-To: <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
 <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>
Message-ID: <hoTsG4Le90HdJbdN-yAOFAYCjwwLn4avbyJBS6VViR8=.7e769d74-a829-4621-8229-8722dc7c50df@github.com>

On Wed, 5 Apr 2023 14:18:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Created [JDK-8305662](https://bugs.openjdk.org/browse/JDK-8305662) to track refactoring.
> Will revert.

Thanks, you can revert the qualified export in module-info and the additional grant in default.policy too.

The interesting thing about this PR is that each change begs the question on whether the code should be refactored, that would take time of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158609098

From duke at openjdk.org  Wed Apr  5 14:45:15 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 14:45:15 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v2]
In-Reply-To: <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>
Message-ID: <Osp9DN7X8Ep5PtaZ0V8E7kf3vDZRpxHnrsKmj4NAjPg=.e2fadf20-cd2e-4596-a78d-73e75af04eab@github.com>

On Wed, 5 Apr 2023 14:32:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert chanes to ZipFileSystem to defer refactoring.
>   Reformatted expression to match switch expression formatting.

src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 103:

> 101:                                         "/usr/lib/sasl2/libgssapiv2.2.so",
> 102:                                 };
> 103:                                 case WINDOWS -> new String[]{ // Full path needed, DLL is in jre/bin

Suggestion:

                                case WINDOWS -> new String[]{
                                        // Full path needed, DLL is in jre/bin

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158620967

From dfuchs at openjdk.org  Wed Apr  5 14:57:24 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Apr 2023 14:57:24 GMT
Subject: RFR: 8267140: Support closing the HttpClient by making it
 auto-closable [v16]
In-Reply-To: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
References: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
Message-ID: <lwWFsqOeAAO7UUGZPVJLszvooxAKx100JCyuU2tegKE=.f2e5b33f-3671-488b-8bf9-39a26e18ec2a@github.com>

> Please find here an RFE that makes the `java.net.HttpClient` auto-closeable.
> 
> The API has been modeled on `ExecutorService`.
> 
> HttpClient::close() is a graceful shutdown and will wait until all operations are terminated before returning.
> If a request is in progress, and the caller doesn't pull the corresponding data (for instance, the request was sent with a BodyHandler.ofInputStream(), but the caller stopped reading the input stream) then close() may never return.
> 
> Therefore, additional methods similar to those present in `ExecutorService` are also proposed. In summary:
> 
> - `shutdown()`: initiate a graceful shutdown, but doesn't wait for termination. 
> - `shutdownNow()`:  initiate an immediate shutdown, attempting to cancel all operations in progress. Doesn't wait for termination.
> - `awaitTermination(Duration)`: await for termination within the given delay
> - `isTerminated()` tells whether the client is terminated
> 
> New tests have been added to test the proposed behaviors.
> 
> HttpClient tests (new and old) are still stable.

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

  Further CSR review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13019/files
  - new: https://git.openjdk.org/jdk/pull/13019/files/35c09a02..6a9523a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13019&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13019&range=14-15

  Stats: 42 lines in 1 file changed: 23 ins; 13 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13019.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13019/head:pull/13019

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

From dfuchs at openjdk.org  Wed Apr  5 15:04:23 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Apr 2023 15:04:23 GMT
Subject: RFR: 8267140: Support closing the HttpClient by making it
 auto-closable [v16]
In-Reply-To: <lwWFsqOeAAO7UUGZPVJLszvooxAKx100JCyuU2tegKE=.f2e5b33f-3671-488b-8bf9-39a26e18ec2a@github.com>
References: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
 <lwWFsqOeAAO7UUGZPVJLszvooxAKx100JCyuU2tegKE=.f2e5b33f-3671-488b-8bf9-39a26e18ec2a@github.com>
Message-ID: <_i349qmsWFAO78AnNWhzYxZKRfQHX5gY5MxyzYsqb4g=.e0edad25-5772-494f-817d-06907cf96c88@github.com>

On Wed, 5 Apr 2023 14:57:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here an RFE that makes the `java.net.HttpClient` auto-closeable.
>> 
>> The API has been modeled on `ExecutorService`.
>> 
>> HttpClient::close() is a graceful shutdown and will wait until all operations are terminated before returning.
>> If a request is in progress, and the caller doesn't pull the corresponding data (for instance, the request was sent with a BodyHandler.ofInputStream(), but the caller stopped reading the input stream) then close() may never return.
>> 
>> Therefore, additional methods similar to those present in `ExecutorService` are also proposed. In summary:
>> 
>> - `shutdown()`: initiate a graceful shutdown, but doesn't wait for termination. 
>> - `shutdownNow()`:  initiate an immediate shutdown, attempting to cancel all operations in progress. Doesn't wait for termination.
>> - `awaitTermination(Duration)`: await for termination within the given delay
>> - `isTerminated()` tells whether the client is terminated
>> 
>> New tests have been added to test the proposed behaviors.
>> 
>> HttpClient tests (new and old) are still stable.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further CSR review feedback

@AlanBateman suggested the following changes, with which I have updated the CSR and this PR:

In the class level documentation:

1. Only the first sentence of the previously added `@apiNote` remains in the `@apiNote`
2. The bulk of the `@apiNote` text that was added previously is now moved to the `@implNote` paragraph
3. The modified `@apiNote` is moved above the `@implNote` that was previously there
4. The `##closing` anchor now links to the `@implNote`

In each of the new methods:

1. The link to the `##closing` paragraph (non-normative) is removed from the `@implSpec` (normative).
2. An `@see ##closing Implementation Note on closing the HttpClient` is added instead, at the end of the method API documentation.

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

PR Comment: https://git.openjdk.org/jdk/pull/13019#issuecomment-1497640779

From djelinski at openjdk.org  Wed Apr  5 15:31:08 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Apr 2023 15:31:08 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2)
In-Reply-To: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
Message-ID: <5LdxHbFCjmNDv-s9An5F63Cx8uux01flNCe8a2pb1Iw=.03f0fae6-e8d0-40af-aea1-2698c543fde2@github.com>

On Tue, 4 Apr 2023 19:46:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248)

Marked as reviewed by djelinski (Reviewer).

src/java.base/share/classes/java/security/Key.java line 91:

> 89:  * @spec serialization/index.html Java Object Serialization Specification
> 90:  * @spec https://www.rfc-editor.org/info/rfc5280
> 91:  *        RFC 5280: Internet X.509 Public Key Infrastructure Certificate

any reason why you indented this comment with 8 spaces? All others are indented with 6

src/java.base/share/classes/java/security/cert/X509Certificate.java line 630:

> 628:      *              UTF-8 String Representation of Distinguished Names
> 629:      * @spec https://www.rfc-editor.org/info/rfc822
> 630:      *      RFC 822:: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES

Suggestion:

     *      RFC 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES

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

PR Review: https://git.openjdk.org/jdk/pull/13336#pullrequestreview-1373161162
PR Review Comment: https://git.openjdk.org/jdk/pull/13336#discussion_r1158675317
PR Review Comment: https://git.openjdk.org/jdk/pull/13336#discussion_r1158672811

From rriggs at openjdk.org  Wed Apr  5 15:48:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 15:48:02 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Backout unneeded changes to module-info and default.policy.
  Fixup formatting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/aadf5bbd..5546b824

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

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

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

From iris at openjdk.org  Wed Apr  5 16:27:21 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 5 Apr 2023 16:27:21 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <yNqK4eZqzxXtzGKEYf4MbbAaVHOB0Y785UAn1LuTvcs=.525903c3-871b-48b0-ab80-36917b999098@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1373282111

From jjg at openjdk.org  Wed Apr  5 16:35:15 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 5 Apr 2023 16:35:15 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v2]
In-Reply-To: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
Message-ID: <k-MCRF38Gk3gvVvDmcOblKUeTvTXLyWDKuOgo39irsA=.5e1ab8d4-17f5-413d-b2ef-ad15826e3d00@github.com>

> Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248)

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/security/cert/X509Certificate.java
  
  Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13336/files
  - new: https://git.openjdk.org/jdk/pull/13336/files/951df1af..2e5425b0

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

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

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

From jjg at openjdk.org  Wed Apr  5 16:35:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 5 Apr 2023 16:35:17 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v2]
In-Reply-To: <5LdxHbFCjmNDv-s9An5F63Cx8uux01flNCe8a2pb1Iw=.03f0fae6-e8d0-40af-aea1-2698c543fde2@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <5LdxHbFCjmNDv-s9An5F63Cx8uux01flNCe8a2pb1Iw=.03f0fae6-e8d0-40af-aea1-2698c543fde2@github.com>
Message-ID: <dymyZM_lYuS1AXCLD01QqfLVX1wYWs5JWcE82zB1Uto=.fa72ee22-12c8-460b-9bc5-db5dce65fe7d@github.com>

On Wed, 5 Apr 2023 15:23:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/security/cert/X509Certificate.java
>>   
>>   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>
> src/java.base/share/classes/java/security/Key.java line 91:
> 
>> 89:  * @spec serialization/index.html Java Object Serialization Specification
>> 90:  * @spec https://www.rfc-editor.org/info/rfc5280
>> 91:  *        RFC 5280: Internet X.509 Public Key Infrastructure Certificate
> 
> any reason why you indented this comment with 8 spaces? All others are indented with 6

I will change it to be consistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13336#discussion_r1158755137

From jjg at openjdk.org  Wed Apr  5 16:45:06 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 5 Apr 2023 16:45:06 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
Message-ID: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>

> Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248)

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13336/files
  - new: https://git.openjdk.org/jdk/pull/13336/files/2e5425b0..03a70694

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

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

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

From djelinski at openjdk.org  Wed Apr  5 17:54:19 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Apr 2023 17:54:19 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v2]
In-Reply-To: <odnIU2CVVA3icR0FUru394X-P7SpQ5VRpx4hP6fbN-M=.bbea50dd-2a64-4c54-9023-d02a58e09791@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <odnIU2CVVA3icR0FUru394X-P7SpQ5VRpx4hP6fbN-M=.bbea50dd-2a64-4c54-9023-d02a58e09791@github.com>
Message-ID: <2yOu0fB2oXs0yBd6brvrqOu6-kjOdLNZkZGtJr-Wj2A=.5858fa36-53df-42f4-ae5e-520bd744ca79@github.com>

On Mon, 3 Apr 2023 22:57:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

This looks like a nice improvement. You'll need to update the docs in all places where `networkaddress.cache.ttl` is mentioned, that is:
- https://github.com/openjdk/jdk/blob/0deb648985b018653ccdaf193dc13b3cf21c088a/src/java.base/share/classes/java/net/doc-files/net-properties.html#L263
- https://github.com/openjdk/jdk/blob/c6bd489cc8d30fb6eec865b3dab1cf861e25c8d7/src/java.base/share/classes/java/net/InetAddress.java#L200
- https://github.com/openjdk/jdk/blob/0deb648985b018653ccdaf193dc13b3cf21c088a/src/java.base/share/conf/security/java.security#L358

Plus, as Alan suggested, a CSR and a release note will also be necessary.

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

> 978:          * are removed from the expirySet and cache.
> 979:          */
> 980:         public boolean expired(long now) {

This method's name does not reflect what this method does. It may be worth splitting.

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

> 1024:         public InetAddress[] get() {
> 1025:             long now = System.nanoTime();
> 1026:             if ((refreshTime - now) < 0L && lookupLock.tryLock()) {

I like it how you only block one thread while refreshing and let other threads use the stale value.

src/java.base/share/classes/sun/net/InetAddressCachePolicy.java line 126:

> 124:             tmp = getProperty(cacheStalePolicyProp,
> 125:                               cacheStalePolicyPropFallback);
> 126:             if (tmp != null && tmp > cachePolicy) {

Why do you require cacheStalePolicy > cachePolicy? In your implementation, stale timer starts running after the base timer expires, so lower values still make sense.

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

PR Review: https://git.openjdk.org/jdk/pull/13285#pullrequestreview-1373340498
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1158790019
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1158822139
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1158824436

From djelinski at openjdk.org  Wed Apr  5 18:14:17 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Apr 2023 18:14:17 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
Message-ID: <LCp0BJA3QyDPxSc-eeOHKjunX1zsjO7msCiqUeiMfq4=.de93de57-7573-41e5-828a-f18072d469fb@github.com>

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

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

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13336#pullrequestreview-1373439503

From mullan at openjdk.org  Wed Apr  5 21:30:18 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 5 Apr 2023 21:30:18 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
Message-ID: <rx1-XyQLo1z1bNP_Ja_ePMwLRXtpOZRv2_Us32haY04=.e83a332d-a9f0-4642-99c2-0c9ed9bd7a82@github.com>

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

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

I plan to review this but may need a couple of days.

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

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

From duke at openjdk.org  Thu Apr  6 06:22:09 2023
From: duke at openjdk.org (Varada M)
Date: Thu, 6 Apr 2023 06:22:09 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v3]
In-Reply-To: <XXQIuVXd_bONLX1ETDmpwYg0NdHZdTFAVrVbIppipMI=.62fb6078-f552-419c-8f4a-075fff796674@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <QE6ST3-qCKq_WarGq2vLZtoqYUyGPDztqBuiZuleCZU=.ab42e5b5-1f85-4025-9d82-7deca21f6a87@github.com>
 <XXQIuVXd_bONLX1ETDmpwYg0NdHZdTFAVrVbIppipMI=.62fb6078-f552-419c-8f4a-075fff796674@github.com>
Message-ID: <U-QIVxoQRxTFzQGhXBh9-aXlekA40oNDsMkHAydrk8k=.e6c6ea9c-e8a3-4585-a0f4-c66a4cfb7a41@github.com>

On Wed, 5 Apr 2023 12:33:40 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Hi, could you check if the value returned by [Java_sun_nio_ch_Net_shouldSetBothIPv4AndIPv6Options0](https://github.com/openjdk/jdk/blob/0deb648985b018653ccdaf193dc13b3cf21c088a/src/java.base/unix/native/libnio/ch/Net.c#L159-L167) is correct on AIX?
> 
> More specifically, this piece of code should throw an exception mentioning that the message is too big for the underlying transport:
> 
> ```
> DatagramChannel channel = DatagramChannel.open(StandardProtocolFamily.INET6);
> channel.setOption(ExtendedSocketOptions.IP_DONTFRAGMENT, true);
> channel.send(ByteBuffer.allocate(64000),
>                     new InetSocketAddress("bugs.openjdk.org", 1234));
> ```
> 
> on Windows and Linux it works (i.e. throws) because `shouldSetBothIPv4AndIPv6Options0` returns `true`; on MacOSX it doesn't work even if `shouldSetBothIPv4AndIPv6Options0` returns `true`, so we return `false`; it would be interesting how AIX behaves here.

Hi @djelinski , On AIX I'm getting socket exception stating the message is too long.

STDERR:
java.net.SocketException: Message too long
        at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method)
        at java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:945)
        at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:921)
        at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:864)
        at DontFragmentTest.main(DontFragmentTest.java:54)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:578)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
        at java.base/java.lang.Thread.run(Thread.java:1623)

JavaTest Message: Test threw exception: java.net.SocketException: Message too long

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

PR Comment: https://git.openjdk.org/jdk/pull/13240#issuecomment-1498551079

From dfuchs at openjdk.org  Thu Apr  6 09:52:36 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Apr 2023 09:52:36 GMT
Subject: RFR: 8267140: Support closing the HttpClient by making it
 auto-closable [v17]
In-Reply-To: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
References: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
Message-ID: <-_feMIJMa7gM88jda3TIdyQ8mKinZf3By8vG9WP98Pg=.2e5039bf-df0a-44f3-a5c4-9847872c84b5@github.com>

> Please find here an RFE that makes the `java.net.HttpClient` auto-closeable.
> 
> The API has been modeled on `ExecutorService`.
> 
> HttpClient::close() is a graceful shutdown and will wait until all operations are terminated before returning.
> If a request is in progress, and the caller doesn't pull the corresponding data (for instance, the request was sent with a BodyHandler.ofInputStream(), but the caller stopped reading the input stream) then close() may never return.
> 
> Therefore, additional methods similar to those present in `ExecutorService` are also proposed. In summary:
> 
> - `shutdown()`: initiate a graceful shutdown, but doesn't wait for termination. 
> - `shutdownNow()`:  initiate an immediate shutdown, attempting to cancel all operations in progress. Doesn't wait for termination.
> - `awaitTermination(Duration)`: await for termination within the given delay
> - `isTerminated()` tells whether the client is terminated
> 
> New tests have been added to test the proposed behaviors.
> 
> HttpClient tests (new and old) are still stable.

Daniel Fuchs 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 25 additional commits since the last revision:

 - Merge branch 'master' into HttpClient-close-8267140
 - Further CSR review feedback
 - Merge branch 'master' into HttpClient-close-8267140
 - Included CSR review feedback
 - Merge branch 'master' into HttpClient-close-8267140
 - Fixed minor typos in test comments
 - Integrated feedback on tests
 - Minor updates. Added some links
 - Define operations. Clarify some of the things that may stall an orderly shutdown
 - Update src/java.net.http/share/classes/java/net/http/HttpClient.java
   
   Fixed typo
 - ... and 15 more: https://git.openjdk.org/jdk/compare/6d8ef3c5...4ebfca14

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13019/files
  - new: https://git.openjdk.org/jdk/pull/13019/files/6a9523a8..4ebfca14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13019&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13019&range=15-16

  Stats: 4535 lines in 136 files changed: 3552 ins; 483 del; 500 mod
  Patch: https://git.openjdk.org/jdk/pull/13019.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13019/head:pull/13019

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

From jpai at openjdk.org  Thu Apr  6 10:05:27 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Apr 2023 10:05:27 GMT
Subject: RFR: 8267140: Support closing the HttpClient by making it
 auto-closable [v17]
In-Reply-To: <-_feMIJMa7gM88jda3TIdyQ8mKinZf3By8vG9WP98Pg=.2e5039bf-df0a-44f3-a5c4-9847872c84b5@github.com>
References: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
 <-_feMIJMa7gM88jda3TIdyQ8mKinZf3By8vG9WP98Pg=.2e5039bf-df0a-44f3-a5c4-9847872c84b5@github.com>
Message-ID: <yPmjx8ruktJuk30cRGQR6mjxEosjEvUs9CBDEjH2ClA=.a3078728-dd8c-4c47-86b8-7212ed89d5e6@github.com>

On Thu, 6 Apr 2023 09:52:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here an RFE that makes the `java.net.HttpClient` auto-closeable.
>> 
>> The API has been modeled on `ExecutorService`.
>> 
>> HttpClient::close() is a graceful shutdown and will wait until all operations are terminated before returning.
>> If a request is in progress, and the caller doesn't pull the corresponding data (for instance, the request was sent with a BodyHandler.ofInputStream(), but the caller stopped reading the input stream) then close() may never return.
>> 
>> Therefore, additional methods similar to those present in `ExecutorService` are also proposed. In summary:
>> 
>> - `shutdown()`: initiate a graceful shutdown, but doesn't wait for termination. 
>> - `shutdownNow()`:  initiate an immediate shutdown, attempting to cancel all operations in progress. Doesn't wait for termination.
>> - `awaitTermination(Duration)`: await for termination within the given delay
>> - `isTerminated()` tells whether the client is terminated
>> 
>> New tests have been added to test the proposed behaviors.
>> 
>> HttpClient tests (new and old) are still stable.
>
> Daniel Fuchs 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 25 additional commits since the last revision:
> 
>  - Merge branch 'master' into HttpClient-close-8267140
>  - Further CSR review feedback
>  - Merge branch 'master' into HttpClient-close-8267140
>  - Included CSR review feedback
>  - Merge branch 'master' into HttpClient-close-8267140
>  - Fixed minor typos in test comments
>  - Integrated feedback on tests
>  - Minor updates. Added some links
>  - Define operations. Clarify some of the things that may stall an orderly shutdown
>  - Update src/java.net.http/share/classes/java/net/http/HttpClient.java
>    
>    Fixed typo
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/69a729e4...4ebfca14

Marked as reviewed by jpai (Reviewer).

Hello Daniel, the latest documentation changes all look fine to me.

As for:

>
>     2. An `@see ##closing Implementation Note on closing the HttpClient` is added instead, at the end of the method API documentation.

I haven't previously used this construct in a `@see`, so as long as the generated javadoc renders fine, this looks good. Does it render a `<a href=...>Implementation Note on closing the HttpClient</a>`?

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

PR Review: https://git.openjdk.org/jdk/pull/13019#pullrequestreview-1374504350
PR Comment: https://git.openjdk.org/jdk/pull/13019#issuecomment-1498802890

From dfuchs at openjdk.org  Thu Apr  6 10:09:33 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Apr 2023 10:09:33 GMT
Subject: RFR: 8267140: Support closing the HttpClient by making it
 auto-closable [v17]
In-Reply-To: <yPmjx8ruktJuk30cRGQR6mjxEosjEvUs9CBDEjH2ClA=.a3078728-dd8c-4c47-86b8-7212ed89d5e6@github.com>
References: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
 <-_feMIJMa7gM88jda3TIdyQ8mKinZf3By8vG9WP98Pg=.2e5039bf-df0a-44f3-a5c4-9847872c84b5@github.com>
 <yPmjx8ruktJuk30cRGQR6mjxEosjEvUs9CBDEjH2ClA=.a3078728-dd8c-4c47-86b8-7212ed89d5e6@github.com>
Message-ID: <v1qzGKg4olvKZvKaOTd7wfSeCy1HBD1VRIaaut6U1WI=.da626099-dd27-493c-94f8-085928801875@github.com>

On Thu, 6 Apr 2023 10:02:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>I haven't previously used this construct in a @see, so as long as the generated javadoc renders fine, this looks good. Does it render a <a href=...>Implementation Note on closing the HttpClient</a>?

yes - I have generated the api doc and it looks fine

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

PR Comment: https://git.openjdk.org/jdk/pull/13019#issuecomment-1498807454

From dfuchs at openjdk.org  Thu Apr  6 10:09:36 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Apr 2023 10:09:36 GMT
Subject: Integrated: 8267140: Support closing the HttpClient by making it
 auto-closable
In-Reply-To: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
References: <AvMyS3Uf1Rwzdh99KZ_uf9UcJVOwVW6KrRwstLPF-hs=.b81e5fd3-931a-44e4-873a-18d9f48e702a@github.com>
Message-ID: <ItXnJUdlyiQbgdmHWvvXvIaWBj9tlHoF7XdNPPUsfUU=.72fb63ae-7203-4ed4-bbb0-3c0560cbdf55@github.com>

On Tue, 14 Mar 2023 14:18:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here an RFE that makes the `java.net.HttpClient` auto-closeable.
> 
> The API has been modeled on `ExecutorService`.
> 
> HttpClient::close() is a graceful shutdown and will wait until all operations are terminated before returning.
> If a request is in progress, and the caller doesn't pull the corresponding data (for instance, the request was sent with a BodyHandler.ofInputStream(), but the caller stopped reading the input stream) then close() may never return.
> 
> Therefore, additional methods similar to those present in `ExecutorService` are also proposed. In summary:
> 
> - `shutdown()`: initiate a graceful shutdown, but doesn't wait for termination. 
> - `shutdownNow()`:  initiate an immediate shutdown, attempting to cancel all operations in progress. Doesn't wait for termination.
> - `awaitTermination(Duration)`: await for termination within the given delay
> - `isTerminated()` tells whether the client is terminated
> 
> New tests have been added to test the proposed behaviors.
> 
> HttpClient tests (new and old) are still stable.

This pull request has now been integrated.

Changeset: 6580c4e6
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6580c4e6311b6f87cec7c5c5537351bec9b703db
Stats:     2401 lines in 12 files changed: 2249 ins; 2 del; 150 mod

8267140: Support closing the HttpClient by making it auto-closable

Reviewed-by: jpai

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

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

From michaelm at openjdk.org  Thu Apr  6 10:35:14 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Apr 2023 10:35:14 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking
In-Reply-To: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
Message-ID: <MVfKkPr8wR6qvCbI2UFFyt6LIKtMCdU_MgfMNU155ok=.14668335-26d1-4a27-8ad9-c12147014bb2@github.com>

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

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

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

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

Afaik, the volatile reference to the Control object does not imply that references to its member fields are volatile, and they are being accessed from different threads.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13330#discussion_r1159613650

From michaelm at openjdk.org  Thu Apr  6 15:09:07 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Apr 2023 15:09:07 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v6]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <w6EdJomvvRARZuzkdYciVCAKi_kACrecJSZhDPflKo8=.dab39267-90f3-49d9-b804-d404d9193236@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  removed AuthenticationInfo serialization code plus other updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/db24a545..3c8600f9

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

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

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

From mullan at openjdk.org  Thu Apr  6 19:34:07 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 6 Apr 2023 19:34:07 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
Message-ID: <m4udm5H1KKWOFrFHbNbbof-gqipEvFbflX-l7-GTImE=.bf857f4e-b987-4eac-a675-aa5b23878cfb@github.com>

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

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

There are references to other specifications missing, like NIST Special Publication 800-90A Revision 1, referenced in `java.security.DrbgParameters`. I think there are others, I haven't done a thorough review yet. Will there be subsequent reviews for these, or should I point them out and have them resolved as part of this PR?

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

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

From jpai at openjdk.org  Fri Apr  7 05:59:46 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 05:59:46 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <P8j4Sb_G26s5EnX3hMY-OkBfW7izQLv1uflhTkdV6sM=.1688b147-9689-4eb1-aebb-9cc0a83b1cd8@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

Looks ok to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1375851004

From aturbanov at openjdk.org  Fri Apr  7 08:09:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 7 Apr 2023 08:09:46 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <MoRaAV2bfkpmtql8WLLyCK7oZuW7oIWJDzLSgmBAEvU=.e90d7846-8e32-4dba-a63e-1d9a2d69fc7e@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

src/java.prefs/share/classes/java/util/prefs/Preferences.java line 299:

> 297:         String platformFactory = switch (OperatingSystem.current()) {
> 298:             case WINDOWS -> "java.util.prefs.WindowsPreferencesFactory";
> 299:             case MACOS ->  "java.util.prefs.MacOSXPreferencesFactory";

Suggestion:

            case MACOS -> "java.util.prefs.MacOSXPreferencesFactory";

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1160525650

From ccleary at openjdk.org  Fri Apr  7 13:38:44 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Fri, 7 Apr 2023 13:38:44 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v3]
In-Reply-To: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
Message-ID: <RS8sUvzJsge3k94fR2fVX18agkfMPpSEbU0tIKYIjbE=.52922b71-87e4-4a5d-8b07-89d638ee492c@github.com>

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

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

  8293786: Reset completes exchange exceptionally for Error Codes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12694/files
  - new: https://git.openjdk.org/jdk/pull/12694/files/040ff23b..bd9cdeee

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

  Stats: 45 lines in 5 files changed: 30 ins; 7 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12694/head:pull/12694

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

From ccleary at openjdk.org  Fri Apr  7 13:46:48 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Fri, 7 Apr 2023 13:46:48 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v2]
In-Reply-To: <TBgRDYMZ1W6i_sH7sLEvfonZAcDX_9aRL6SrzYYUX88=.dede5a89-ae8e-4323-96b8-5a8b0379b1d8@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <a3Hwswq5vT_d8NHnSS7UzGg5KISpy2WIMtweAB00jxU=.d57c9290-9c26-4406-bf52-f65a6129b763@github.com>
 <TBgRDYMZ1W6i_sH7sLEvfonZAcDX_9aRL6SrzYYUX88=.dede5a89-ae8e-4323-96b8-5a8b0379b1d8@github.com>
Message-ID: <3ltzPs3Yy2My5fPpjSwIPr5AQwZ02kqBbR4QologKHo=.103c70a8-916f-4754-8050-e99d1acadc0a@github.com>

On Tue, 7 Mar 2023 15:05:17 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Conor Cleary 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 three additional commits since the last revision:
>> 
>>  - 8293786: Server-side reset implemented, updated comments on incoming_reset
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8293786
>>  - 8293786: HttpClient will not send more than 64 kb of data from the 2nd request in http2
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 560:
> 
>> 558:                 // response to be read before the Reset is handled in the case where the client's
>> 559:                 // input stream is partially consumed or not consumed at all by the server.
>> 560:                 requestBodyCF.complete(null);
> 
> Doesn't seem right: if the error code != NO_ERROR we should probably complete the requestBodyCf exceptionally?

There is now a `completeExceptionally(new IOException("..."))` call is if `frame.ErrorCode() != NO_ERROR`. Otherwise, `complete(null)` is called.

> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/BodyInputStream.java line 44:
> 
>> 42:     final Queue<Http2Frame> q;
>> 43:     final int streamid;
>> 44:     boolean closed;
> 
> Maybe `closed` should be volatile as well

Agreed, this is the case now

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

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

From ccleary at openjdk.org  Fri Apr  7 13:46:49 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Fri, 7 Apr 2023 13:46:49 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v2]
In-Reply-To: <3ltzPs3Yy2My5fPpjSwIPr5AQwZ02kqBbR4QologKHo=.103c70a8-916f-4754-8050-e99d1acadc0a@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <a3Hwswq5vT_d8NHnSS7UzGg5KISpy2WIMtweAB00jxU=.d57c9290-9c26-4406-bf52-f65a6129b763@github.com>
 <TBgRDYMZ1W6i_sH7sLEvfonZAcDX_9aRL6SrzYYUX88=.dede5a89-ae8e-4323-96b8-5a8b0379b1d8@github.com>
 <3ltzPs3Yy2My5fPpjSwIPr5AQwZ02kqBbR4QologKHo=.103c70a8-916f-4754-8050-e99d1acadc0a@github.com>
Message-ID: <Me0PGdyCf5KMQl_b7ZbV66UYRRDzSdcOm9TlZMvO2o8=.89a45d46-2361-4599-a4ab-1dfac7769e75@github.com>

On Fri, 7 Apr 2023 13:43:42 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 560:
>> 
>>> 558:                 // response to be read before the Reset is handled in the case where the client's
>>> 559:                 // input stream is partially consumed or not consumed at all by the server.
>>> 560:                 requestBodyCF.complete(null);
>> 
>> Doesn't seem right: if the error code != NO_ERROR we should probably complete the requestBodyCf exceptionally?
>
> There is now a `completeExceptionally(new IOException("..."))` call is if `frame.ErrorCode() != NO_ERROR`. Otherwise, `complete(null)` is called.

Agree that this is better behaviour. Should we test for the case where an ErrorCode is given?

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

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

From ccleary at openjdk.org  Fri Apr  7 13:46:51 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Fri, 7 Apr 2023 13:46:51 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v2]
In-Reply-To: <VVA9001ABhuGVsbBQjcTNjMA4ZG6ERoVUrsarhatoyI=.c0efbcf7-ac5f-45cf-8607-ea565b3b2f7d@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <a3Hwswq5vT_d8NHnSS7UzGg5KISpy2WIMtweAB00jxU=.d57c9290-9c26-4406-bf52-f65a6129b763@github.com>
 <1K6wi_-jxPIAVQi46UnLsJG7mLTJoFyDOHRKYZTyq-I=.18105161-981d-4de7-8641-1bc5b42b5617@github.com>
 <hTGud-1T7fAjCqzEH63KW2RGSYMUTVRo-ViXxEekva4=.49c02a7d-f57d-4ccb-bcd9-7e6454928f20@github.com>
 <uFw50Cb46yEXT3CZb9tT0FtSmivbJnMk9C9KasMviaY=.d7ee74bf-8884-4a1d-9861-a4add7ccf0ed@github.com>
 <VVA9001ABhuGVsbBQjcTNjMA4ZG6ERoVUrsarhatoyI=.c0efbcf7-ac5f-45cf-8607-ea565b3b2f7d@github.com>
Message-ID: <QJO-VmZUfmfHox4_W2QBB8NvFsSPqjWSh_xzE9Hs5T0=.0aababf2-e253-4228-86e3-0f7204c59c74@github.com>

On Tue, 7 Mar 2023 15:15:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> To add on to the explanation given by the in-line comments. 
>> 
>> - If an END_STREAM is not seen by the `BodyInputStream`, `bis`, then the client has stopped transmitting for some reason. For example if the sendWindow has been exceeded and the client is waiting for WINDOW_UPDATE frames. This can occur if the InputStream is not fully consumed by the exchange handler too.
>> - It is possible too that the EOF has been seen but that the `BodyInputStream's` Queue is non empty. This is why an || is used instead of an &&.
>> 
>> Through testing this seems to be the most stable solution, this code usually should only get triggered in test cases including a test handler which does not consume the input stream.
>
> This is strange and probably too late: when you reach here the bos has probably already been closed by the handler, so setting the flag will have no effect in the usual case.

In the usual case yes, if the handler reads the stream this code will have no effect. I think thats what we want though as we don't want the sending of reset frame to be triggered if the server handler reads/closes the stream. It should only be sent when the stream has not been closed/consumed by the handler and the exchanges send window has been exceeded.

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

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

From dfuchs at openjdk.org  Fri Apr  7 14:06:44 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Apr 2023 14:06:44 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v2]
In-Reply-To: <QJO-VmZUfmfHox4_W2QBB8NvFsSPqjWSh_xzE9Hs5T0=.0aababf2-e253-4228-86e3-0f7204c59c74@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <a3Hwswq5vT_d8NHnSS7UzGg5KISpy2WIMtweAB00jxU=.d57c9290-9c26-4406-bf52-f65a6129b763@github.com>
 <1K6wi_-jxPIAVQi46UnLsJG7mLTJoFyDOHRKYZTyq-I=.18105161-981d-4de7-8641-1bc5b42b5617@github.com>
 <hTGud-1T7fAjCqzEH63KW2RGSYMUTVRo-ViXxEekva4=.49c02a7d-f57d-4ccb-bcd9-7e6454928f20@github.com>
 <uFw50Cb46yEXT3CZb9tT0FtSmivbJnMk9C9KasMviaY=.d7ee74bf-8884-4a1d-9861-a4add7ccf0ed@github.com>
 <VVA9001ABhuGVsbBQjcTNjMA4ZG6ERoVUrsarhatoyI=.c0efbcf7-ac5f-45cf-8607-ea565b3b2f7d@github.com>
 <QJO-VmZUfmfHox4_W2QBB8NvFsSPqjWSh_xzE9Hs5T0=.0aababf2-e253-4228-86e3-0f7204c59c74@github.com>
Message-ID: <u2wyQlgQPIGVb_Hmw8H7pHwykBTXVctcZKJvWMtYTRo=.13d1e8d2-fe28-47c3-ad11-309dfcd1e058@github.com>

On Fri, 7 Apr 2023 13:41:23 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> This is strange and probably too late: when you reach here the bos has probably already been closed by the handler, so setting the flag will have no effect in the usual case.
>
> In the usual case yes, if the handler reads the stream this code will have no effect. I think thats what we want though as we don't want the sending of reset frame to be triggered if the server handler reads/closes the stream. It should only be sent when the stream has not been closed/consumed by the handler and the exchanges send window has been exceeded.

I see. That sounds right. Can you had a comment above line 736 to explain that?

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

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

From rriggs at openjdk.org  Fri Apr  7 14:24:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 14:24:37 GMT
Subject: RFR: 8304911: Use OperatingSystem enum in some modules [v4]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <Usevw300y_mQRvFgSwqQlXsxI8LHs0hb38Xk6PuTx1g=.64512eff-175f-4da7-a1e2-34afd8936b3c@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove errant space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/5546b824..b9267942

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

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

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

From mpowers at openjdk.org  Fri Apr  7 19:16:47 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Fri, 7 Apr 2023 19:16:47 GMT
Subject: RFR: JDK-8302696 Revert API signature changes made in JDK-8285504 and
 JDK-8285263
Message-ID: <zCM_RV3fofY3zjylJKmGv2LL-oDTxrkdRkzLmrZfUiI=.10758d5e-33ba-4629-80c7-2b045a2283d5@github.com>

https://bugs.openjdk.org/browse/JDK-8302696

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

Commit messages:
 - Merge
 - first iteration

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

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

From mullan at openjdk.org  Fri Apr  7 19:48:44 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 7 Apr 2023 19:48:44 GMT
Subject: RFR: JDK-8302696 Revert API signature changes made in JDK-8285504
 and JDK-8285263
In-Reply-To: <zCM_RV3fofY3zjylJKmGv2LL-oDTxrkdRkzLmrZfUiI=.10758d5e-33ba-4629-80c7-2b045a2283d5@github.com>
References: <zCM_RV3fofY3zjylJKmGv2LL-oDTxrkdRkzLmrZfUiI=.10758d5e-33ba-4629-80c7-2b045a2283d5@github.com>
Message-ID: <w7_ZOyCwypz0QqtQGaoLY_5qRnWlUb1ggM9z2aoPhWA=.c434c5f0-4f09-4f91-8881-30ac1ee608e8@github.com>

On Fri, 7 Apr 2023 19:09:43 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8302696

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13391#pullrequestreview-1376528212

From rriggs at openjdk.org  Mon Apr 10 15:53:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Apr 2023 15:53:54 GMT
Subject: Integrated: 8304911: Use OperatingSystem enum in some modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <cYBk3ZVUnDppbIZGj79ENgNctV4SjMCgrAXF1Jf_Sd8=.150e8aac-3658-4a6e-876c-9c3147847104@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

This pull request has now been integrated.

Changeset: ba90dc77
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba90dc77958c399e4e1fc3c4999dd76680480c7b
Stats:     120 lines in 12 files changed: 20 ins; 50 del; 50 mod

8304911: Use OperatingSystem enum in some modules

Reviewed-by: naoto, lancea, iris, jpai

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

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

From ccleary at openjdk.org  Tue Apr 11 08:26:36 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 11 Apr 2023 08:26:36 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v2]
In-Reply-To: <u2wyQlgQPIGVb_Hmw8H7pHwykBTXVctcZKJvWMtYTRo=.13d1e8d2-fe28-47c3-ad11-309dfcd1e058@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <a3Hwswq5vT_d8NHnSS7UzGg5KISpy2WIMtweAB00jxU=.d57c9290-9c26-4406-bf52-f65a6129b763@github.com>
 <1K6wi_-jxPIAVQi46UnLsJG7mLTJoFyDOHRKYZTyq-I=.18105161-981d-4de7-8641-1bc5b42b5617@github.com>
 <hTGud-1T7fAjCqzEH63KW2RGSYMUTVRo-ViXxEekva4=.49c02a7d-f57d-4ccb-bcd9-7e6454928f20@github.com>
 <uFw50Cb46yEXT3CZb9tT0FtSmivbJnMk9C9KasMviaY=.d7ee74bf-8884-4a1d-9861-a4add7ccf0ed@github.com>
 <VVA9001ABhuGVsbBQjcTNjMA4ZG6ERoVUrsarhatoyI=.c0efbcf7-ac5f-45cf-8607-ea565b3b2f7d@github.com>
 <QJO-VmZUfmfHox4_W2QBB8NvFsSPqjWSh_xzE9Hs5T0=.0aababf2-e253-4228-86e3-0f7204c59c74@github.com>
 <u2wyQlgQPIGVb_Hmw8H7pHwykBTXVctcZKJvWMtYTRo=.13d1e8d2-fe28-47c3-ad11-309dfcd1e058@github.com>
Message-ID: <THq7RAeFEYDLP4DPf2vaYw82R3Pz9ur8XtsSA3jCSO8=.18c1f534-af08-4e35-83be-109277d3683b@github.com>

On Fri, 7 Apr 2023 14:03:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> In the usual case yes, if the handler reads the stream this code will have no effect. I think thats what we want though as we don't want the sending of reset frame to be triggered if the server handler reads/closes the stream. It should only be sent when the stream has not been closed/consumed by the handler and the exchanges send window has been exceeded.
>
> I see. That sounds right. Can you had a comment above line 736 to explain that?

Was thinking of putting the comment:


// If the handler reads the exchange's InputStream, this code will have no effect. If the handler does not
// read the exchange's InputStream and the send window has been exceeded, then the stream will be reset.


Sort of a simplified version of my previous PR comment to you

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

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

From michaelm at openjdk.org  Tue Apr 11 09:42:41 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 11 Apr 2023 09:42:41 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v7]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <jFHxjBRzzrSkwFMUaB1s6hRFIg-u42KBof__86J4vJc=.85b574df-adf3-4bad-a8dc-513de4300756@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

Michael McMahon 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 ten additional commits since the last revision:

 - Merge branch 'master' into auth
 - removed AuthenticationInfo serialization code plus other updates
 - update
 - Merge branch 'master' into auth
 - updated implementation and reimpl of AuthenticatoKeys
 - review updates
 - test update
 - revert removed methods (used in tests)
 - initial impl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/3c8600f9..6636ac3f

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

  Stats: 28635 lines in 725 files changed: 13299 ins; 13590 del; 1746 mod
  Patch: https://git.openjdk.org/jdk/pull/13159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13159/head:pull/13159

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

From jpai at openjdk.org  Tue Apr 11 11:32:22 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Apr 2023 11:32:22 GMT
Subject: RFR: 8305529: DefaultProxySelector.select(URI) in certain cases
 returns a List with null element
Message-ID: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>

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

There were a couple of places in the `DefaultProxySelector.c` (for unix variant) where we would end up returning an array with `null` element in it, when an error was detected by the underlying library that we invoke upon. The change here fixes those places to immediately return a `null` instance instead of an array, when iterating over the configured proxies. This matches with how we handle similar issues within the code (as well as on other OS, like windows and macos).

A jtreg test case has been added which reproduces on variant of the reported bug and verifies the fix. As noted in the JBS issue, the other variant of the bug (where environment variables have empty values) isn't reproducible and that appears to be because the underlying library that we use, now has a fix/change to ignore such proxy values.

One round of testing has completed without any issues. I have triggered a more extensive tier testing to make sure nothing regresses.

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

Commit messages:
 - 8305529: DefaultProxySelector.select(URI) in certain cases returns a List with null element

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

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

From jpai at openjdk.org  Tue Apr 11 11:32:22 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Apr 2023 11:32:22 GMT
Subject: RFR: 8305529: DefaultProxySelector.select(URI) in certain cases
 returns a List with null element
In-Reply-To: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
References: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
Message-ID: <-pO4fhcIMnnBnE0gW9CXUZmkwdrKYTD_oq7ApeWZkyY=.53dd6fc0-42f1-4d39-89aa-fe310f0c31ba@github.com>

On Tue, 11 Apr 2023 11:24:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305529?
> 
> There were a couple of places in the `DefaultProxySelector.c` (for unix variant) where we would end up returning an array with `null` element in it, when an error was detected by the underlying library that we invoke upon. The change here fixes those places to immediately return a `null` instance instead of an array, when iterating over the configured proxies. This matches with how we handle similar issues within the code (as well as on other OS, like windows and macos).
> 
> A jtreg test case has been added which reproduces on variant of the reported bug and verifies the fix. As noted in the JBS issue, the other variant of the bug (where environment variables have empty values) isn't reproducible and that appears to be because the underlying library that we use, now has a fix/change to ignore such proxy values.
> 
> One round of testing has completed without any issues. I have triggered a more extensive tier testing to make sure nothing regresses.

I have looked through the macos, windows and even the gconf code in the unix variant of `DefaultProxySelector.c` to see if there's other similar places which need such attention, and I haven't found any.

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

PR Comment: https://git.openjdk.org/jdk/pull/13424#issuecomment-1503157767

From dfuchs at openjdk.org  Tue Apr 11 11:38:36 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Apr 2023 11:38:36 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v2]
In-Reply-To: <THq7RAeFEYDLP4DPf2vaYw82R3Pz9ur8XtsSA3jCSO8=.18c1f534-af08-4e35-83be-109277d3683b@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <a3Hwswq5vT_d8NHnSS7UzGg5KISpy2WIMtweAB00jxU=.d57c9290-9c26-4406-bf52-f65a6129b763@github.com>
 <1K6wi_-jxPIAVQi46UnLsJG7mLTJoFyDOHRKYZTyq-I=.18105161-981d-4de7-8641-1bc5b42b5617@github.com>
 <hTGud-1T7fAjCqzEH63KW2RGSYMUTVRo-ViXxEekva4=.49c02a7d-f57d-4ccb-bcd9-7e6454928f20@github.com>
 <uFw50Cb46yEXT3CZb9tT0FtSmivbJnMk9C9KasMviaY=.d7ee74bf-8884-4a1d-9861-a4add7ccf0ed@github.com>
 <VVA9001ABhuGVsbBQjcTNjMA4ZG6ERoVUrsarhatoyI=.c0efbcf7-ac5f-45cf-8607-ea565b3b2f7d@github.com>
 <QJO-VmZUfmfHox4_W2QBB8NvFsSPqjWSh_xzE9Hs5T0=.0aababf2-e253-4228-86e3-0f7204c59c74@github.com>
 <u2wyQlgQPIGVb_Hmw8H7pHwykBTXVctcZKJvWMtYTRo=.13d1e8d2-fe28-47c3-ad11-309dfcd1e058@github.com>
 <THq7RAeFEYDLP4DPf2vaYw82R3Pz9ur8XtsSA3jCSO8=.18c1f534-af08-4e35-83be-109277d3683b@github.com>
Message-ID: <Y7025iwjcrBRsrUaYlQJDFzTKLc0yv9GUFCkb0uqpPg=.907777f0-8091-4926-bccd-ae38ac30d5af@github.com>

On Tue, 11 Apr 2023 08:23:28 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> I see. That sounds right. Can you had a comment above line 736 to explain that?
>
> Was thinking of putting the comment:
> 
> 
> // If the handler reads the exchange's InputStream, this code will have no effect. If the handler does not
> // read the exchange's InputStream and the send window has been exceeded, then the stream will be reset.
> 
> 
> Sort of a simplified version of my previous PR comment to you

Sounds good. But won't the stream be reset even if the send windows hasn't been exceeded? I mean - it will be reset if not all data has been read off the stream, isn't it?

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

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

From dfuchs at openjdk.org  Tue Apr 11 13:05:35 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Apr 2023 13:05:35 GMT
Subject: RFR: 8305529: DefaultProxySelector.select(URI) in certain cases
 returns a List with null element
In-Reply-To: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
References: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
Message-ID: <hQYERXL89rLDsGHcQMsfiCxE6S4O2m1rRIJSQYeC47k=.8655900d-e53b-49d5-8338-1573d1234a3b@github.com>

On Tue, 11 Apr 2023 11:24:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305529?
> 
> There were a couple of places in the `DefaultProxySelector.c` (for unix variant) where we would end up returning an array with `null` element in it, when an error was detected by the underlying library that we invoke upon. The change here fixes those places to immediately return a `null` instance instead of an array, when iterating over the configured proxies. This matches with how we handle similar issues within the code (as well as on other OS, like windows and macos).
> 
> A jtreg test case has been added which reproduces on variant of the reported bug and verifies the fix. As noted in the JBS issue, the other variant of the bug (where environment variables have empty values) isn't reproducible and that appears to be because the underlying library that we use, now has a fix/change to ignore such proxy values.
> 
> One round of testing has completed without any issues. I have triggered a more extensive tier testing to make sure nothing regresses.

Sounds reasonable to me. Maybe wait until Daniel or Michael get a chance to look at the fix before integrating.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13424#pullrequestreview-1379202764

From jpai at openjdk.org  Tue Apr 11 13:14:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Apr 2023 13:14:33 GMT
Subject: RFR: 8305529: DefaultProxySelector.select(URI) in certain cases
 returns a List with null element
In-Reply-To: <hQYERXL89rLDsGHcQMsfiCxE6S4O2m1rRIJSQYeC47k=.8655900d-e53b-49d5-8338-1573d1234a3b@github.com>
References: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
 <hQYERXL89rLDsGHcQMsfiCxE6S4O2m1rRIJSQYeC47k=.8655900d-e53b-49d5-8338-1573d1234a3b@github.com>
Message-ID: <742BqUoeFKjUzqOcwkbfqY1coPnAqDRLeV81OkSN3CU=.6b05fe6c-ff8f-403c-af00-75b8a621f75c@github.com>

On Tue, 11 Apr 2023 13:02:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Maybe wait until Daniel or Michael get a chance to look at the fix before integrating.

Certainly.

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

PR Comment: https://git.openjdk.org/jdk/pull/13424#issuecomment-1503327443

From ccleary at openjdk.org  Tue Apr 11 13:50:31 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 11 Apr 2023 13:50:31 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v4]
In-Reply-To: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
Message-ID: <p6d4MbKArIpG0X4_gMpsLMA7nr4A6C_L6kzjAV93zKU=.3433ab41-6c54-49a3-a1b0-3e59e77c31a7@github.com>

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

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

  8293786: Updated comment in Http2TestServerConnection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12694/files
  - new: https://git.openjdk.org/jdk/pull/12694/files/bd9cdeee..556ba788

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

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

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

From ccleary at openjdk.org  Tue Apr 11 13:50:31 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Tue, 11 Apr 2023 13:50:31 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v3]
In-Reply-To: <RS8sUvzJsge3k94fR2fVX18agkfMPpSEbU0tIKYIjbE=.52922b71-87e4-4a5d-8b07-89d638ee492c@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <RS8sUvzJsge3k94fR2fVX18agkfMPpSEbU0tIKYIjbE=.52922b71-87e4-4a5d-8b07-89d638ee492c@github.com>
Message-ID: <dMOmscUwUZiIcpk8r8aDm1qZuvVsnWhThABWft7a4fw=.83b85e06-0fce-4820-a006-7731ee4144f3@github.com>

On Fri, 7 Apr 2023 13:38:44 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

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

Added a comment to `Http2TestServerConnection.java` explaining the contents of the finally block in `handleRequest()`. This PR is probably ready for final review but any other feedback is of course also welcome!

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

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

From dfuchs at openjdk.org  Tue Apr 11 13:54:42 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Apr 2023 13:54:42 GMT
Subject: RFR: 8305847: Improve diagnosability and resilience of
 HttpClient::close tests
Message-ID: <Dwv_Z5AGTOduVyE57m-Frv58JEBr9Nk9d6t5GLK2fpo=.f3e60bed-37d7-4db8-9776-84e910273c15@github.com>

The HttpClient close tests could be improved to provide better diagnosis. 

The tests make some requests and register some dependent actions to check the response state, followed by some dependent action that will read the request body (from an input stream). But if the first dependent action asserts, the second will not be executed, and the body will neither be read or closed.
This will later prevent HttpClient::close method, or the HttpClient::awaitTermination method, to terminate as expected, and the test will then later fail in timeout (either from jtreg or awaitTermination). This behaviour can be confusing for failure analysis. 

The tests could also be further simplified by creating the executor in which the responses bodies will eventually be read (called `readerService`) in the `setup()` method and later close it in `teardown()`. This will simplify the cleanup phase, and ensure the service does not get closed until all dependent actions have been scheduled.

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

Commit messages:
 - 8305847

Changes: https://git.openjdk.org/jdk/pull/13426/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305847
  Stats: 278 lines in 4 files changed: 168 ins; 54 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/13426.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13426/head:pull/13426

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

From dfuchs at openjdk.org  Tue Apr 11 13:54:46 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Apr 2023 13:54:46 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v4]
In-Reply-To: <p6d4MbKArIpG0X4_gMpsLMA7nr4A6C_L6kzjAV93zKU=.3433ab41-6c54-49a3-a1b0-3e59e77c31a7@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <p6d4MbKArIpG0X4_gMpsLMA7nr4A6C_L6kzjAV93zKU=.3433ab41-6c54-49a3-a1b0-3e59e77c31a7@github.com>
Message-ID: <u9eA1msxCwVpp_zHNd2FSGF2n4xL6mizW2-t_jOvfGk=.cbd6c827-1664-4fdd-8de0-a5f557d63c42@github.com>

On Tue, 11 Apr 2023 13:50:31 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

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

Marked as reviewed by dfuchs (Reviewer).

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

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

From mpowers at openjdk.org  Tue Apr 11 14:45:47 2023
From: mpowers at openjdk.org (Mark Powers)
Date: Tue, 11 Apr 2023 14:45:47 GMT
Subject: Integrated: JDK-8302696 Revert API signature changes made in
 JDK-8285504 and JDK-8285263
In-Reply-To: <zCM_RV3fofY3zjylJKmGv2LL-oDTxrkdRkzLmrZfUiI=.10758d5e-33ba-4629-80c7-2b045a2283d5@github.com>
References: <zCM_RV3fofY3zjylJKmGv2LL-oDTxrkdRkzLmrZfUiI=.10758d5e-33ba-4629-80c7-2b045a2283d5@github.com>
Message-ID: <BeVsKjSie4CnqMzPx8h3CTqoue675oLO3MDKPwMheow=.8265224a-d112-4b69-ad03-6280608dec59@github.com>

On Fri, 7 Apr 2023 19:09:43 GMT, Mark Powers <mpowers at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8302696

This pull request has now been integrated.

Changeset: 9486969b
Author:    Mark Powers <mpowers at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9486969bd3cb084c89a7255de0c664c980d1e661
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8302696: Revert API signature changes made in JDK-8285504 and JDK-8285263

Reviewed-by: mullan

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

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

From jjg at openjdk.org  Tue Apr 11 18:21:56 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 11 Apr 2023 18:21:56 GMT
Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and
 inlineContent
Message-ID: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>

Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment.

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

Depends on: https://git.openjdk.org/jdk/pull/13362

Commit messages:
 - JDK-8305713: DocCommentParser: merge blockContent and inlineContent
 - 8272119: Typo in JDK documentation (a -> an)
 - 8305461: [vectorapi] Add VectorMask::xor
 - 8305608: Change VMConnection to use "test.class.path"instead of "test.classes"
 - 8274166: Some CDS tests ignore -Dtest.cds.runtime.options
 - 8304745: Lazily initialize byte[] in java.io.BufferedInputStream
 - 8267140: Support closing the HttpClient by making it auto-closable
 - 8269843: typo in LinkedHashMap::removeEldestEntry spec
 - 8305480: test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java failing on 32 bit arm
 - 8305607: Remove some unused test parameters in com/sun/jdi tests
 - ... and 6 more: https://git.openjdk.org/jdk/compare/44f33ad1...b8b43eae

Changes: https://git.openjdk.org/jdk/pull/13431/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13431&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305713
  Stats: 5934 lines in 119 files changed: 5071 ins; 480 del; 383 mod
  Patch: https://git.openjdk.org/jdk/pull/13431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13431/head:pull/13431

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

From jjg at openjdk.org  Tue Apr 11 18:35:12 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 11 Apr 2023 18:35:12 GMT
Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and
 inlineContent [v2]
In-Reply-To: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
References: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
Message-ID: <m4FKFQc83YnYk50tr42KC2uCVa1Mx6ohf16CAoYkP0U=.6c3c7753-cc46-4ac3-a304-fb3c4abeab0e@github.com>

> Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment.

Jonathan Gibbons has updated the pull request incrementally with 42 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8305713.dcp-content
 - 8305809: (fs) Review obsolete Linux kernel dependency on os.version (Unix kernel 2.6.39)
   
   Reviewed-by: rriggs, alanb
 - 8294806: jpackaged-app ignores splash screen from jar file
   
   Reviewed-by: almatvee
 - 8305368: G1 remset chunk claiming may use relaxed memory ordering
   
   Reviewed-by: ayang, iwalulya
 - 8305370: Inconsistent use of for_young_only_phase parameter in G1 predictions
   
   Reviewed-by: iwalulya, kbarrett
 - 8305663: Wrong iteration order of pause array in g1MMUTracker
   
   Reviewed-by: ayang, tschatzl
 - 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries
   
   Reviewed-by: alanb, kevinw
 - 8305419: JDK-8301995 broke building libgraal
   
   Reviewed-by: matsaave, dnsimon, thartmann
 - 8302696: Revert API signature changes made in JDK-8285504 and JDK-8285263
   
   Reviewed-by: mullan
 - 8304738: UnregisteredClassesTable_lock never created
   
   Reviewed-by: iklam, jcking, dholmes
 - ... and 32 more: https://git.openjdk.org/jdk/compare/b8b43eae...ab56c463

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13431/files
  - new: https://git.openjdk.org/jdk/pull/13431/files/b8b43eae..ab56c463

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

  Stats: 9487 lines in 384 files changed: 2654 ins; 5914 del; 919 mod
  Patch: https://git.openjdk.org/jdk/pull/13431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13431/head:pull/13431

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

From jjg at openjdk.org  Tue Apr 11 18:39:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 11 Apr 2023 18:39:53 GMT
Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and
 inlineContent [v3]
In-Reply-To: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
References: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
Message-ID: <jr7O3o6GmhaZ6OcVVF0l9qrkBHGju4UC-60To5CDahE=.52854f35-c016-4a1a-8a86-78dcc1453de7@github.com>

> Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge branch 'pr/13362' into pr/13362
 - Merge remote-tracking branch 'upstream/master' into 8305713.dcp-content
 - 8305809: (fs) Review obsolete Linux kernel dependency on os.version (Unix kernel 2.6.39)
   
   Reviewed-by: rriggs, alanb
 - 8294806: jpackaged-app ignores splash screen from jar file
   
   Reviewed-by: almatvee
 - 8305368: G1 remset chunk claiming may use relaxed memory ordering
   
   Reviewed-by: ayang, iwalulya
 - 8305370: Inconsistent use of for_young_only_phase parameter in G1 predictions
   
   Reviewed-by: iwalulya, kbarrett
 - 8305663: Wrong iteration order of pause array in g1MMUTracker
   
   Reviewed-by: ayang, tschatzl
 - 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries
   
   Reviewed-by: alanb, kevinw
 - 8305419: JDK-8301995 broke building libgraal
   
   Reviewed-by: matsaave, dnsimon, thartmann
 - 8302696: Revert API signature changes made in JDK-8285504 and JDK-8285263
   
   Reviewed-by: mullan
 - ... and 49 more: https://git.openjdk.org/jdk/compare/5501bf21...45ee028b

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

Changes: https://git.openjdk.org/jdk/pull/13431/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13431&range=02
  Stats: 15292 lines in 500 files changed: 7710 ins; 6358 del; 1224 mod
  Patch: https://git.openjdk.org/jdk/pull/13431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13431/head:pull/13431

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

From jiangli at openjdk.org  Tue Apr 11 19:25:25 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Apr 2023 19:25:25 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError' when
 statically linking with JDK native libraries
Message-ID: <g3oGVtC_e7QXpX9duoKG8UvErLjuej7bNM5UjH336Dg=.5ad810ef-44cd-42f6-8097-a890d2c95bd3@github.com>

Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves related duplicate symbol failure when both libnio and libsctp are statically linked with.

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

Commit messages:
 - 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries

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

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

From jiangli at openjdk.org  Tue Apr 11 22:33:42 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Apr 2023 22:33:42 GMT
Subject: Withdrawn: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <g3oGVtC_e7QXpX9duoKG8UvErLjuej7bNM5UjH336Dg=.5ad810ef-44cd-42f6-8097-a890d2c95bd3@github.com>
References: <g3oGVtC_e7QXpX9duoKG8UvErLjuej7bNM5UjH336Dg=.5ad810ef-44cd-42f6-8097-a890d2c95bd3@github.com>
Message-ID: <JuZ-yUzcwWEo1ITyibZNkGtV4eWlwFIOhEbknlqqBf8=.ca49a43d-542c-4099-89c3-1005c730afba@github.com>

On Tue, 11 Apr 2023 19:19:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves related duplicate symbol failure when both libnio and libsctp are statically linked with.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Wed Apr 12 01:21:41 2023
From: duke at openjdk.org (Dhamoder Nalla)
Date: Wed, 12 Apr 2023 01:21:41 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a silent
 exception, negatively impacting performance
Message-ID: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>

Issue 8305763 : Using underscores in the name for a URI triggers a silent exception in the java standard library, which consumes 5% of the CPU.

Exception:
java.net.URISyntaxException: Illegal character in hostname at index N: xyz1_abcd.com
    at java.base/java.net.URI$Parser.fail(URI.java:2943)
    at java.base/java.net.URI$Parser.parseHostname(URI.java:3487)
    at java.base/java.net.URI$Parser.parseServer(URI.java:3329)
    
    This exception is silent and does not produce any messages, except for ODP profiler, there is no other evidence that it?s happening (the stack trace above was printed after changes to Java library). The reason for this is because of how the URI creation is implemented in the java.net.URI class. There are two paths for creating a valid URI, and one of them goes through an exception.

We can see that if parseServer fails, there is still a way the authority gets assigned and we don?t throw an exception from the method. This means, not being able to parse the server is ok and the exception is silenced. In our case, the server parsing fails because we find an illegal character, as only alphanumeric and dash characters are allowed.

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

Commit messages:
 - Parsing a URI with an underscore goes through a silent exception, negatively impacting performance

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

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

From jiangli at openjdk.org  Wed Apr 12 03:29:36 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 03:29:36 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError' when
 statically linking with JDK native libraries
Message-ID: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>

Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.

Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.

(Sorry about the earlier RFR/Withdrawn noise.)

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

Commit messages:
 - 8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries

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

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

From jiangli at openjdk.org  Wed Apr 12 03:29:37 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 03:29:37 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
Message-ID: <kLWWNdDkdoeUNGpyPd-cGDVwEw7oYKMT5Jtc8YyZGPw=.56098905-b018-4455-b803-dc4d44c82cce@github.com>

On Wed, 12 Apr 2023 03:20:47 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
> 
> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
> 
> (Sorry about the earlier RFR/Withdrawn noise.)

I noticed there is a presubmit test failure: https://github.com/jianglizhou/jdk/actions/runs/4672962155#user-content-java_lang_thread_virtual_tracevirtualthreadlocals for linux-x86. It appears to be unrelated. Will file a bug tomorrow if there is not existing bug (will check before filing).

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1504522861

From alanb at openjdk.org  Wed Apr 12 06:32:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 06:32:40 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
Message-ID: <NnM-UCb2Uxd8ncH6BEqgDu0YTjhZE2UmmwdNB4Mh_f4=.376a705e-eb38-4e06-9f3b-7648699bac28@github.com>

On Wed, 12 Apr 2023 03:20:47 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
> 
> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
> 
> (Sorry about the earlier RFR/Withdrawn noise.)

This looks okay but it makes me wonder about loadSocketExtensionFuncs. Maybe we should remove that from Sctp.h and change loadSocketExtensionFuncs in SctpNet.c to be static.

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1504733524

From michaelm at openjdk.org  Wed Apr 12 07:53:28 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 12 Apr 2023 07:53:28 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  update to remove dependency on AuthCacheImpl in j.n.Authenticator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/6636ac3f..a073c95f

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

  Stats: 390 lines in 8 files changed: 6 ins; 367 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13159/head:pull/13159

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

From djelinski at openjdk.org  Wed Apr 12 08:24:33 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Apr 2023 08:24:33 GMT
Subject: RFR: 8305529: DefaultProxySelector.select(URI) in certain cases
 returns a List with null element
In-Reply-To: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
References: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
Message-ID: <qzzOkYuIia7SPTYhGndLfpXDsMjpgogTTE5npFEFAvs=.edf6b0a1-f248-4cea-803d-1b1c596bc524@github.com>

On Tue, 11 Apr 2023 11:24:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305529?
> 
> There were a couple of places in the `DefaultProxySelector.c` (for unix variant) where we would end up returning an array with `null` element in it, when an error was detected by the underlying library that we invoke upon. The change here fixes those places to immediately return a `null` instance instead of an array, when iterating over the configured proxies. This matches with how we handle similar issues within the code (as well as on other OS, like windows and macos).
> 
> A jtreg test case has been added which reproduces on variant of the reported bug and verifies the fix. As noted in the JBS issue, the other variant of the bug (where environment variables have empty values) isn't reproducible and that appears to be because the underlying library that we use, now has a fix/change to ignore such proxy values.
> 
> One round of testing has completed without any issues. I have triggered a more extensive tier testing to make sure nothing regresses.

LGTM. Thanks!

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13424#pullrequestreview-1380787661

From jpai at openjdk.org  Wed Apr 12 09:47:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Apr 2023 09:47:37 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
Message-ID: <TB1oA2VUGvxKw9bAlU709RQrsyrh-05UBho_f01TxoQ=.16535f63-5f87-40b1-afa8-1e53dae15ad0@github.com>

On Wed, 12 Apr 2023 07:53:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to remove dependency on AuthCacheImpl in j.n.Authenticator

src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java line 115:

> 113:     }
> 114: 
> 115:     private static Map<Authenticator,AuthCacheImpl> caches =

Hello Michael, could this be `final`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163888845

From jpai at openjdk.org  Wed Apr 12 09:50:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Apr 2023 09:50:35 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
Message-ID: <0eH-ii2u-OKXpfGFtkJx5MVCepEhyIEIkU_yGgkNmbc=.5ba79f83-3abd-48ac-840e-698e63a6ff64@github.com>

On Wed, 12 Apr 2023 07:53:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to remove dependency on AuthCacheImpl in j.n.Authenticator

src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java line 122:

> 120:         if (c == null) {
> 121:             c = new AuthCacheImpl();
> 122:             caches.put(auth, c);

It appears that there's a potential for a race here, which could end up (creating and) returning a different `AuthCacheImpl` for the same `auth` instance.
Even though the `caches` is a `synchronizedMap`, we are using it here for two separate operations (`get()` followed by `put()`) which makes this non-atomic. Perhaps add a `synchronized` block `sychronized` on `caches`, if `c` is null?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163893587

From jpai at openjdk.org  Wed Apr 12 09:54:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Apr 2023 09:54:35 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
Message-ID: <ZmBkKem0TcHmX6C4t2Rskb5ZOy55rNXxzh9nfvu8LYw=.690b5a69-835c-494b-ba88-7e1624249e5b@github.com>

On Wed, 12 Apr 2023 07:53:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to remove dependency on AuthCacheImpl in j.n.Authenticator

src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheValue.java line 47:

> 45:      * The default authentication cache
> 46:      */
> 47:     protected static AuthCacheImpl defCache = new AuthCacheImpl();

Do instances of `AuthCacheValue` get used concurrently (by different threads)? If so, should this `defCache` value be a `volatile`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163899164

From jpai at openjdk.org  Wed Apr 12 09:59:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Apr 2023 09:59:35 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
Message-ID: <EtJTcq2aP5_tNCDZix57MouOtJohQPerPGzj0fRMRJs=.6d064ffe-a9fd-4be2-8a5e-04d12bd9abbd@github.com>

On Wed, 12 Apr 2023 07:53:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to remove dependency on AuthCacheImpl in j.n.Authenticator

src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 217:

> 215: 
> 216:     /** A cache to obtain credentials from if the default cache not to be used */
> 217:     transient AuthCacheImpl authcache; // may be null

Now that `AuthCacheValue` is no longer `Serializable` in this PR (and thus this `AuthenticationInfo` too isn't serializable), is the use of `transient` here and on some other fields in this class, needed anymore?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163904933

From jpai at openjdk.org  Wed Apr 12 10:07:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Apr 2023 10:07:37 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
Message-ID: <psn0RzotWq1_sB_uRNi0_LmfCt83uqftFiMnDLG2d6s=.86195c1d-8bab-4f7a-847f-23f8f06ec13d@github.com>

On Wed, 12 Apr 2023 07:53:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to remove dependency on AuthCacheImpl in j.n.Authenticator

src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 332:

> 330:     static AuthenticationInfo getAuth(String key, URL url, AuthCacheImpl authcache) {
> 331:         // use default cache if none supplied
> 332:         authcache = authcache == null ? defCache : authcache;

Was this supposed to be a declaration and assignment to a local variable here or are we intentionally overwrting the static `authcache` field here?

Same comment in a few other methods in this class.

src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 382:

> 380:         String key = cacheKey(true);
> 381:         if (useAuthCache()) {
> 382:             authcache.put(key, this);

Given that `authcache` can be null, do we need null checks in this and `removeFromCache()` method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163909705
PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163913890

From jpai at openjdk.org  Wed Apr 12 10:11:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Apr 2023 10:11:37 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
Message-ID: <NILKIB0xucguzCR004JmCmHpr75aMDubdDk7ISKlPtw=.e7079bed-8166-4011-bcae-45c4e0193aec@github.com>

On Wed, 12 Apr 2023 07:53:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to remove dependency on AuthCacheImpl in j.n.Authenticator

src/java.base/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java line 77:

> 75:                               AuthCacheImpl authcache) {
> 76:         try {
> 77:             return sixArgCtr.newInstance(isProxy, host, port, pw, authcache);

Not because of the changes in this PR, but this field is oddly named. It says six arg constructor but infact is a five arg constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163920645

From jpai at openjdk.org  Wed Apr 12 10:15:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Apr 2023 10:15:34 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
Message-ID: <Sis6aaQrUUWj49w8DSW-bWAgEeiCpyFtvZRhBR9BjCI=.76646a09-5c09-4cdb-a030-412545211a92@github.com>

On Wed, 12 Apr 2023 07:53:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to remove dependency on AuthCacheImpl in j.n.Authenticator

test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java line 75:

> 73:  * @run main/othervm HTTPSetAuthenticatorTest BASIC  SERVER307
> 74:  * @run main/othervm HTTPSetAuthenticatorTest BASICSERVER SERVER
> 75:  * @run main/othervm HTTPSetAuthenticatorTest BASICSERVER SERVER307

Is it intentional to remove many of these `@run` actions on this test?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163924648

From dfuchs at openjdk.org  Wed Apr 12 10:34:34 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Apr 2023 10:34:34 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance
In-Reply-To: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
Message-ID: <z7BTybOZSsBQQrFx_MgGnaWc1HTrC-sX9PHvnZGIfv8=.ae1b12c5-3432-4ebc-baa2-c6b688fdaa58@github.com>

On Tue, 11 Apr 2023 18:00:05 GMT, Dhamoder Nalla <duke at openjdk.org> wrote:

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

>From a quick look at the proposed change, I got the feeling that this change might not be appropriate: I suspect it will let `host` be assigned to the reg_name.
We want to preserve the long standing behavior that:

jshell> new URI("http://foo_bar:8080/").getHost()
$1 ==> null

Is this still the case after your proposed changes?

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

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

From michaelm at openjdk.org  Wed Apr 12 10:56:38 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 12 Apr 2023 10:56:38 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <ZmBkKem0TcHmX6C4t2Rskb5ZOy55rNXxzh9nfvu8LYw=.690b5a69-835c-494b-ba88-7e1624249e5b@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
 <ZmBkKem0TcHmX6C4t2Rskb5ZOy55rNXxzh9nfvu8LYw=.690b5a69-835c-494b-ba88-7e1624249e5b@github.com>
Message-ID: <DHtC8RRr7kE8g008Yq9hSE0Z9NVY6_84bad3EWx9SKo=.80def010-f724-4ddb-99ef-e45a71e99e5e@github.com>

On Wed, 12 Apr 2023 09:52:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to remove dependency on AuthCacheImpl in j.n.Authenticator
>
> src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheValue.java line 47:
> 
>> 45:      * The default authentication cache
>> 46:      */
>> 47:     protected static AuthCacheImpl defCache = new AuthCacheImpl();
> 
> Do instances of `AuthCacheValue` get used concurrently (by different threads)? If so, should this `defCache` value be a `volatile`?

I think it can be made `final`. The method that sets the field is redundant and no longer used afaik.

> src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 217:
> 
>> 215: 
>> 216:     /** A cache to obtain credentials from if the default cache not to be used */
>> 217:     transient AuthCacheImpl authcache; // may be null
> 
> Now that `AuthCacheValue` is no longer `Serializable` in this PR (and thus this `AuthenticationInfo` too isn't serializable), is the use of `transient` here and on some other fields in this class, needed anymore?

Good point.

> src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 332:
> 
>> 330:     static AuthenticationInfo getAuth(String key, URL url, AuthCacheImpl authcache) {
>> 331:         // use default cache if none supplied
>> 332:         authcache = authcache == null ? defCache : authcache;
> 
> Was this supposed to be a declaration and assignment to a local variable here or are we intentionally overwrting the static `authcache` field here?
> 
> Same comment in a few other methods in this class.

It sets the local variable (which is intended). It doesn't override the field. But, I agree it's confusing because of the name clash. I had changed a number of occurrences of this, but also missed a few. I will rename the local parameter variable.

> src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 382:
> 
>> 380:         String key = cacheKey(true);
>> 381:         if (useAuthCache()) {
>> 382:             authcache.put(key, this);
> 
> Given that `authcache` can be null, do we need null checks in this and `removeFromCache()` method?

Actually, the comment attached to the field is wrong. It really means the parameter to the constructor can be null, in which case we set the field to the default cache. So, the field can not be null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163956609
PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163957679
PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163960747
PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163965233

From michaelm at openjdk.org  Wed Apr 12 11:01:42 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 12 Apr 2023 11:01:42 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <NILKIB0xucguzCR004JmCmHpr75aMDubdDk7ISKlPtw=.e7079bed-8166-4011-bcae-45c4e0193aec@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
 <NILKIB0xucguzCR004JmCmHpr75aMDubdDk7ISKlPtw=.e7079bed-8166-4011-bcae-45c4e0193aec@github.com>
Message-ID: <jO8YVFe4p6tQdg6Ml-nZDfgKxyV_ekxvfK3pvpFTzLc=.d58199ec-3206-4986-aa13-6684bd25fd55@github.com>

On Wed, 12 Apr 2023 10:09:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to remove dependency on AuthCacheImpl in j.n.Authenticator
>
> src/java.base/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java line 77:
> 
>> 75:                               AuthCacheImpl authcache) {
>> 76:         try {
>> 77:             return sixArgCtr.newInstance(isProxy, host, port, pw, authcache);
> 
> Not because of the changes in this PR, but this field is oddly named. It says six arg constructor but infact is a five arg constructor.

Good catch!

> test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java line 75:
> 
>> 73:  * @run main/othervm HTTPSetAuthenticatorTest BASIC  SERVER307
>> 74:  * @run main/othervm HTTPSetAuthenticatorTest BASICSERVER SERVER
>> 75:  * @run main/othervm HTTPSetAuthenticatorTest BASICSERVER SERVER307
> 
> Is it intentional to remove many of these `@run` actions on this test?

No, I only just noticed that also ..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163968989
PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163969694

From michaelm at openjdk.org  Wed Apr 12 11:08:56 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 12 Apr 2023 11:08:56 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v9]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <il8wj_GCQWJE17M4-Smealjdy6wR2HrovE1MeSKyVkg=.39c0f7e3-2f05-492b-96b2-8f704273e5dc@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:

 - error in test
 - Jai's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/a073c95f..6618ffe7

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

  Stats: 45 lines in 5 files changed: 12 ins; 5 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/13159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13159/head:pull/13159

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

From dfuchs at openjdk.org  Wed Apr 12 11:09:00 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Apr 2023 11:09:00 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v8]
In-Reply-To: <0eH-ii2u-OKXpfGFtkJx5MVCepEhyIEIkU_yGgkNmbc=.5ba79f83-3abd-48ac-840e-698e63a6ff64@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <KlO1dtIzTaFHMs4OkrPi53uBltBnnPD_z9AAHMZY3q0=.c6a0930a-db05-41c1-9506-a22feb4d03ad@github.com>
 <0eH-ii2u-OKXpfGFtkJx5MVCepEhyIEIkU_yGgkNmbc=.5ba79f83-3abd-48ac-840e-698e63a6ff64@github.com>
Message-ID: <ZeYnzrgxqYlYyiPCp_tqZjbBU-qEbU1Nz1fsbP72kMo=.89c0d193-f7a0-4afe-90c7-1a6e71d2b420@github.com>

On Wed, 12 Apr 2023 09:48:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to remove dependency on AuthCacheImpl in j.n.Authenticator
>
> src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java line 122:
> 
>> 120:         if (c == null) {
>> 121:             c = new AuthCacheImpl();
>> 122:             caches.put(auth, c);
> 
> It appears that there's a potential for a race here, which could end up (creating and) returning a different `AuthCacheImpl` for the same `auth` instance.
> Even though the `caches` is a `synchronizedMap`, we are using it here for two separate operations (`get()` followed by `put()`) which makes this non-atomic. Perhaps add a `synchronized` block `sychronized` on `caches`, if `c` is null?

Or maybe use computeIfAbsent ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1163974073

From dfuchs at openjdk.org  Wed Apr 12 11:53:37 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Apr 2023 11:53:37 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v9]
In-Reply-To: <il8wj_GCQWJE17M4-Smealjdy6wR2HrovE1MeSKyVkg=.39c0f7e3-2f05-492b-96b2-8f704273e5dc@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <il8wj_GCQWJE17M4-Smealjdy6wR2HrovE1MeSKyVkg=.39c0f7e3-2f05-492b-96b2-8f704273e5dc@github.com>
Message-ID: <EqEpBev3oaJ4ujLoaPy8moGwhjUk4No-cCuTWsQY4-I=.e415c146-f648-4db2-aa23-b4677ef6953f@github.com>

On Wed, 12 Apr 2023 11:08:56 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - error in test
>  - Jai's review

src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java line 126:

> 124:             }
> 125:             return c;
> 126:         }

Suggestion:

        return caches.computeIfAbsent(auth, (k) -> new AuthCacheImpl());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1164019776

From michaelm at openjdk.org  Wed Apr 12 12:00:41 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 12 Apr 2023 12:00:41 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v10]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <8gAo-pKgHVJahrbElQutsDIDtEvVeiHzFg-DBjJBB1E=.fe1d2e53-a92e-42a1-aeb1-6209af2b09eb@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/6618ffe7..03d9b9ac

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

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

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

From michaelm at openjdk.org  Wed Apr 12 12:00:45 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 12 Apr 2023 12:00:45 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v9]
In-Reply-To: <EqEpBev3oaJ4ujLoaPy8moGwhjUk4No-cCuTWsQY4-I=.e415c146-f648-4db2-aa23-b4677ef6953f@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <il8wj_GCQWJE17M4-Smealjdy6wR2HrovE1MeSKyVkg=.39c0f7e3-2f05-492b-96b2-8f704273e5dc@github.com>
 <EqEpBev3oaJ4ujLoaPy8moGwhjUk4No-cCuTWsQY4-I=.e415c146-f648-4db2-aa23-b4677ef6953f@github.com>
Message-ID: <lHFmHvzWNflFb0s8wBGGkLcsLDnQML3SBFIp7Uy5lFs=.81783002-bd29-4840-9f60-f08171326dd5@github.com>

On Wed, 12 Apr 2023 11:50:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - error in test
>>  - Jai's review
>
> src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java line 126:
> 
>> 124:             }
>> 125:             return c;
>> 126:         }
> 
> Suggestion:
> 
>         return caches.computeIfAbsent(auth, (k) -> new AuthCacheImpl());

Suggestion committed. Thanks for the reviews!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1164024474

From djelinski at openjdk.org  Wed Apr 12 12:02:41 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Apr 2023 12:02:41 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v4]
In-Reply-To: <p6d4MbKArIpG0X4_gMpsLMA7nr4A6C_L6kzjAV93zKU=.3433ab41-6c54-49a3-a1b0-3e59e77c31a7@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <p6d4MbKArIpG0X4_gMpsLMA7nr4A6C_L6kzjAV93zKU=.3433ab41-6c54-49a3-a1b0-3e59e77c31a7@github.com>
Message-ID: <zAofQ8qApMMewmENbyRJFuxvfPxhqovTGJuMPuPgNgM=.63c33609-8e03-4b58-8e72-4aa7ea1fbca8@github.com>

On Tue, 11 Apr 2023 13:50:31 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

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

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestServerConnection.java line 737:

> 735:                 // the error code NO_ERROR will be sent to the client before closing.
> 736:                 if (bis instanceof BodyInputStream inputStream && (!inputStream.isEof() || inputStream.q.size() > 0)) {
> 737:                     bos.sendResetOnClose(ResetFrame.NO_ERROR);

I share @dfuch concern. This line will have no effect if `bos` is already closed at this point. We still need to reset the stream to let the peer know that we won't consume `bis`.

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

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

From dfuchs at openjdk.org  Wed Apr 12 12:02:42 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Apr 2023 12:02:42 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v9]
In-Reply-To: <il8wj_GCQWJE17M4-Smealjdy6wR2HrovE1MeSKyVkg=.39c0f7e3-2f05-492b-96b2-8f704273e5dc@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <il8wj_GCQWJE17M4-Smealjdy6wR2HrovE1MeSKyVkg=.39c0f7e3-2f05-492b-96b2-8f704273e5dc@github.com>
Message-ID: <VfR_-6lMm_XRslOY970YspXh1fcMLhWWF4KpRLSOTbw=.6e3360b3-c568-48fa-ab7c-64b6bcc6b8bb@github.com>

On Wed, 12 Apr 2023 11:08:56 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - error in test
>  - Jai's review

src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 229:

> 227:         this.realm = realm;
> 228:         this.path = null;
> 229:         this.authcache = acache == null ? defCache : acache;

Do we really need that field? Now that AuthCacheValue instances are held in separate caches, there should be no need to have a field referring to the authenticator/cache in the auth value.
This let me thinks that some more refactoring could further simplify everything.
Having the value point to the cache in which it's been added seems wrong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1164028256

From jpai at openjdk.org  Wed Apr 12 12:43:29 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Apr 2023 12:43:29 GMT
Subject: RFR: 8305900: Use loopback IP addresses in security policy files of
 httpclient tests
Message-ID: <hMShODUoal3gtUQTPQrLeUlAtiRqtn95ojR6qE6GPOc=.8165e738-b1d9-4585-b769-dd8764dc1dfd@github.com>

Can I please get a review of this test-only changes to the `java/net/httpclient/` tests? This addresses https://bugs.openjdk.org/browse/JDK-8305900.

As noted in the JBS issue, the changes here update the security policy files and the test library to use IP address of the loopback address instead of using "localhost".

Multiple runs of tests have been run with this change both with IPv4 and IPv6 and I haven't observed any failures or regressions with these changes.

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

Commit messages:
 - 8305900: Use loopback IP addresses in security policy files of httpclient tests

Changes: https://git.openjdk.org/jdk/pull/13444/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305900
  Stats: 421 lines in 33 files changed: 187 ins; 30 del; 204 mod
  Patch: https://git.openjdk.org/jdk/pull/13444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13444/head:pull/13444

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

From dfuchs at openjdk.org  Wed Apr 12 13:11:33 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Apr 2023 13:11:33 GMT
Subject: RFR: 8305900: Use loopback IP addresses in security policy files
 of httpclient tests
In-Reply-To: <hMShODUoal3gtUQTPQrLeUlAtiRqtn95ojR6qE6GPOc=.8165e738-b1d9-4585-b769-dd8764dc1dfd@github.com>
References: <hMShODUoal3gtUQTPQrLeUlAtiRqtn95ojR6qE6GPOc=.8165e738-b1d9-4585-b769-dd8764dc1dfd@github.com>
Message-ID: <6MjecY380mtpm30J8E517uRwSQzhmtxLF9vG-he2DmI=.22d59cdb-7522-4f93-b9e4-636718e4eb7e@github.com>

On Wed, 12 Apr 2023 12:36:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only changes to the `java/net/httpclient/` tests? This addresses https://bugs.openjdk.org/browse/JDK-8305900.
> 
> As noted in the JBS issue, the changes here update the security policy files and the test library to use IP address of the loopback address instead of using "localhost".
> 
> Multiple runs of tests have been run with this change both with IPv4 and IPv6 and I haven't observed any failures or regressions with these changes.

Thabks for taking care of this Jaikiran. This looks good to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13444#pullrequestreview-1381284520

From michaelm at openjdk.org  Wed Apr 12 15:48:34 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 12 Apr 2023 15:48:34 GMT
Subject: RFR: 8305529: DefaultProxySelector.select(URI) in certain cases
 returns a List with null element
In-Reply-To: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
References: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
Message-ID: <QQG8-gF24tej-hssDIMbZHuPSGnB6eH_rCTe8iPvbfg=.ce919b9e-879a-4a7d-8153-3c9302c05302@github.com>

On Tue, 11 Apr 2023 11:24:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305529?
> 
> There were a couple of places in the `DefaultProxySelector.c` (for unix variant) where we would end up returning an array with `null` element in it, when an error was detected by the underlying library that we invoke upon. The change here fixes those places to immediately return a `null` instance instead of an array, when iterating over the configured proxies. This matches with how we handle similar issues within the code (as well as on other OS, like windows and macos).
> 
> A jtreg test case has been added which reproduces on variant of the reported bug and verifies the fix. As noted in the JBS issue, the other variant of the bug (where environment variables have empty values) isn't reproducible and that appears to be because the underlying library that we use, now has a fix/change to ignore such proxy values.
> 
> One round of testing has completed without any issues. I have triggered a more extensive tier testing to make sure nothing regresses.

Looks fine.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13424#pullrequestreview-1381611173

From jiangli at openjdk.org  Wed Apr 12 17:18:25 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 17:18:25 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries [v2]
In-Reply-To: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
Message-ID: <ottq6FwpL2F8ZMEPCndVczNF1yc3lPAuL6cb5Pl0tG4=.286c3f4a-b46d-44f5-ae26-0aab2c1bf26d@github.com>

> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
> 
> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
> 
> (Sorry about the earlier RFR/Withdrawn noise.)

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Make loadSocketExtensionFuncs as a static function.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13438/files
  - new: https://git.openjdk.org/jdk/pull/13438/files/ea9627a4..321fa6d5

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

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

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

From alanb at openjdk.org  Wed Apr 12 17:18:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 17:18:25 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries [v2]
In-Reply-To: <ottq6FwpL2F8ZMEPCndVczNF1yc3lPAuL6cb5Pl0tG4=.286c3f4a-b46d-44f5-ae26-0aab2c1bf26d@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
 <ottq6FwpL2F8ZMEPCndVczNF1yc3lPAuL6cb5Pl0tG4=.286c3f4a-b46d-44f5-ae26-0aab2c1bf26d@github.com>
Message-ID: <1Pt6vqYxxVPJktghuO6F0zs3GkvouCGooJI01F646ns=.607cfddb-bc96-4a45-b1de-8784fcbe33b4@github.com>

On Wed, 12 Apr 2023 17:13:56 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
>> 
>> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
>> 
>> (Sorry about the earlier RFR/Withdrawn noise.)
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make loadSocketExtensionFuncs as a static function.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13438#pullrequestreview-1381756250

From jiangli at openjdk.org  Wed Apr 12 17:18:28 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 17:18:28 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <NnM-UCb2Uxd8ncH6BEqgDu0YTjhZE2UmmwdNB4Mh_f4=.376a705e-eb38-4e06-9f3b-7648699bac28@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
 <NnM-UCb2Uxd8ncH6BEqgDu0YTjhZE2UmmwdNB4Mh_f4=.376a705e-eb38-4e06-9f3b-7648699bac28@github.com>
Message-ID: <om75cQes6jNcUdA-2halAkughrsM66mAvHRObbglBXg=.f0cfa614-7f19-442a-9014-d8baad899677@github.com>

On Wed, 12 Apr 2023 06:29:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks okay but it makes me wonder about loadSocketExtensionFuncs. Maybe we should remove that from Sctp.h and change loadSocketExtensionFuncs in SctpNet.c to be static.

Changed loadSocketExtensionFuncs to be static as suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1505628839

From alanb at openjdk.org  Wed Apr 12 17:18:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Apr 2023 17:18:28 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <om75cQes6jNcUdA-2halAkughrsM66mAvHRObbglBXg=.f0cfa614-7f19-442a-9014-d8baad899677@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
 <NnM-UCb2Uxd8ncH6BEqgDu0YTjhZE2UmmwdNB4Mh_f4=.376a705e-eb38-4e06-9f3b-7648699bac28@github.com>
 <om75cQes6jNcUdA-2halAkughrsM66mAvHRObbglBXg=.f0cfa614-7f19-442a-9014-d8baad899677@github.com>
Message-ID: <AYOdVScRdiBxHxQPQS6XaLkwx5cnRnvlsDFxZKiWAW8=.9d9beb7d-f868-46d6-aefd-368ed0eb2c40@github.com>

On Wed, 12 Apr 2023 17:09:26 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Changed loadSocketExtensionFuncs to be static as suggested.

Thanks, that avoids having inconsistent naming in the header file.

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1505632040

From jiangli at openjdk.org  Wed Apr 12 17:32:35 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 17:32:35 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries [v2]
In-Reply-To: <ottq6FwpL2F8ZMEPCndVczNF1yc3lPAuL6cb5Pl0tG4=.286c3f4a-b46d-44f5-ae26-0aab2c1bf26d@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
 <ottq6FwpL2F8ZMEPCndVczNF1yc3lPAuL6cb5Pl0tG4=.286c3f4a-b46d-44f5-ae26-0aab2c1bf26d@github.com>
Message-ID: <x6ofs6Je8NeHpr37CUme8lTs8oCLRdd0PzbPISga7sQ=.fe4b3643-8572-48ae-8e75-f74ea9d2a797@github.com>

On Wed, 12 Apr 2023 17:18:25 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
>> 
>> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
>> 
>> (Sorry about the earlier RFR/Withdrawn noise.)
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make loadSocketExtensionFuncs as a static function.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1505662956

From jiangli at openjdk.org  Wed Apr 12 17:38:34 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 17:38:34 GMT
Subject: RFR: 8305858: Resolve multiple definition of 'handleSocketError'
 when statically linking with JDK native libraries
In-Reply-To: <kLWWNdDkdoeUNGpyPd-cGDVwEw7oYKMT5Jtc8YyZGPw=.56098905-b018-4455-b803-dc4d44c82cce@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
 <kLWWNdDkdoeUNGpyPd-cGDVwEw7oYKMT5Jtc8YyZGPw=.56098905-b018-4455-b803-dc4d44c82cce@github.com>
Message-ID: <BwomHkm6FvtLdnjwuxGvHF2frvkEO5EZA1OmjRcgesA=.fd78e15e-820d-4cd9-9576-f957be1fd648@github.com>

On Wed, 12 Apr 2023 03:26:10 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> I noticed there is a presubmit test failure: https://github.com/jianglizhou/jdk/actions/runs/4672962155#user-content-java_lang_thread_virtual_tracevirtualthreadlocals for linux-x86. It appears to be unrelated. Will file a bug tomorrow if there is not existing bug (will check before filing).

I found there is the existing https://bugs.openjdk.org/browse/JDK-8305875.

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

PR Comment: https://git.openjdk.org/jdk/pull/13438#issuecomment-1505670999

From jiangli at openjdk.org  Wed Apr 12 20:45:42 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Apr 2023 20:45:42 GMT
Subject: Integrated: 8305858: Resolve multiple definition of
 'handleSocketError' when statically linking with JDK native libraries
In-Reply-To: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
References: <3tSFAJf4ihFEz3_AQ2JiowVTckhLlaVxNcIDSFO4CCA=.14e712de-c6ef-4d66-adb7-4a243d34f5c1@github.com>
Message-ID: <asZX78C5grsqQ68TEBBPkiR32FmTtkNu_vnC21j2jGw=.56bf211b-84ee-4249-9368-fc3dd0cd620e@github.com>

On Wed, 12 Apr 2023 03:20:47 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Rename 'handleSocketError' to 'sctpHandleSocketError' in libsctp. This resolves the related duplicate symbol failures when both libnio and libsctp are statically linked with the launcher.
> 
> Remove #include "nio_util.h" from SctpChannelImpl.c and SctpNet.c. Looks like that's only needed for handleSocketError() declaration. Declare sctpHandleSocketError() in Sctp.h.
> 
> (Sorry about the earlier RFR/Withdrawn noise.)

This pull request has now been integrated.

Changeset: 2bbbff20
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bbbff209dc21633e08fe4d565dfc649eea2c883
Stats:     20 lines in 3 files changed: 0 ins; 4 del; 16 mod

8305858: Resolve multiple definition of 'handleSocketError' when statically linking with JDK native libraries

Reviewed-by: alanb

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

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

From jpai at openjdk.org  Thu Apr 13 01:33:06 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Apr 2023 01:33:06 GMT
Subject: RFR: 8305529: DefaultProxySelector.select(URI) in certain cases
 returns a List with null element
In-Reply-To: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
References: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
Message-ID: <FI_JbJdXjmY__MMhjaXAokHD2Mg_TayHsjvt5aEc-ho=.3fc189aa-0a2e-4fa2-9c34-1eb9baa761d8@github.com>

On Tue, 11 Apr 2023 11:24:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305529?
> 
> There were a couple of places in the `DefaultProxySelector.c` (for unix variant) where we would end up returning an array with `null` element in it, when an error was detected by the underlying library that we invoke upon. The change here fixes those places to immediately return a `null` instance instead of an array, when iterating over the configured proxies. This matches with how we handle similar issues within the code (as well as on other OS, like windows and macos).
> 
> A jtreg test case has been added which reproduces on variant of the reported bug and verifies the fix. As noted in the JBS issue, the other variant of the bug (where environment variables have empty values) isn't reproducible and that appears to be because the underlying library that we use, now has a fix/change to ignore such proxy values.
> 
> One round of testing has completed without any issues. I have triggered a more extensive tier testing to make sure nothing regresses.

Thank you everyone for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/13424#issuecomment-1506184947

From jpai at openjdk.org  Thu Apr 13 01:33:07 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Apr 2023 01:33:07 GMT
Subject: Integrated: 8305529: DefaultProxySelector.select(URI) in certain cases
 returns a List with null element
In-Reply-To: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
References: <aCYpBbxZGIP2sHGEkpQWvJxGcJ_IKlMsbVwH-oq4DR0=.6397a6e6-c091-497b-a6b9-28a5b4b3eec4@github.com>
Message-ID: <I8hEBkIhzPJAz7fdIUREaUCSdx96oioc3Gkwtna2Hhs=.bc63b71a-2ac9-42f7-8206-0a64bc2bba09@github.com>

On Tue, 11 Apr 2023 11:24:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305529?
> 
> There were a couple of places in the `DefaultProxySelector.c` (for unix variant) where we would end up returning an array with `null` element in it, when an error was detected by the underlying library that we invoke upon. The change here fixes those places to immediately return a `null` instance instead of an array, when iterating over the configured proxies. This matches with how we handle similar issues within the code (as well as on other OS, like windows and macos).
> 
> A jtreg test case has been added which reproduces on variant of the reported bug and verifies the fix. As noted in the JBS issue, the other variant of the bug (where environment variables have empty values) isn't reproducible and that appears to be because the underlying library that we use, now has a fix/change to ignore such proxy values.
> 
> One round of testing has completed without any issues. I have triggered a more extensive tier testing to make sure nothing regresses.

This pull request has now been integrated.

Changeset: 3f36dd81
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f36dd811e56ecb4b7c6bf1bf8be8a8de9481ed0
Stats:     131 lines in 3 files changed: 129 ins; 0 del; 2 mod

8305529: DefaultProxySelector.select(URI) in certain cases returns a List with null element

Reviewed-by: dfuchs, djelinski, michaelm

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

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

From michaelm at openjdk.org  Thu Apr 13 07:44:57 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 13 Apr 2023 07:44:57 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v9]
In-Reply-To: <VfR_-6lMm_XRslOY970YspXh1fcMLhWWF4KpRLSOTbw=.6e3360b3-c568-48fa-ab7c-64b6bcc6b8bb@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <il8wj_GCQWJE17M4-Smealjdy6wR2HrovE1MeSKyVkg=.39c0f7e3-2f05-492b-96b2-8f704273e5dc@github.com>
 <VfR_-6lMm_XRslOY970YspXh1fcMLhWWF4KpRLSOTbw=.6e3360b3-c568-48fa-ab7c-64b6bcc6b8bb@github.com>
Message-ID: <CPqprexw0CuTlgGSpDE1vLYZrs1PJ5A7c5orBeeWthc=.47a43c51-18e1-41e0-812d-c978f2838177@github.com>

On Wed, 12 Apr 2023 11:58:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - error in test
>>  - Jai's review
>
> src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 229:
> 
>> 227:         this.realm = realm;
>> 228:         this.path = null;
>> 229:         this.authcache = acache == null ? defCache : acache;
> 
> Do we really need that field? Now that AuthCacheValue instances are held in separate caches, there should be no need to have a field referring to the authenticator/cache in the auth value.
> This let me thinks that some more refactoring could further simplify everything.
> Having the value point to the cache in which it's been added seems wrong.

That structure is not related to this change though. Previously, the value added itself to the single static cache, but now to add itself, it needs a reference to the cache instance. We could certainly reorganise this code, but I'm not sure that work belongs in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1165130860

From jpai at openjdk.org  Thu Apr 13 09:44:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Apr 2023 09:44:10 GMT
Subject: RFR: 8305900: Use loopback IP addresses in security policy files
 of httpclient tests
In-Reply-To: <hMShODUoal3gtUQTPQrLeUlAtiRqtn95ojR6qE6GPOc=.8165e738-b1d9-4585-b769-dd8764dc1dfd@github.com>
References: <hMShODUoal3gtUQTPQrLeUlAtiRqtn95ojR6qE6GPOc=.8165e738-b1d9-4585-b769-dd8764dc1dfd@github.com>
Message-ID: <oeQQCoJ8P1mflCc275wY7EjS9uvgJtC91x1xwbUXpHo=.8610938c-a40f-4eb4-b2a4-53d3fe5a1e18@github.com>

On Wed, 12 Apr 2023 12:36:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only changes to the `java/net/httpclient/` tests? This addresses https://bugs.openjdk.org/browse/JDK-8305900.
> 
> As noted in the JBS issue, the changes here update the security policy files and the test library to use IP address of the loopback address instead of using "localhost".
> 
> Multiple runs of tests have been run with this change both with IPv4 and IPv6 and I haven't observed any failures or regressions with these changes.

Thank you Daniel for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13444#issuecomment-1506662341

From jpai at openjdk.org  Thu Apr 13 09:44:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Apr 2023 09:44:11 GMT
Subject: Integrated: 8305900: Use loopback IP addresses in security policy
 files of httpclient tests
In-Reply-To: <hMShODUoal3gtUQTPQrLeUlAtiRqtn95ojR6qE6GPOc=.8165e738-b1d9-4585-b769-dd8764dc1dfd@github.com>
References: <hMShODUoal3gtUQTPQrLeUlAtiRqtn95ojR6qE6GPOc=.8165e738-b1d9-4585-b769-dd8764dc1dfd@github.com>
Message-ID: <1Ckz1k9LnQovNK6hTn-Yh_hkgZ5WfKtavgGah70joMk=.0bee97f2-07cf-42da-b203-6a6edff9ba1b@github.com>

On Wed, 12 Apr 2023 12:36:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only changes to the `java/net/httpclient/` tests? This addresses https://bugs.openjdk.org/browse/JDK-8305900.
> 
> As noted in the JBS issue, the changes here update the security policy files and the test library to use IP address of the loopback address instead of using "localhost".
> 
> Multiple runs of tests have been run with this change both with IPv4 and IPv6 and I haven't observed any failures or regressions with these changes.

This pull request has now been integrated.

Changeset: 646b666a
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/646b666a265c4de961b8ba3f9e4e8c9231be8a6f
Stats:     421 lines in 33 files changed: 187 ins; 30 del; 204 mod

8305900: Use loopback IP addresses in security policy files of httpclient tests

Reviewed-by: dfuchs

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

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

From michaelm at openjdk.org  Thu Apr 13 10:08:58 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 13 Apr 2023 10:08:58 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v11]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <oMU5YnxcH4Ciolv8xdqvc-DsXm6FAD4jdo7jpSLfQEs=.2b8eb57c-a70d-4654-ba68-19ed5eb96db6@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

Michael McMahon 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 14 additional commits since the last revision:

 - Merge branch 'master' into auth
 - Update src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - error in test
 - Jai's review
 - update to remove dependency on AuthCacheImpl in j.n.Authenticator
 - Merge branch 'master' into auth
 - removed AuthenticationInfo serialization code plus other updates
 - update
 - Merge branch 'master' into auth
 - updated implementation and reimpl of AuthenticatoKeys
 - ... and 4 more: https://git.openjdk.org/jdk/compare/88b42e2a...d2d27f8c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/03d9b9ac..d2d27f8c

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

  Stats: 5049 lines in 173 files changed: 2316 ins; 1326 del; 1407 mod
  Patch: https://git.openjdk.org/jdk/pull/13159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13159/head:pull/13159

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

From jpai at openjdk.org  Thu Apr 13 11:19:38 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Apr 2023 11:19:38 GMT
Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled
 HTTP/2 connection for IPv6 address
Message-ID: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>

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

As noted in that issue, when IPv6 hosts are involved, the HttpClient on certain occasions can end up caching the connection with a key which doesn't match with the key which is then used in a subsequent request against the same target host. 

The commit in this PR now wraps the IPv6 address in a square bracket consistently so that the correct key is used both during storing the connection in the pool and when looking up.

A new jtreg test has been added which reproduces this issue without the fix and verifies the fix.

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

Commit messages:
 - 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address

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

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

From dfuchs at openjdk.org  Thu Apr 13 11:36:37 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Apr 2023 11:36:37 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v9]
In-Reply-To: <CPqprexw0CuTlgGSpDE1vLYZrs1PJ5A7c5orBeeWthc=.47a43c51-18e1-41e0-812d-c978f2838177@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <il8wj_GCQWJE17M4-Smealjdy6wR2HrovE1MeSKyVkg=.39c0f7e3-2f05-492b-96b2-8f704273e5dc@github.com>
 <VfR_-6lMm_XRslOY970YspXh1fcMLhWWF4KpRLSOTbw=.6e3360b3-c568-48fa-ab7c-64b6bcc6b8bb@github.com>
 <CPqprexw0CuTlgGSpDE1vLYZrs1PJ5A7c5orBeeWthc=.47a43c51-18e1-41e0-812d-c978f2838177@github.com>
Message-ID: <3yAjvdIW9qvahZOWb9c6IRqnIHg8XDDwpEbunXCN4ag=.4c747e6c-f6bf-4583-ab16-4e7873b88d47@github.com>

On Thu, 13 Apr 2023 07:42:31 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 229:
>> 
>>> 227:         this.realm = realm;
>>> 228:         this.path = null;
>>> 229:         this.authcache = acache == null ? defCache : acache;
>> 
>> Do we really need that field? Now that AuthCacheValue instances are held in separate caches, there should be no need to have a field referring to the authenticator/cache in the auth value.
>> This let me thinks that some more refactoring could further simplify everything.
>> Having the value point to the cache in which it's been added seems wrong.
>
> That structure is not related to this change though. Previously, the value added itself to the single static cache, but now to add itself, it needs a reference to the cache instance. We could certainly reorganise this code, but I'm not sure that work belongs in this PR.

Possibly - but there seems to be a lot of churn caused by having to pass an AuthCacheImpl instance to the AuthCacheValue now. It makes it a bit difficult to reason about. I just wonder if *not* passing that value would not simplify the fix considerably. I'll try to import your changes and see what I can find.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1165391501

From michaelm at openjdk.org  Thu Apr 13 11:36:38 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 13 Apr 2023 11:36:38 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v9]
In-Reply-To: <3yAjvdIW9qvahZOWb9c6IRqnIHg8XDDwpEbunXCN4ag=.4c747e6c-f6bf-4583-ab16-4e7873b88d47@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <il8wj_GCQWJE17M4-Smealjdy6wR2HrovE1MeSKyVkg=.39c0f7e3-2f05-492b-96b2-8f704273e5dc@github.com>
 <VfR_-6lMm_XRslOY970YspXh1fcMLhWWF4KpRLSOTbw=.6e3360b3-c568-48fa-ab7c-64b6bcc6b8bb@github.com>
 <CPqprexw0CuTlgGSpDE1vLYZrs1PJ5A7c5orBeeWthc=.47a43c51-18e1-41e0-812d-c978f2838177@github.com>
 <3yAjvdIW9qvahZOWb9c6IRqnIHg8XDDwpEbunXCN4ag=.4c747e6c-f6bf-4583-ab16-4e7873b88d47@github.com>
Message-ID: <P16m39k5_jEIkK93rYgOtlm5HfFOcBG6I5Sxiuscyn0=.b905f0f1-dab1-4e35-9fde-850810caca59@github.com>

On Thu, 13 Apr 2023 11:30:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> That structure is not related to this change though. Previously, the value added itself to the single static cache, but now to add itself, it needs a reference to the cache instance. We could certainly reorganise this code, but I'm not sure that work belongs in this PR.
>
> Possibly - but there seems to be a lot of churn caused by having to pass an AuthCacheImpl instance to the AuthCacheValue now. It makes it a bit difficult to reason about. I just wonder if *not* passing that value would not simplify the fix considerably. I'll try to import your changes and see what I can find.

Okay, I'll take a look and see if it can be simplified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1165394619

From jpai at openjdk.org  Thu Apr 13 11:58:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Apr 2023 11:58:34 GMT
Subject: RFR: 8305847: Improve diagnosability and resilience of
 HttpClient::close tests
In-Reply-To: <Dwv_Z5AGTOduVyE57m-Frv58JEBr9Nk9d6t5GLK2fpo=.f3e60bed-37d7-4db8-9776-84e910273c15@github.com>
References: <Dwv_Z5AGTOduVyE57m-Frv58JEBr9Nk9d6t5GLK2fpo=.f3e60bed-37d7-4db8-9776-84e910273c15@github.com>
Message-ID: <KFv1nvjquSgARF5lmLagtUxO0aRF1JZh5EP7muarFVM=.7f0e8408-aa35-4435-8abf-4670e7677ca8@github.com>

On Tue, 11 Apr 2023 13:46:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The HttpClient close tests could be improved to provide better diagnosis. 
> 
> The tests make some requests and register some dependent actions to check the response state, followed by some dependent action that will read the request body (from an input stream). But if the first dependent action asserts, the second will not be executed, and the body will neither be read or closed.
> This will later prevent HttpClient::close method, or the HttpClient::awaitTermination method, to terminate as expected, and the test will then later fail in timeout (either from jtreg or awaitTermination). This behaviour can be confusing for failure analysis. 
> 
> The tests could also be further simplified by creating the executor in which the responses bodies will eventually be read (called `readerService`) in the `setup()` method and later close it in `teardown()`. This will simplify the cleanup phase, and ensure the service does not get closed until all dependent actions have been scheduled.

Hello Daniel, the changes look fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13426#pullrequestreview-1383248127

From djelinski at openjdk.org  Thu Apr 13 12:32:24 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Apr 2023 12:32:24 GMT
Subject: RFR: 8305847: Improve diagnosability and resilience of
 HttpClient::close tests
In-Reply-To: <Dwv_Z5AGTOduVyE57m-Frv58JEBr9Nk9d6t5GLK2fpo=.f3e60bed-37d7-4db8-9776-84e910273c15@github.com>
References: <Dwv_Z5AGTOduVyE57m-Frv58JEBr9Nk9d6t5GLK2fpo=.f3e60bed-37d7-4db8-9776-84e910273c15@github.com>
Message-ID: <vHeQaDiogOpyXgAlGqK6Gx10GNQ4EI-OvuIe3hGPFYY=.7212ec89-5f71-4902-958f-a50367b16da3@github.com>

On Tue, 11 Apr 2023 13:46:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The HttpClient close tests could be improved to provide better diagnosis. 
> 
> The tests make some requests and register some dependent actions to check the response state, followed by some dependent action that will read the request body (from an input stream). But if the first dependent action asserts, the second will not be executed, and the body will neither be read or closed.
> This will later prevent HttpClient::close method, or the HttpClient::awaitTermination method, to terminate as expected, and the test will then later fail in timeout (either from jtreg or awaitTermination). This behaviour can be confusing for failure analysis. 
> 
> The tests could also be further simplified by creating the executor in which the responses bodies will eventually be read (called `readerService`) in the `setup()` method and later close it in `teardown()`. This will simplify the cleanup phase, and ensure the service does not get closed until all dependent actions have been scheduled.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13426#pullrequestreview-1383303807

From dfuchs at openjdk.org  Thu Apr 13 15:32:14 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Apr 2023 15:32:14 GMT
Subject: Integrated: 8305847: Improve diagnosability and resilience of
 HttpClient::close tests
In-Reply-To: <Dwv_Z5AGTOduVyE57m-Frv58JEBr9Nk9d6t5GLK2fpo=.f3e60bed-37d7-4db8-9776-84e910273c15@github.com>
References: <Dwv_Z5AGTOduVyE57m-Frv58JEBr9Nk9d6t5GLK2fpo=.f3e60bed-37d7-4db8-9776-84e910273c15@github.com>
Message-ID: <I1QHuk9HJQ2sjymSxybm-unlv5SLc96IMFeuCdD_60Y=.e864ff54-2fde-4c30-b203-fd7332f4ce40@github.com>

On Tue, 11 Apr 2023 13:46:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The HttpClient close tests could be improved to provide better diagnosis. 
> 
> The tests make some requests and register some dependent actions to check the response state, followed by some dependent action that will read the request body (from an input stream). But if the first dependent action asserts, the second will not be executed, and the body will neither be read or closed.
> This will later prevent HttpClient::close method, or the HttpClient::awaitTermination method, to terminate as expected, and the test will then later fail in timeout (either from jtreg or awaitTermination). This behaviour can be confusing for failure analysis. 
> 
> The tests could also be further simplified by creating the executor in which the responses bodies will eventually be read (called `readerService`) in the `setup()` method and later close it in `teardown()`. This will simplify the cleanup phase, and ensure the service does not get closed until all dependent actions have been scheduled.

This pull request has now been integrated.

Changeset: 90b4006b
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90b4006bce6a4c28f93297da06be3b30d02fa89f
Stats:     278 lines in 4 files changed: 168 ins; 54 del; 56 mod

8305847: Improve diagnosability and resilience of HttpClient::close tests

Reviewed-by: jpai, djelinski

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

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

From jjg at openjdk.org  Thu Apr 13 20:30:03 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 13 Apr 2023 20:30:03 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <m4udm5H1KKWOFrFHbNbbof-gqipEvFbflX-l7-GTImE=.bf857f4e-b987-4eac-a675-aa5b23878cfb@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
 <m4udm5H1KKWOFrFHbNbbof-gqipEvFbflX-l7-GTImE=.bf857f4e-b987-4eac-a675-aa5b23878cfb@github.com>
Message-ID: <UGiiVD_nZK18Cul3Ww_GwNji8G26KplBEMoJV3EgAuw=.23e0116e-6701-4040-90b6-37bda7333df4@github.com>

On Thu, 6 Apr 2023 19:31:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> There are references to other specifications missing, like NIST Special Publication 800-90A Revision 1, referenced in `java.security.DrbgParameters`. I think there are others, I haven't done a thorough review yet. Will there be subsequent reviews for these, or should I point them out and have them resolved as part of this PR?

This should contain all the specs on spec sites that I know about, so if there are other specs that I missed, please indicate that, and we can either handle them here or in follow-up reviews. Your choice.

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

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

From wetmore at openjdk.org  Fri Apr 14 05:10:34 2023
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 14 Apr 2023 05:10:34 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
Message-ID: <pIAgd90HZULenLPxOFuq6VZdWfWZs0l4oKgUIHfOMTQ=.84f00548-51f8-4982-984e-ae8785f26c54@github.com>

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

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

I'm coming to this late, but what is the breadth of the specs you're trying to call out?  Where did you obtain this list?  Are all of these changes coming from existing mentions in the current APIs, and you're just adding a `@spec` in various places?   Or are you trying to be complete, or just list a representative sample?   In part 1, I saw you moved some of the spec mentions to be in a `@spec`, but in this PR, you're adding specs in the APIs.

In many of our APIs, we mention things "...such as...RFC 2246...", but we make no effort to be complete by providing a list of specs.

For example:

SSLEngine.java:  only TLSv1.0 was mentioned, but there's also SSLv3/1.1/1.2/1.3, and DTLS 1.0/1.2.

SSLSocket.java:  your change only lists 7301, but not 2246.  But same issue as SSLEngine, there are others specs this also applies to.

java.security.Key.java:  RFC 5280 was the only spec called out.  There are many other Key types.

SecureRandom:  RFC 4086 was called out.  There are others.

If you want to mention a bunch of the security specs, I think we need to better understand the scope of what you're trying to do, and how this will be kept in sync with Chapter 4 of the Security Documentation (Providers):  which also could use some updates-e.g. TLSv1.x RFCs, but that is another RFE for another day.

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

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

From duke at openjdk.org  Fri Apr 14 07:59:49 2023
From: duke at openjdk.org (Varada M)
Date: Fri, 14 Apr 2023 07:59:49 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
Message-ID: <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>

> Breaking this into two parts : 
> 
> 1. Implementing socket options for AIX 
> 2. DontFragmentTest failure 
> 
> - Implementing socket options for AIX :
> 
> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
> 
> - DontFragment test failure :
> 
> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
> 
> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)

Varada M has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into aix_socket_options
 - Updated copyright year
 - Update to copyright year
 - AIX socket options
 - aix socket options
 - AIX Socket Options

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

Changes: https://git.openjdk.org/jdk/pull/13240/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13240&range=03
  Stats: 411 lines in 4 files changed: 409 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13240.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13240/head:pull/13240

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

From djelinski at openjdk.org  Fri Apr 14 08:58:38 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 14 Apr 2023 08:58:38 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
Message-ID: <oMpUOHFixivMmwW5LqZoTdXOUAHjJRt7nUoK_aAs4ac=.7e861b3f-ea90-48b7-82af-a894b3adfca6@github.com>

On Fri, 14 Apr 2023 07:59:49 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into aix_socket_options
>  - Updated copyright year
>  - Update to copyright year
>  - AIX socket options
>  - aix socket options
>  - AIX Socket Options

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13240#pullrequestreview-1384980796

From jpai at openjdk.org  Fri Apr 14 09:13:38 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Apr 2023 09:13:38 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
Message-ID: <RB8EpdrNhAVnU2ISjiCZ645Z1Kt1yiDi3yPokDLjEBc=.63242c82-4798-4dee-b94f-39fb1d7d5172@github.com>

On Fri, 14 Apr 2023 07:59:49 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into aix_socket_options
>  - Updated copyright year
>  - Update to copyright year
>  - AIX socket options
>  - aix socket options
>  - AIX Socket Options

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13240#pullrequestreview-1385016595

From dfuchs at openjdk.org  Fri Apr 14 09:13:42 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Apr 2023 09:13:42 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
Message-ID: <a01s8hNr1PacdE2XM7VOgIpaJa40wDZMCkAdjKl0Bqw=.088d49ec-504c-4520-9c88-992167096bdc@github.com>

On Fri, 14 Apr 2023 07:59:49 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into aix_socket_options
>  - Updated copyright year
>  - Update to copyright year
>  - AIX socket options
>  - aix socket options
>  - AIX Socket Options

src/jdk.net/aix/native/libextnet/AIXSocketOptions.c line 130:

> 128: 
> 129:     if ((rv=getsockopt(fd, SOL_SOCKET, SO_PEERID, &cred_info, &len)) < 0) {
> 130:         handleError(env, rv, "get  failed");

Is the double space after "get  " intended here, or is something missing from the error message?

src/jdk.net/aix/native/libextnet/AIXSocketOptions.c line 133:

> 131:     } else {
> 132:         if ((int)cred_info.euid == -1) {
> 133:             handleError(env, -1, "get  failed");

Same here...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166550875
PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166551515

From duke at openjdk.org  Fri Apr 14 10:55:41 2023
From: duke at openjdk.org (Varada M)
Date: Fri, 14 Apr 2023 10:55:41 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <a01s8hNr1PacdE2XM7VOgIpaJa40wDZMCkAdjKl0Bqw=.088d49ec-504c-4520-9c88-992167096bdc@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
 <a01s8hNr1PacdE2XM7VOgIpaJa40wDZMCkAdjKl0Bqw=.088d49ec-504c-4520-9c88-992167096bdc@github.com>
Message-ID: <2GpLJhYzD5gZ-uMe-CUdJ_KSUajTjQLNhBrIZFro6oA=.7aa4a063-723a-4bd1-b849-a5d6dc77d97f@github.com>

On Fri, 14 Apr 2023 09:10:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Varada M has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into aix_socket_options
>>  - Updated copyright year
>>  - Update to copyright year
>>  - AIX socket options
>>  - aix socket options
>>  - AIX Socket Options
>
> src/jdk.net/aix/native/libextnet/AIXSocketOptions.c line 130:
> 
>> 128: 
>> 129:     if ((rv=getsockopt(fd, SOL_SOCKET, SO_PEERID, &cred_info, &len)) < 0) {
>> 130:         handleError(env, rv, "get  failed");
> 
> Is the double space after "get  " intended here, or is something missing from the error message?

It is intended

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166685715

From dfuchs at openjdk.org  Fri Apr 14 11:30:36 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Apr 2023 11:30:36 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <2GpLJhYzD5gZ-uMe-CUdJ_KSUajTjQLNhBrIZFro6oA=.7aa4a063-723a-4bd1-b849-a5d6dc77d97f@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
 <a01s8hNr1PacdE2XM7VOgIpaJa40wDZMCkAdjKl0Bqw=.088d49ec-504c-4520-9c88-992167096bdc@github.com>
 <2GpLJhYzD5gZ-uMe-CUdJ_KSUajTjQLNhBrIZFro6oA=.7aa4a063-723a-4bd1-b849-a5d6dc77d97f@github.com>
Message-ID: <2g9qkOUiq_N7v1-pQRvK7uh-M7NJwIF8wHVoAdXCYG4=.4f5398c6-28da-44fb-adbb-96fb0414fff8@github.com>

On Fri, 14 Apr 2023 10:52:45 GMT, Varada M <duke at openjdk.org> wrote:

>> src/jdk.net/aix/native/libextnet/AIXSocketOptions.c line 130:
>> 
>>> 128: 
>>> 129:     if ((rv=getsockopt(fd, SOL_SOCKET, SO_PEERID, &cred_info, &len)) < 0) {
>>> 130:         handleError(env, rv, "get  failed");
>> 
>> Is the double space after "get  " intended here, or is something missing from the error message?
>
> It is intended

I'm curious, what is the rationale?
By comparison the Linux version has: 

        handleError(env, rv, "get SO_PEERCRED failed");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166718087

From vtewari at openjdk.org  Fri Apr 14 11:36:36 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Fri, 14 Apr 2023 11:36:36 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
Message-ID: <eeT70XbdoXbfjnAjtujgce3AylaLjd_-1jhhKgSlJNw=.c4935a3a-f801-428a-9b53-0e7922407f18@github.com>

On Fri, 14 Apr 2023 07:59:49 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into aix_socket_options
>  - Updated copyright year
>  - Update to copyright year
>  - AIX socket options
>  - aix socket options
>  - AIX Socket Options

looks OK

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

PR Review: https://git.openjdk.org/jdk/pull/13240#pullrequestreview-1385287637

From duke at openjdk.org  Fri Apr 14 11:36:38 2023
From: duke at openjdk.org (Varada M)
Date: Fri, 14 Apr 2023 11:36:38 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <2g9qkOUiq_N7v1-pQRvK7uh-M7NJwIF8wHVoAdXCYG4=.4f5398c6-28da-44fb-adbb-96fb0414fff8@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
 <a01s8hNr1PacdE2XM7VOgIpaJa40wDZMCkAdjKl0Bqw=.088d49ec-504c-4520-9c88-992167096bdc@github.com>
 <2GpLJhYzD5gZ-uMe-CUdJ_KSUajTjQLNhBrIZFro6oA=.7aa4a063-723a-4bd1-b849-a5d6dc77d97f@github.com>
 <2g9qkOUiq_N7v1-pQRvK7uh-M7NJwIF8wHVoAdXCYG4=.4f5398c6-28da-44fb-adbb-96fb0414fff8@github.com>
Message-ID: <tkSbYirgEikthVSBdoe7S-we9vz6WRdp8zX6Yuc1Dnc=.9d075d46-634b-4548-b765-8c2454e6d5c9@github.com>

On Fri, 14 Apr 2023 11:27:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> It is intended
>
> I'm curious, what is the rationale?
> By comparison the Linux version has: 
> 
>         handleError(env, rv, "get SO_PEERCRED failed");

On linux it is implemented from [attachListener_linux.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/attachListener_linux.cpp#L361) and on aix it is from [attachListener_aix.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/attachListener_aix.cpp#L392)
In both the cases when rv == -1 , it fails to get this socket option.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166722914

From jpai at openjdk.org  Fri Apr 14 12:01:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Apr 2023 12:01:34 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <tkSbYirgEikthVSBdoe7S-we9vz6WRdp8zX6Yuc1Dnc=.9d075d46-634b-4548-b765-8c2454e6d5c9@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
 <a01s8hNr1PacdE2XM7VOgIpaJa40wDZMCkAdjKl0Bqw=.088d49ec-504c-4520-9c88-992167096bdc@github.com>
 <2GpLJhYzD5gZ-uMe-CUdJ_KSUajTjQLNhBrIZFro6oA=.7aa4a063-723a-4bd1-b849-a5d6dc77d97f@github.com>
 <2g9qkOUiq_N7v1-pQRvK7uh-M7NJwIF8wHVoAdXCYG4=.4f5398c6-28da-44fb-adbb-96fb0414fff8@github.com>
 <tkSbYirgEikthVSBdoe7S-we9vz6WRdp8zX6Yuc1Dnc=.9d075d46-634b-4548-b765-8c2454e6d5c9@github.com>
Message-ID: <FE2JhFdS1DNR7862zTH8_zTKAJiaqwCOrbQ3i0OfBzU=.68bf1efb-2628-4a41-a872-15c13ffc99f2@github.com>

On Fri, 14 Apr 2023 11:33:13 GMT, Varada M <duke at openjdk.org> wrote:

>> I'm curious, what is the rationale?
>> By comparison the Linux version has: 
>> 
>>         handleError(env, rv, "get SO_PEERCRED failed");
>
> On linux it is implemented from [attachListener_linux.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/attachListener_linux.cpp#L361) and on aix it is from [attachListener_aix.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/attachListener_aix.cpp#L392)
> In both the cases when rv == -1 , it fails to get this socket option.

Hello Varada, so the Linux version uses `SO_PEERCRED` socket option and when it fails, the error message says "get SO_PEERCRED failed". The AIX version uses `SO_PEERID` and if it fails, the current proposed form in this PR will report the error message as "get  failed" which wouldn't be too informative.

I'm guessing that the reason you didn't include the socket option in the error message is perhaps because the native socket option (on AIX) is `SO_PEERID` but this method is named `getSoPeerCred`. So it might be confusing to report `SO_PEERID` in the error message. Maybe you could change the message to just "getSoPeerCred failed"  instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166743891

From duke at openjdk.org  Fri Apr 14 12:16:34 2023
From: duke at openjdk.org (Varada M)
Date: Fri, 14 Apr 2023 12:16:34 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <FE2JhFdS1DNR7862zTH8_zTKAJiaqwCOrbQ3i0OfBzU=.68bf1efb-2628-4a41-a872-15c13ffc99f2@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
 <a01s8hNr1PacdE2XM7VOgIpaJa40wDZMCkAdjKl0Bqw=.088d49ec-504c-4520-9c88-992167096bdc@github.com>
 <2GpLJhYzD5gZ-uMe-CUdJ_KSUajTjQLNhBrIZFro6oA=.7aa4a063-723a-4bd1-b849-a5d6dc77d97f@github.com>
 <2g9qkOUiq_N7v1-pQRvK7uh-M7NJwIF8wHVoAdXCYG4=.4f5398c6-28da-44fb-adbb-96fb0414fff8@github.com>
 <tkSbYirgEikthVSBdoe7S-we9vz6WRdp8zX6Yuc1Dnc=.9d075d46-634b-4548-b765-8c2454e6d5c9@github.com>
 <FE2JhFdS1DNR7862zTH8_zTKAJiaqwCOrbQ3i0OfBzU=.68bf1efb-2628-4a41-a872-15c13ffc99f2@github.com>
Message-ID: <-HT-C2EaMw-QqnO7GH-eu-64jOG8QOsoG8g7HNZUT9g=.821df6e9-5837-47e8-8ae8-515dc9414a7a@github.com>

On Fri, 14 Apr 2023 11:58:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> On linux it is implemented from [attachListener_linux.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/attachListener_linux.cpp#L361) and on aix it is from [attachListener_aix.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/attachListener_aix.cpp#L392)
>> In both the cases when rv == -1 , it fails to get this socket option.
>
> Hello Varada, so the Linux version uses `SO_PEERCRED` socket option and when it fails, the error message says "get SO_PEERCRED failed". The AIX version uses `SO_PEERID` and if it fails, the current proposed form in this PR will report the error message as "get  failed" which wouldn't be too informative.
> 
> I'm guessing that the reason you didn't include the socket option in the error message is perhaps because the native socket option (on AIX) is `SO_PEERID` but this method is named `getSoPeerCred`. So it might be confusing to report `SO_PEERID` in the error message. Maybe you could change the message to just "getSoPeerCred failed"  instead?

The method name `getSoPeerCred` is the one used in ExtendedSocketOptions.java, which we are overriding here.
The supported socket option on AIX for is  `SO_PEERID` . I will add `"get SO_PEERID failed"`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166754770

From dfuchs at openjdk.org  Fri Apr 14 12:16:35 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Apr 2023 12:16:35 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <-HT-C2EaMw-QqnO7GH-eu-64jOG8QOsoG8g7HNZUT9g=.821df6e9-5837-47e8-8ae8-515dc9414a7a@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
 <a01s8hNr1PacdE2XM7VOgIpaJa40wDZMCkAdjKl0Bqw=.088d49ec-504c-4520-9c88-992167096bdc@github.com>
 <2GpLJhYzD5gZ-uMe-CUdJ_KSUajTjQLNhBrIZFro6oA=.7aa4a063-723a-4bd1-b849-a5d6dc77d97f@github.com>
 <2g9qkOUiq_N7v1-pQRvK7uh-M7NJwIF8wHVoAdXCYG4=.4f5398c6-28da-44fb-adbb-96fb0414fff8@github.com>
 <tkSbYirgEikthVSBdoe7S-we9vz6WRdp8zX6Yuc1Dnc=.9d075d46-634b-4548-b765-8c2454e6d5c9@github.com>
 <FE2JhFdS1DNR7862zTH8_zTKAJiaqwCOrbQ3i0OfBzU=.68bf1efb-2628-4a41-a872-15c13ffc99f2@github.com>
 <-HT-C2EaMw-QqnO7GH-eu-64jOG8QOsoG8g7HNZUT9g=.821df6e9-5837-47e8-8ae8-515dc9414a7a@github.com>
Message-ID: <c_nk1eFgyOUl5jIJTGqMOLxXTgw4x9qrtcbMc72nugU=.314ed055-d6c6-467d-a721-b871502a0ad7@github.com>

On Fri, 14 Apr 2023 12:09:48 GMT, Varada M <duke at openjdk.org> wrote:

>> Hello Varada, so the Linux version uses `SO_PEERCRED` socket option and when it fails, the error message says "get SO_PEERCRED failed". The AIX version uses `SO_PEERID` and if it fails, the current proposed form in this PR will report the error message as "get  failed" which wouldn't be too informative.
>> 
>> I'm guessing that the reason you didn't include the socket option in the error message is perhaps because the native socket option (on AIX) is `SO_PEERID` but this method is named `getSoPeerCred`. So it might be confusing to report `SO_PEERID` in the error message. Maybe you could change the message to just "getSoPeerCred failed"  instead?
>
> The method name `getSoPeerCred` is the one used in ExtendedSocketOptions.java, which we are overriding here.
> The supported socket option on AIX for is  `SO_PEERID` . I will add `"get SO_PEERID failed"`

For consistency reasons I think I would prefer the message to be "get SO_PEERID failed". All the other methods in this file seem to use the native option name, so let's keep things consistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166757202

From dfuchs at openjdk.org  Fri Apr 14 12:16:41 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Apr 2023 12:16:41 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
Message-ID: <9bUMBNdKe6526js1cLAdCOL5V7rOeHn4lvUjMDjFfTo=.008a5757-2b20-4bdc-94c4-b7d80dea074d@github.com>

On Fri, 14 Apr 2023 07:59:49 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into aix_socket_options
>  - Updated copyright year
>  - Update to copyright year
>  - AIX socket options
>  - aix socket options
>  - AIX Socket Options

src/jdk.net/aix/native/libextnet/AIXSocketOptions.c line 130:

> 128: 
> 129:     if ((rv=getsockopt(fd, SOL_SOCKET, SO_PEERID, &cred_info, &len)) < 0) {
> 130:         handleError(env, rv, "get  failed");

Suggestion:

        handleError(env, rv, "get SO_PEERID failed");

src/jdk.net/aix/native/libextnet/AIXSocketOptions.c line 133:

> 131:     } else {
> 132:         if ((int)cred_info.euid == -1) {
> 133:             handleError(env, -1, "get  failed");

Suggestion:

            handleError(env, -1, "get SO_PEERID failed");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166758749
PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166759161

From duke at openjdk.org  Fri Apr 14 12:32:32 2023
From: duke at openjdk.org (Varada M)
Date: Fri, 14 Apr 2023 12:32:32 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v5]
In-Reply-To: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
Message-ID: <W77xJ7lUtfUe3G7785a9yn6eiJkKu4ERzrbsQtaqe-c=.c073ea76-7319-4fd5-8161-8c780070f08f@github.com>

> Breaking this into two parts : 
> 
> 1. Implementing socket options for AIX 
> 2. DontFragmentTest failure 
> 
> - Implementing socket options for AIX :
> 
> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
> 
> - DontFragment test failure :
> 
> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
> 
> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)

Varada M has updated the pull request incrementally with one additional commit since the last revision:

  added SO_PEERID failed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13240/files
  - new: https://git.openjdk.org/jdk/pull/13240/files/5b2fd5e2..d595d962

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

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

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

From dfuchs at openjdk.org  Fri Apr 14 12:32:33 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Apr 2023 12:32:33 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v5]
In-Reply-To: <W77xJ7lUtfUe3G7785a9yn6eiJkKu4ERzrbsQtaqe-c=.c073ea76-7319-4fd5-8161-8c780070f08f@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <W77xJ7lUtfUe3G7785a9yn6eiJkKu4ERzrbsQtaqe-c=.c073ea76-7319-4fd5-8161-8c780070f08f@github.com>
Message-ID: <yd7riNxvUsE8bCLcnM08yfhiV3WivAzsha7odQpX7Js=.2fb8de03-5d50-41ef-8cb7-57f605b76303@github.com>

On Fri, 14 Apr 2023 12:27:30 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added SO_PEERID failed

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13240#pullrequestreview-1385367531

From duke at openjdk.org  Fri Apr 14 12:32:38 2023
From: duke at openjdk.org (Varada M)
Date: Fri, 14 Apr 2023 12:32:38 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v4]
In-Reply-To: <9bUMBNdKe6526js1cLAdCOL5V7rOeHn4lvUjMDjFfTo=.008a5757-2b20-4bdc-94c4-b7d80dea074d@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <v9-7MoJFK31r_W40E2qZOl-0ENBQV03C4L91o3p4VSg=.e36fd285-a9d7-4d21-9179-052fa2ee8b4d@github.com>
 <9bUMBNdKe6526js1cLAdCOL5V7rOeHn4lvUjMDjFfTo=.008a5757-2b20-4bdc-94c4-b7d80dea074d@github.com>
Message-ID: <1b7Dq_aUI6oCkcQHPuocX9Bf0v1r1cZ5X_90Zk3_efY=.26335d57-667a-4423-b741-e16ffbb2a705@github.com>

On Fri, 14 Apr 2023 12:13:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Varada M has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into aix_socket_options
>>  - Updated copyright year
>>  - Update to copyright year
>>  - AIX socket options
>>  - aix socket options
>>  - AIX Socket Options
>
> src/jdk.net/aix/native/libextnet/AIXSocketOptions.c line 133:
> 
>> 131:     } else {
>> 132:         if ((int)cred_info.euid == -1) {
>> 133:             handleError(env, -1, "get  failed");
> 
> Suggestion:
> 
>             handleError(env, -1, "get SO_PEERID failed");

Thanks @dfuch and @jaikiran. I have updated to `"get SO_PEERID failed"`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13240#discussion_r1166772753

From jjg at openjdk.org  Fri Apr 14 20:12:34 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 14 Apr 2023 20:12:34 GMT
Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3]
In-Reply-To: <pIAgd90HZULenLPxOFuq6VZdWfWZs0l4oKgUIHfOMTQ=.84f00548-51f8-4982-984e-ae8785f26c54@github.com>
References: <JoYI-wtX99q1Fj7w2jdfWVmgLQx9QHg90EfwAoBbrDg=.2d1fbf04-3ecb-4ee6-9c5a-ab2610785e32@github.com>
 <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com>
 <pIAgd90HZULenLPxOFuq6VZdWfWZs0l4oKgUIHfOMTQ=.84f00548-51f8-4982-984e-ae8785f26c54@github.com>
Message-ID: <0uQtS932l0j2dzw4f8mn4uiPznDPfSNNUixv9UoS8bI=.9a6d465e-b3cd-487d-a7b3-5c108fb14c1e@github.com>

On Fri, 14 Apr 2023 05:07:18 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedback
>
> I'm coming to this late, but what is the breadth of the specs you're trying to call out?  Where did you obtain this list?  Are all of these changes coming from existing mentions in the current APIs, and you're just adding a `@spec` in various places?   Or are you trying to be complete, or just list a representative sample?   In part 1, I saw you moved some of the spec mentions to be in a `@spec`, but in this PR, you're adding specs in the APIs.
> 
> In many of our APIs, we mention things "...such as...RFC 2246...", but we make no effort to be complete by providing a list of specs.
> 
> For example:
> 
> SSLEngine.java:  only TLSv1.0 was mentioned, but there's also SSLv3/1.1/1.2/1.3, and DTLS 1.0/1.2.
> 
> SSLSocket.java:  your change only lists 7301, but not 2246.  But same issue as SSLEngine, there are others specs this also applies to.
> 
> java.security.Key.java:  RFC 5280 was the only spec called out.  There are many other Key types.
> 
> SecureRandom:  RFC 4086 was called out.  There are others.
> 
> If you want to mention a bunch of the security specs, I think we need to better understand the scope of what you're trying to do, and how this will be kept in sync with Chapter 4 of the Security Documentation (Providers):  which also could use some updates-e.g. TLSv1.x RFCs, but that is another RFE for another day.

@bradfordwetmore 
> I'm coming to this late, but what is the breadth of the specs you're trying to call out? 

This is a mostly automated update based on existing references to well-known specifications.  

* **Mostly automated** means it was done by a custom utility program, but I hand-edited the output to improve line-wrapping, etc.
* **Existing references** means found in `<a href=...>` in the same doc comment to which the `@spec` is added, where that HTML link may appear in either narrative text or in a `@see` tag
* **Well-known specifications** means that the utility was looking for well-known hosts/urls. The list of the hosts that was used is `ietf.org`, `unicode.org`, `w3.org`, `iana.org`, `iso.org`, and references to the sibling `specs` directory that exists beside the main `api` directory.  While those are the hosts, the pattern matching was more specific to singleton URLs or groups of URLs at each site.

The update uses "normative"/"preferred" URLs for each spec, to avoid the variety of different URLs used for some of the specs, reflecting _different_ hosts and/or paths for the _same_ specification.
The goal is just to add these `@spec` tags without any semantic change to the specification. As such, no CSR is required for this work.

If there are additional `@spec` tags that should be added for existing references, I can do that here in this PR, or in followup work. It has already been noted that I missed the references to `nist.gov`.

If there are additional specifications that should be included (that are not currently mentioned) that is a task for the relevant developers in the relevant component teams. I would expect any such work to be done separately, later.

It is also a future-goal to clean up the existing `href` references to the same general form of URL as given in the `@spec` tag, thus normalizing the host and path that we use for each specification (or the root of a multi-page specification.). 

The effect of the `@spec` tags is to list the specifications for a declaration in a list headed `External Specifications`, similar to the existing `See Also` list.  Eventually, we will enable a new summary page headed `External Specifications` that lists all the specs listed in `@spec` tags, providing links to where the specs are mentioned. That page is currently temporarily disabled until we have a more complete set of `@spec` tags in most or all modules.  Using the canonical form of spec URLs and titles in `@spec` tags, and having the cross-referenced list on that new `External Specifications` page should make it easier to find and maintain these references going forward.

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

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

From duke at openjdk.org  Mon Apr 17 05:10:44 2023
From: duke at openjdk.org (Varada M)
Date: Mon, 17 Apr 2023 05:10:44 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v5]
In-Reply-To: <W77xJ7lUtfUe3G7785a9yn6eiJkKu4ERzrbsQtaqe-c=.c073ea76-7319-4fd5-8161-8c780070f08f@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <W77xJ7lUtfUe3G7785a9yn6eiJkKu4ERzrbsQtaqe-c=.c073ea76-7319-4fd5-8161-8c780070f08f@github.com>
Message-ID: <DQCX2Z8bdFKp6QFN_su-a-aDlh0xRMLP-e4JI0vvR-E=.224839a5-61d8-479f-a7ec-16ae06f85f48@github.com>

On Fri, 14 Apr 2023 12:32:32 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added SO_PEERID failed

Not sure the PR is ready for integration or not. Can anyone tell me is this PR ready for integration or should I wait for more reviewers to approve the changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/13240#issuecomment-1510709112

From jpai at openjdk.org  Mon Apr 17 05:16:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Apr 2023 05:16:45 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v5]
In-Reply-To: <W77xJ7lUtfUe3G7785a9yn6eiJkKu4ERzrbsQtaqe-c=.c073ea76-7319-4fd5-8161-8c780070f08f@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <W77xJ7lUtfUe3G7785a9yn6eiJkKu4ERzrbsQtaqe-c=.c073ea76-7319-4fd5-8161-8c780070f08f@github.com>
Message-ID: <UipPkeck-vQkWbNUGb83QKWnH_SiPr96Q5_8BLzVgyk=.e8508488-7d37-4655-9bf9-7e7e016a4c28@github.com>

On Fri, 14 Apr 2023 12:32:32 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added SO_PEERID failed

Hello Varada, you can go ahead and issue the /integrate command.

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

PR Comment: https://git.openjdk.org/jdk/pull/13240#issuecomment-1510714473

From duke at openjdk.org  Mon Apr 17 05:16:45 2023
From: duke at openjdk.org (Varada M)
Date: Mon, 17 Apr 2023 05:16:45 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v5]
In-Reply-To: <UipPkeck-vQkWbNUGb83QKWnH_SiPr96Q5_8BLzVgyk=.e8508488-7d37-4655-9bf9-7e7e016a4c28@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <W77xJ7lUtfUe3G7785a9yn6eiJkKu4ERzrbsQtaqe-c=.c073ea76-7319-4fd5-8161-8c780070f08f@github.com>
 <UipPkeck-vQkWbNUGb83QKWnH_SiPr96Q5_8BLzVgyk=.e8508488-7d37-4655-9bf9-7e7e016a4c28@github.com>
Message-ID: <o2Tq3mhEgfJU4nAvorlPsALI0YT0H4T41Nl5t3Vp3ZA=.59cb6a24-cd5c-4133-a772-f74c8af2fa70@github.com>

On Mon, 17 Apr 2023 05:13:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added SO_PEERID failed
>
> Hello Varada, you can go ahead and issue the /integrate command.

Thank you @jaikiran

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

PR Comment: https://git.openjdk.org/jdk/pull/13240#issuecomment-1510715284

From jpai at openjdk.org  Mon Apr 17 05:27:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Apr 2023 05:27:35 GMT
Subject: RFR: 8305089: Implement missing socket options on AIX [v5]
In-Reply-To: <W77xJ7lUtfUe3G7785a9yn6eiJkKu4ERzrbsQtaqe-c=.c073ea76-7319-4fd5-8161-8c780070f08f@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
 <W77xJ7lUtfUe3G7785a9yn6eiJkKu4ERzrbsQtaqe-c=.c073ea76-7319-4fd5-8161-8c780070f08f@github.com>
Message-ID: <1W9EkR_0FFZGlyhHkifHu9GYinKI-_7XBvj3zQZY-Ec=.384453cb-32c2-4823-bd27-f8287d2bcb79@github.com>

On Fri, 14 Apr 2023 12:32:32 GMT, Varada M <duke at openjdk.org> wrote:

>> Breaking this into two parts : 
>> 
>> 1. Implementing socket options for AIX 
>> 2. DontFragmentTest failure 
>> 
>> - Implementing socket options for AIX :
>> 
>> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
>> 
>> - DontFragment test failure :
>> 
>> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
>> 
>> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added SO_PEERID failed

These changes shouldn't cause any regressions, but just to be sure, I've triggered a CI run with these changes. I can sponsor this change once the results are available.

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

PR Comment: https://git.openjdk.org/jdk/pull/13240#issuecomment-1510722415

From duke at openjdk.org  Mon Apr 17 07:34:00 2023
From: duke at openjdk.org (Varada M)
Date: Mon, 17 Apr 2023 07:34:00 GMT
Subject: Integrated: 8305089: Implement missing socket options on AIX
In-Reply-To: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
References: <PRoena-gGKmycrcj7umh9DI3196N3EWH16kU2Ynpiak=.0dd9fb0d-d1f1-4193-b640-df7632b21d1e@github.com>
Message-ID: <8DKM7UhI83cTpu-OC9IpVr4Ozc2gdqJ7fd1uSrZV8fw=.394ba45f-d68f-4161-b25c-90713823d641@github.com>

On Thu, 30 Mar 2023 06:39:57 GMT, Varada M <duke at openjdk.org> wrote:

> Breaking this into two parts : 
> 
> 1. Implementing socket options for AIX 
> 2. DontFragmentTest failure 
> 
> - Implementing socket options for AIX :
> 
> Unlike the linux, windows and macOS, AIX uses the default implementation for socket options such as ipDontFragmentSupported(), keepAliveOptionsSupported(), setTcpkeepAliveProbes, getTcpkeepAliveProbes, setQuickAck, getQuickAck and more, where it either returns false or exception. These options can be implemented on AIX with the supported flags like SO_PEERID, TCP_NODELAYACK is the equivalent AIX option for TCP_QUICKACK and IPPROTO_TCP, IP_DONTFRAG. 
> 
> - DontFragment test failure :
> 
> DontFragmentTest.java fails with a runtime exception : ?IP_DONTFRAGMENT should be supported? because the supportOptions doesn?t contain IP_DONTFRAGMENT flag.
> 
> Reported Issue :  [JDK-8305089](https://bugs.openjdk.org/browse/JDK-8305089)

This pull request has now been integrated.

Changeset: 2a062f16
Author:    Varada M <mvarada2000 at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a062f165491d599eb0dcfb6050eb9186ae31b71
Stats:     411 lines in 4 files changed: 409 ins; 0 del; 2 mod

8305089: Implement missing socket options on AIX

Reviewed-by: erikj, jpai, vtewari, djelinski, dfuchs

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

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

From ccleary at openjdk.org  Mon Apr 17 10:31:45 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Mon, 17 Apr 2023 10:31:45 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v4]
In-Reply-To: <zAofQ8qApMMewmENbyRJFuxvfPxhqovTGJuMPuPgNgM=.63c33609-8e03-4b58-8e72-4aa7ea1fbca8@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <p6d4MbKArIpG0X4_gMpsLMA7nr4A6C_L6kzjAV93zKU=.3433ab41-6c54-49a3-a1b0-3e59e77c31a7@github.com>
 <zAofQ8qApMMewmENbyRJFuxvfPxhqovTGJuMPuPgNgM=.63c33609-8e03-4b58-8e72-4aa7ea1fbca8@github.com>
Message-ID: <Mgn-qzdyDKn85a8WkPFCTKqm0pzbiNqWTlmUJvifVys=.190cf5fa-e197-4b94-a414-493385096b6e@github.com>

On Wed, 12 Apr 2023 11:59:59 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293786: Updated comment in Http2TestServerConnection
>
> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestServerConnection.java line 737:
> 
>> 735:                 // the error code NO_ERROR will be sent to the client before closing.
>> 736:                 if (bis instanceof BodyInputStream inputStream && (!inputStream.isEof() || inputStream.q.size() > 0)) {
>> 737:                     bos.sendResetOnClose(ResetFrame.NO_ERROR);
> 
> I share @dfuch concern. This line will have no effect if `bos` is already closed at this point. We still need to reset the stream to let the peer know that we won't consume `bis`.
> (edit) To illustrate that, try changing `PostPutTest.TestHandler.handle` to one of:
> 
>             exchange.sendResponseHeaders(200, -1);
> 
> or:
> 
>             exchange.sendResponseHeaders(200, 0);
>             exchange.getResponseBody().close();
> 
> it will time out again.

Thanks for the feedback Daniel. I see the issue that my implementation causes if the handler closes the `bos` early. Working on this now as a priority, solution will try to make sure that this RST_STREAM is sent even if the handler looks like the example you gave above. Probably worth inluding these handlers as test cases also.

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

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

From djelinski at openjdk.org  Thu Apr 20 10:30:42 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 20 Apr 2023 10:30:42 GMT
Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled
 HTTP/2 connection for IPv6 address
In-Reply-To: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
Message-ID: <4eagGjf_F29--yy4wylNOKgpYh7vbZBYn9vBf60IZxA=.5e175906-3606-4558-bb34-13811434eb58@github.com>

On Thu, 13 Apr 2023 11:13:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

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

This patch improves the situation, but is not sufficient to address all cases. For example, `http://[::1]` will still not use the cache, because the cache key will contain `[0:0:0:0:0:0:0:1]` instead of `[::1]`.

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

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

From jpai at openjdk.org  Thu Apr 20 11:04:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Apr 2023 11:04:53 GMT
Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled
 HTTP/2 connection for IPv6 address [v2]
In-Reply-To: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
Message-ID: <ZdwVJJL7BtNLT60odl6wFTixbpTTIWcNdOVyqZKHUAA=.5a119ac8-c805-470a-b259-6cc658657a14@github.com>

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

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

  use HttpRequestImpl.getAddress() to lookup cache key instead of HttpRequestImpl.getURI()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13456/files
  - new: https://git.openjdk.org/jdk/pull/13456/files/cf641a69..77547fef

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

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

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

From jpai at openjdk.org  Thu Apr 20 11:06:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Apr 2023 11:06:51 GMT
Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled
 HTTP/2 connection for IPv6 address
In-Reply-To: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
Message-ID: <0sLk-Eq-Mb0aMhooYUhi56VMb6no1icmVXcet3YRY6w=.a6547da6-10fa-48c9-9bc7-a0ebab17571d@github.com>

On Thu, 13 Apr 2023 11:13:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

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

Thank you for catching that, Daniel. You are indeed right, the fix missed this part. I updated the new `ConnectionReuseTest` to run a test which matches what you described and that too fails, with the fix I had in this PR.

I have now updated the PR to use `HttpRequestImpl.getAddress()` (which returns a `InetSocketAddress`) instead of `HttpRequestImpl.getURI()` while looking up the cache keys. What this does is that it gets rid of the usage of the `URI.getHost()` API completely, during connection cache lookups. Instead, this now relies solely on the `InetAddress` API which always returns a long form address string. This is similar to what we do in the HTTP1 connection caching internally.

With this change the `ConnectionReuseTest` passes, even with the newly added additional test. I will run tier tests to make sure this doesn't impact anything else.

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

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

From djelinski at openjdk.org  Thu Apr 20 11:15:53 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 20 Apr 2023 11:15:53 GMT
Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled
 HTTP/2 connection for IPv6 address [v2]
In-Reply-To: <ZdwVJJL7BtNLT60odl6wFTixbpTTIWcNdOVyqZKHUAA=.5a119ac8-c805-470a-b259-6cc658657a14@github.com>
References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
 <ZdwVJJL7BtNLT60odl6wFTixbpTTIWcNdOVyqZKHUAA=.5a119ac8-c805-470a-b259-6cc658657a14@github.com>
Message-ID: <FLJAroz_8rdLHw1ri-y_9s6b6zufuWLK1IgsWW0Y8T0=.c1e34e6a-0b3b-4943-8102-cf76e0cb66d2@github.com>

On Thu, 20 Apr 2023 11:04:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

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

Thanks for the fix, that looks better.

Now that we always use `InetSocketAddress` to build the cache key, do we still need to wrap the hostnames in brackets?

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

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

From jpai at openjdk.org  Fri Apr 21 01:26:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Apr 2023 01:26:35 GMT
Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled
 HTTP/2 connection for IPv6 address [v3]
In-Reply-To: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
Message-ID: <toVD9EaY8qxThRENfJZmZUVnLR6Qmy_VZ4BNyONKslI=.03a27f15-8e36-4624-a2c2-826e8b2d49e0@github.com>

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

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

  wrapping into brackets is no longer needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13456/files
  - new: https://git.openjdk.org/jdk/pull/13456/files/77547fef..96b92659

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

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

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

From serb at openjdk.org  Fri Apr 21 04:56:38 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 04:56:38 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v3]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <cIlWAx5CQhWWBlzkpObw2Hd-gFVhOBpMqLCJpR1grD4=.43c55d8a-c8e3-46cf-a3cd-f9f8f7b0e9e7@github.com>

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

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

 - Merge remote-tracking branch 'upstream/master' into JDK-8304885
 - Use "maximum stale timer" instead of the extended timeout, and bump it on each successful lookup
 -  the suggested cap is 7 days
 - simplify
 - comments
 - Merge remote-tracking branch 'upstream/master' into JDK-8304885
 - 8304885: Reuse stale data to improve DNS resolver resiliency

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13285/files
  - new: https://git.openjdk.org/jdk/pull/13285/files/c9b0d79b..4db0216c

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

  Stats: 10481 lines in 234 files changed: 2916 ins; 7145 del; 420 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

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

From djelinski at openjdk.org  Fri Apr 21 06:19:40 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Apr 2023 06:19:40 GMT
Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled
 HTTP/2 connection for IPv6 address [v3]
In-Reply-To: <toVD9EaY8qxThRENfJZmZUVnLR6Qmy_VZ4BNyONKslI=.03a27f15-8e36-4624-a2c2-826e8b2d49e0@github.com>
References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>
 <toVD9EaY8qxThRENfJZmZUVnLR6Qmy_VZ4BNyONKslI=.03a27f15-8e36-4624-a2c2-826e8b2d49e0@github.com>
Message-ID: <GsG4L7IEcSnoAVNt49c5JKwTbtSAB6OvAgdE-IrI1vw=.e1a1f06f-1e43-437b-af2f-9fa7580dea05@github.com>

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

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

LGTM

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13456#pullrequestreview-1395115657

From serb at openjdk.org  Fri Apr 21 07:18:52 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 07:18:52 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v4]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <39reLvSo1OsI8B5zTQTSQIi0x2y1bcA6VMtjZA0haFA=.c8e76d8d-5c62-4f05-b105-c839a7247b55@github.com>

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

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

 - documentation
 - PR feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13285/files
  - new: https://git.openjdk.org/jdk/pull/13285/files/4db0216c..1c60b4bc

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

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

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

From serb at openjdk.org  Fri Apr 21 07:18:55 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 07:18:55 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v2]
In-Reply-To: <2yOu0fB2oXs0yBd6brvrqOu6-kjOdLNZkZGtJr-Wj2A=.5858fa36-53df-42f4-ae5e-520bd744ca79@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <odnIU2CVVA3icR0FUru394X-P7SpQ5VRpx4hP6fbN-M=.bbea50dd-2a64-4c54-9023-d02a58e09791@github.com>
 <2yOu0fB2oXs0yBd6brvrqOu6-kjOdLNZkZGtJr-Wj2A=.5858fa36-53df-42f4-ae5e-520bd744ca79@github.com>
Message-ID: <eEGR5y5IuVxq8YXv4lz9PITN7y0xkqAcx7JqJXjvV4M=.10bd345a-5e1a-4565-9907-21c0d2d66ae9@github.com>

On Wed, 5 Apr 2023 17:50:53 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Plus, as Alan suggested, a CSR and a release note will also be necessary.

Sure, I just would like to get some initial feedback and have an agreement about the implementation/spec before submitting the CSR.

> src/java.base/share/classes/java/net/InetAddress.java line 980:
> 
>> 978:          * are removed from the expirySet and cache.
>> 979:          */
>> 980:         public boolean expired(long now) {
> 
> This method's name does not reflect what this method does. It may be worth splitting.

It is renamed to describe what it tries to do.

> src/java.base/share/classes/sun/net/InetAddressCachePolicy.java line 126:
> 
>> 124:             tmp = getProperty(cacheStalePolicyProp,
>> 125:                               cacheStalePolicyPropFallback);
>> 126:             if (tmp != null && tmp > cachePolicy) {
> 
> Why do you require cacheStalePolicy > cachePolicy? In your implementation, stale timer starts running after the base timer expires, so lower values still make sense.

correct

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

PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1517376675
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1173390141
PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1173391847

From serb at openjdk.org  Fri Apr 21 18:23:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 21 Apr 2023 18:23:07 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v5]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <32LnosjQ6BjtjndPmWiXGsnT_M2V23eiKf1g2sf__mM=.f80efa43-d669-4c68-81dc-5db1c3a44d97@github.com>

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

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

 - Merge branch 'master' into JDK-8304885
 - documentation
 - PR feedback
 - Merge remote-tracking branch 'upstream/master' into JDK-8304885
 - Use "maximum stale timer" instead of the extended timeout, and bump it on each successful lookup
 -  the suggested cap is 7 days
 - simplify
 - comments
 - Merge remote-tracking branch 'upstream/master' into JDK-8304885
 - 8304885: Reuse stale data to improve DNS resolver resiliency

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13285/files
  - new: https://git.openjdk.org/jdk/pull/13285/files/1c60b4bc..ea3748f2

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

  Stats: 257746 lines in 2248 files changed: 229477 ins; 14767 del; 13502 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

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

From michaelm at openjdk.org  Fri Apr 21 20:47:54 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 21 Apr 2023 20:47:54 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v12]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <p6xZ57dt9D1XNXJnSOZfxki-fqUNtybYC4wTqrR6th8=.b59ccd61-5603-4d92-b099-375968ad7e2e@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

Michael McMahon 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 19 additional commits since the last revision:

 - tests all passing now
 - tidy up
 - Merge branch 'master' into auth
 - update
 - update
 - Merge branch 'master' into auth
 - Update src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - error in test
 - Jai's review
 - update to remove dependency on AuthCacheImpl in j.n.Authenticator
 - ... and 9 more: https://git.openjdk.org/jdk/compare/3e009968...94b50c54

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/d2d27f8c..94b50c54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13159&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13159&range=10-11

  Stats: 227713 lines in 1494 files changed: 213491 ins; 4312 del; 9910 mod
  Patch: https://git.openjdk.org/jdk/pull/13159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13159/head:pull/13159

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

From michaelm at openjdk.org  Fri Apr 21 21:22:53 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 21 Apr 2023 21:22:53 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v9]
In-Reply-To: <P16m39k5_jEIkK93rYgOtlm5HfFOcBG6I5Sxiuscyn0=.b905f0f1-dab1-4e35-9fde-850810caca59@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <il8wj_GCQWJE17M4-Smealjdy6wR2HrovE1MeSKyVkg=.39c0f7e3-2f05-492b-96b2-8f704273e5dc@github.com>
 <VfR_-6lMm_XRslOY970YspXh1fcMLhWWF4KpRLSOTbw=.6e3360b3-c568-48fa-ab7c-64b6bcc6b8bb@github.com>
 <CPqprexw0CuTlgGSpDE1vLYZrs1PJ5A7c5orBeeWthc=.47a43c51-18e1-41e0-812d-c978f2838177@github.com>
 <3yAjvdIW9qvahZOWb9c6IRqnIHg8XDDwpEbunXCN4ag=.4c747e6c-f6bf-4583-ab16-4e7873b88d47@github.com>
 <P16m39k5_jEIkK93rYgOtlm5HfFOcBG6I5Sxiuscyn0=.b905f0f1-dab1-4e35-9fde-850810caca59@github.com>
Message-ID: <MsHS92gKnN0_YxtWzVv01AewfBtb6SMkoq5SdQEWmV8=.5c8dabeb-36e7-4bc3-b719-5478b314489a@github.com>

On Thu, 13 Apr 2023 11:33:26 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Possibly - but there seems to be a lot of churn caused by having to pass an AuthCacheImpl instance to the AuthCacheValue now. It makes it a bit difficult to reason about. I just wonder if *not* passing that value would not simplify the fix considerably. I'll try to import your changes and see what I can find.
>
> Okay, I'll take a look and see if it can be simplified. Yes, I can move the caching methods from AuthCacheValue to AuthCacheImpl. I don't think it will simplify this fix as such, but the resulting code is probably more readble.

I've just pushed an update to the implementation which removes the reference to the cache from the `AuthCacheValue`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1174170256

From duke at openjdk.org  Mon Apr 24 10:07:48 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 24 Apr 2023 10:07:48 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking [v2]
In-Reply-To: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
Message-ID: <Hx0Us79HXTu9czSE_tnIxDi9gXXUM33mVF1434PgcCI=.03a299ec-9f91-481c-9625-48d6b8bf2b41@github.com>

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

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

  added additional tests, cleaned up code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13330/files
  - new: https://git.openjdk.org/jdk/pull/13330/files/3da5096f..d8288cde

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

  Stats: 275 lines in 2 files changed: 127 ins; 87 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/13330.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13330/head:pull/13330

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

From duke at openjdk.org  Mon Apr 24 10:08:09 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 24 Apr 2023 10:08:09 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking
In-Reply-To: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
Message-ID: <-uWrDT3NYEc2NVu9_5bewkinpFkT1XcX6LbQGNtDpPs=.6597bb48-cf3b-4d47-b157-6ed8093d774c@github.com>

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

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

Sorry for the delay in responding to the feedback, I was sidetracked on some other tasks then had an intermittent failure when I was adding the new fixed Length tests here.

I've added 3 tests to cover fixed length, tried to cut down some duplication by creating a shared `createConnection` method and cut down some of the server code.

Let me know if there are any other changes that should be made.

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

PR Comment: https://git.openjdk.org/jdk/pull/13330#issuecomment-1519829762

From dfuchs at openjdk.org  Mon Apr 24 12:20:53 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Apr 2023 12:20:53 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v12]
In-Reply-To: <p6xZ57dt9D1XNXJnSOZfxki-fqUNtybYC4wTqrR6th8=.b59ccd61-5603-4d92-b099-375968ad7e2e@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <p6xZ57dt9D1XNXJnSOZfxki-fqUNtybYC4wTqrR6th8=.b59ccd61-5603-4d92-b099-375968ad7e2e@github.com>
Message-ID: <4p1ylwSM2x4Had5bSqQoK3DDU-LgXvPcVDrAGE5a3ws=.76721992-aef4-456c-aa1e-a034a9fd9a24@github.com>

On Fri, 21 Apr 2023 20:47:54 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon 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 19 additional commits since the last revision:
> 
>  - tests all passing now
>  - tidy up
>  - Merge branch 'master' into auth
>  - update
>  - update
>  - Merge branch 'master' into auth
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - error in test
>  - Jai's review
>  - update to remove dependency on AuthCacheImpl in j.n.Authenticator
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/dca4c518...94b50c54

That looks good now! Thanks Michael for working on this.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13159#pullrequestreview-1397857379

From michaelm at openjdk.org  Mon Apr 24 14:11:09 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 24 Apr 2023 14:11:09 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v13]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <8nZMhgy4cqZ9-k4BEjz-246NWDuJ5IqxGJs9ym9vdfM=.7c61aea2-3d2c-41c7-a1be-033a3cb66f4b@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

Michael McMahon 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 20 additional commits since the last revision:

 - Merge branch 'master' into auth
 - tests all passing now
 - tidy up
 - Merge branch 'master' into auth
 - update
 - update
 - Merge branch 'master' into auth
 - Update src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - error in test
 - Jai's review
 - ... and 10 more: https://git.openjdk.org/jdk/compare/cd184cdd...93a55fe1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/94b50c54..93a55fe1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13159&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13159&range=11-12

  Stats: 9466 lines in 199 files changed: 5761 ins; 2782 del; 923 mod
  Patch: https://git.openjdk.org/jdk/pull/13159.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13159/head:pull/13159

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

From djelinski at openjdk.org  Mon Apr 24 16:31:54 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Apr 2023 16:31:54 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v13]
In-Reply-To: <8nZMhgy4cqZ9-k4BEjz-246NWDuJ5IqxGJs9ym9vdfM=.7c61aea2-3d2c-41c7-a1be-033a3cb66f4b@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <8nZMhgy4cqZ9-k4BEjz-246NWDuJ5IqxGJs9ym9vdfM=.7c61aea2-3d2c-41c7-a1be-033a3cb66f4b@github.com>
Message-ID: <jIQcRcsMGaQR1tXoonjh6m3VPZMulTOpOuQ5243gzpA=.ca37e035-48e3-4138-8678-0f086b102356@github.com>

On Mon, 24 Apr 2023 14:11:09 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon 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 20 additional commits since the last revision:
> 
>  - Merge branch 'master' into auth
>  - tests all passing now
>  - tidy up
>  - Merge branch 'master' into auth
>  - update
>  - update
>  - Merge branch 'master' into auth
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - error in test
>  - Jai's review
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/a76a3f2e...93a55fe1

src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheValue.java line 47:

> 45:      * The default authentication cache
> 46:      */
> 47:     protected static final AuthCacheImpl defCache = new AuthCacheImpl();

Is this still needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1175531617

From djelinski at openjdk.org  Mon Apr 24 17:09:02 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Apr 2023 17:09:02 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v13]
In-Reply-To: <8nZMhgy4cqZ9-k4BEjz-246NWDuJ5IqxGJs9ym9vdfM=.7c61aea2-3d2c-41c7-a1be-033a3cb66f4b@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <8nZMhgy4cqZ9-k4BEjz-246NWDuJ5IqxGJs9ym9vdfM=.7c61aea2-3d2c-41c7-a1be-033a3cb66f4b@github.com>
Message-ID: <1JzQB0A5KDk_pjmzwQ-p7V6rQajb4I6m_xuo0Tp1srg=.a4fa10ec-872f-4fc7-b9a3-06746896533b@github.com>

On Mon, 24 Apr 2023 14:11:09 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon 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 20 additional commits since the last revision:
> 
>  - Merge branch 'master' into auth
>  - tests all passing now
>  - tidy up
>  - Merge branch 'master' into auth
>  - update
>  - update
>  - Merge branch 'master' into auth
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - error in test
>  - Jai's review
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/60bdee78...93a55fe1

Looks good overall. Some files need copyright updates.

src/java.base/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java line 118:

> 116:     private static NTLMAuthenticationProxy tryLoadNTLMAuthentication() {
> 117:         Class<? extends AuthenticationInfo> cl;
> 118:         Constructor<? extends AuthenticationInfo> fourArg, fiveArg;

Nit: the number of arguments changed again.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13159#pullrequestreview-1398461196
PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1175566657

From michaelm at openjdk.org  Mon Apr 24 17:09:04 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 24 Apr 2023 17:09:04 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v13]
In-Reply-To: <jIQcRcsMGaQR1tXoonjh6m3VPZMulTOpOuQ5243gzpA=.ca37e035-48e3-4138-8678-0f086b102356@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <8nZMhgy4cqZ9-k4BEjz-246NWDuJ5IqxGJs9ym9vdfM=.7c61aea2-3d2c-41c7-a1be-033a3cb66f4b@github.com>
 <jIQcRcsMGaQR1tXoonjh6m3VPZMulTOpOuQ5243gzpA=.ca37e035-48e3-4138-8678-0f086b102356@github.com>
Message-ID: <DdrDm-5uUlx1MvsgmzSxWPaY4DSwZP--SL6U4Z1vn6Y=.87c0b211-439b-4b47-bf4f-7c189f5a7398@github.com>

On Mon, 24 Apr 2023 16:29:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Michael McMahon 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 20 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into auth
>>  - tests all passing now
>>  - tidy up
>>  - Merge branch 'master' into auth
>>  - update
>>  - update
>>  - Merge branch 'master' into auth
>>  - Update src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
>>    
>>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>>  - error in test
>>  - Jai's review
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/60bdee78...93a55fe1
>
> src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheValue.java line 47:
> 
>> 45:      * The default authentication cache
>> 46:      */
>> 47:     protected static final AuthCacheImpl defCache = new AuthCacheImpl();
> 
> Is this still needed?

Right, that is redundant now as the default instance is created in `AuthCacheImpl`. I will remove it.

> src/java.base/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java line 118:
> 
>> 116:     private static NTLMAuthenticationProxy tryLoadNTLMAuthentication() {
>> 117:         Class<? extends AuthenticationInfo> cl;
>> 118:         Constructor<? extends AuthenticationInfo> fourArg, fiveArg;
> 
> Nit: the number of arguments changed again.

Yes, I had changed it to threeArgs and fourArgs but missed that method. Will update and check the copyrights

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1175566678
PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1175569888

From michaelm at openjdk.org  Mon Apr 24 17:22:58 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 24 Apr 2023 17:22:58 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v14]
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <oxexrnx8eROPcYh0Oa9JalYWXwu9Dtwhd0qbT9-v_Pw=.a42ad305-673b-47b8-b394-c0f863271a85@github.com>

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  Dj comments and copyright updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13159/files
  - new: https://git.openjdk.org/jdk/pull/13159/files/93a55fe1..84666287

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13159&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13159&range=12-13

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

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

From djelinski at openjdk.org  Mon Apr 24 17:25:52 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Apr 2023 17:25:52 GMT
Subject: RFR: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected [v14]
In-Reply-To: <oxexrnx8eROPcYh0Oa9JalYWXwu9Dtwhd0qbT9-v_Pw=.a42ad305-673b-47b8-b394-c0f863271a85@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
 <oxexrnx8eROPcYh0Oa9JalYWXwu9Dtwhd0qbT9-v_Pw=.a42ad305-673b-47b8-b394-c0f863271a85@github.com>
Message-ID: <jdqpSTdpT_wNT2bAorqjeF9WtgRyfLW3RcZdp1S9Bgo=.0c5f0e96-8982-42a4-b590-f39963f431da@github.com>

On Mon, 24 Apr 2023 17:22:58 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dj comments and copyright updates

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13159#pullrequestreview-1398491814

From michaelm at openjdk.org  Mon Apr 24 17:29:10 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 24 Apr 2023 17:29:10 GMT
Subject: Integrated: 8304818: Prune HttpURLConnection cache when corresponding
 Authenticator is garbage collected
In-Reply-To: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
References: <yC4jbRTI_FJJVCr0LAEdlvVYQcYd46qdB5zGuG2AHJ4=.667cc821-c4f9-4e6d-9add-3f31157a9dc2@github.com>
Message-ID: <GBoag-Udl7AzoQi4Ylk6XIE3kM2eFgtN2skh42klYOc=.525018a5-d3d9-4b59-ab7e-65f2930eee5b@github.com>

On Thu, 23 Mar 2023 15:47:10 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Can I get a review for this please? This change uses a Cleaner to check when java.net.Authenticator instances become unreachable, and then prunes the authentication cache for entries that correspond to that Authenticator and therefore cannot be used again. This stops the authentication cache from growing in size unbounded. Note, this only happens in the probably unusual case where more than one Authenticator object is used. Normally there is no reason to use more than one instance.
> 
> Thanks,
> Michael.

This pull request has now been integrated.

Changeset: 314db55f
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/314db55f6dde033f62481b62f10dd11030473569
Stats:     891 lines in 18 files changed: 211 ins; 551 del; 129 mod

8304818: Prune HttpURLConnection cache when corresponding Authenticator is garbage collected

Reviewed-by: dfuchs, djelinski

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

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

From dfuchs at openjdk.org  Tue Apr 25 14:09:06 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Apr 2023 14:09:06 GMT
Subject: RFR: 8301169:
 java/net/httpclient/ThrowingSubscribersAsInputStream.java,
 ThrowingSubscribersAsInputStreamAsync.java, 
 and other httpclient tests failing on windows: Unable to establish loopback
 connection
Message-ID: <ehaB7-oo4LS1FCdcZSGYzfxDyenC_x6gzgGeb02wHPE=.00a55a0c-5cc7-4912-ba0c-cfee62de6759@github.com>

The HttpClient Throwing* tests are creating a lot of HttpClient instances and have been observed failing on Windows from time to time with the error:  Unable to establish loopback connection.

To try and mitigate the issue here is a change that will wait for the previous client to be GC'ed before creating the new one. Hopefully that should reduce the cases where these tests fail due to resource exhaustion.

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

Commit messages:
 - 8301169

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

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

From aefimov at openjdk.org  Tue Apr 25 15:07:08 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 25 Apr 2023 15:07:08 GMT
Subject: RFR: 8301169:
 java/net/httpclient/ThrowingSubscribersAsInputStream.java,
 ThrowingSubscribersAsInputStreamAsync.java, 
 and other httpclient tests failing on windows: Unable to establish loopback
 connection
In-Reply-To: <ehaB7-oo4LS1FCdcZSGYzfxDyenC_x6gzgGeb02wHPE=.00a55a0c-5cc7-4912-ba0c-cfee62de6759@github.com>
References: <ehaB7-oo4LS1FCdcZSGYzfxDyenC_x6gzgGeb02wHPE=.00a55a0c-5cc7-4912-ba0c-cfee62de6759@github.com>
Message-ID: <mRYAdQaUu8vQoHeMkb7LjgKRTZ3O1cHT6KEiCCa31nY=.1bbdf91b-0e7d-464b-9dc9-b582e79d6384@github.com>

On Tue, 25 Apr 2023 14:02:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The HttpClient Throwing* tests are creating a lot of HttpClient instances and have been observed failing on Windows from time to time with the error:  Unable to establish loopback connection.
> 
> To try and mitigate the issue here is a change that will wait for the previous client to be GC'ed before creating the new one. Hopefully that should reduce the cases where these tests fail due to resource exhaustion.

LGTM

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

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13644#pullrequestreview-1400137282

From dfuchs at openjdk.org  Tue Apr 25 15:17:07 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Apr 2023 15:17:07 GMT
Subject: RFR: 8301169:
 java/net/httpclient/ThrowingSubscribersAsInputStream.java,
 ThrowingSubscribersAsInputStreamAsync.java, 
 and other httpclient tests failing on windows: Unable to establish loopback
 connection [v2]
In-Reply-To: <ehaB7-oo4LS1FCdcZSGYzfxDyenC_x6gzgGeb02wHPE=.00a55a0c-5cc7-4912-ba0c-cfee62de6759@github.com>
References: <ehaB7-oo4LS1FCdcZSGYzfxDyenC_x6gzgGeb02wHPE=.00a55a0c-5cc7-4912-ba0c-cfee62de6759@github.com>
Message-ID: <pqVt68bGZj_DIQgCXrJc1q_L2gQj9eyRRqHkrPuxoqM=.824ccf9c-a943-4452-a3c6-ed5fa4acaecc@github.com>

> The HttpClient Throwing* tests are creating a lot of HttpClient instances and have been observed failing on Windows from time to time with the error:  Unable to establish loopback connection.
> 
> To try and mitigate the issue here is a change that will wait for the previous client to be GC'ed before creating the new one. Hopefully that should reduce the cases where these tests fail due to resource exhaustion.

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

  Added comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13644/files
  - new: https://git.openjdk.org/jdk/pull/13644/files/62792d05..f84b93bb

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

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

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

From djelinski at openjdk.org  Tue Apr 25 15:17:08 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Apr 2023 15:17:08 GMT
Subject: RFR: 8301169:
 java/net/httpclient/ThrowingSubscribersAsInputStream.java,
 ThrowingSubscribersAsInputStreamAsync.java, 
 and other httpclient tests failing on windows: Unable to establish loopback
 connection [v2]
In-Reply-To: <pqVt68bGZj_DIQgCXrJc1q_L2gQj9eyRRqHkrPuxoqM=.824ccf9c-a943-4452-a3c6-ed5fa4acaecc@github.com>
References: <ehaB7-oo4LS1FCdcZSGYzfxDyenC_x6gzgGeb02wHPE=.00a55a0c-5cc7-4912-ba0c-cfee62de6759@github.com>
 <pqVt68bGZj_DIQgCXrJc1q_L2gQj9eyRRqHkrPuxoqM=.824ccf9c-a943-4452-a3c6-ed5fa4acaecc@github.com>
Message-ID: <rbCCi8H-AE-lg6C0XkbH_Y4OPLGOxciH8fmBcTbKrhM=.199f8012-36bf-4c5e-9944-cae164e45565@github.com>

On Tue, 25 Apr 2023 15:12:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The HttpClient Throwing* tests are creating a lot of HttpClient instances and have been observed failing on Windows from time to time with the error:  Unable to establish loopback connection.
>> 
>> To try and mitigate the issue here is a change that will wait for the previous client to be GC'ed before creating the new one. Hopefully that should reduce the cases where these tests fail due to resource exhaustion.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comments

LGTM.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13644#pullrequestreview-1400151115

From dfuchs at openjdk.org  Tue Apr 25 15:51:40 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Apr 2023 15:51:40 GMT
Subject: Integrated: 8301169:
 java/net/httpclient/ThrowingSubscribersAsInputStream.java,
 ThrowingSubscribersAsInputStreamAsync.java, 
 and other httpclient tests failing on windows: Unable to establish loopback
 connection
In-Reply-To: <ehaB7-oo4LS1FCdcZSGYzfxDyenC_x6gzgGeb02wHPE=.00a55a0c-5cc7-4912-ba0c-cfee62de6759@github.com>
References: <ehaB7-oo4LS1FCdcZSGYzfxDyenC_x6gzgGeb02wHPE=.00a55a0c-5cc7-4912-ba0c-cfee62de6759@github.com>
Message-ID: <n1hDZLe2IJZzt-Hr43vPYuNoTSqwmPsu0z5omz5U8Zo=.305a1e2f-59f8-49d5-833e-2ef6a75738c0@github.com>

On Tue, 25 Apr 2023 14:02:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The HttpClient Throwing* tests are creating a lot of HttpClient instances and have been observed failing on Windows from time to time with the error:  Unable to establish loopback connection.
> 
> To try and mitigate the issue here is a change that will wait for the previous client to be GC'ed before creating the new one. Hopefully that should reduce the cases where these tests fail due to resource exhaustion.

This pull request has now been integrated.

Changeset: 98e8616a
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98e8616a0c27ac73caf8f91cc83adc88b3490dcb
Stats:     108 lines in 3 files changed: 108 ins; 0 del; 0 mod

8301169: java/net/httpclient/ThrowingSubscribersAsInputStream.java,ThrowingSubscribersAsInputStreamAsync.java, and other httpclient tests failing on windows: Unable to establish loopback connection

Reviewed-by: aefimov, djelinski

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

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

From duke at openjdk.org  Tue Apr 25 17:48:10 2023
From: duke at openjdk.org (Dhamoder Nalla)
Date: Tue, 25 Apr 2023 17:48:10 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance
In-Reply-To: <z7BTybOZSsBQQrFx_MgGnaWc1HTrC-sX9PHvnZGIfv8=.ae1b12c5-3432-4ebc-baa2-c6b688fdaa58@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
 <z7BTybOZSsBQQrFx_MgGnaWc1HTrC-sX9PHvnZGIfv8=.ae1b12c5-3432-4ebc-baa2-c6b688fdaa58@github.com>
Message-ID: <gefFeVXa_HrxO6TyD-7G9F-vVgkOY2QoiZmcVIqnhUs=.482a8cfa-686d-441c-b102-e7ba26149d86@github.com>

On Wed, 12 Apr 2023 10:31:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Issue 8305763 : Using underscores in the name for a URI triggers a silent exception in the java standard library, which consumes 5% of the CPU.
>> 
>> Exception:
>> java.net.URISyntaxException: Illegal character in hostname at index N: xyz1_abcd.com
>>     at java.base/java.net.URI$Parser.fail(URI.java:2943)
>>     at java.base/java.net.URI$Parser.parseHostname(URI.java:3487)
>>     at java.base/java.net.URI$Parser.parseServer(URI.java:3329)
>>     
>>     This exception is silent and does not produce any messages, except for ODP profiler, there is no other evidence that it?s happening (the stack trace above was printed after changes to Java library). The reason for this is because of how the URI creation is implemented in the java.net.URI class. There are two paths for creating a valid URI, and one of them goes through an exception.
>> 
>> We can see that if parseServer fails, there is still a way the authority gets assigned and we don?t throw an exception from the method. This means, not being able to parse the server is ok and the exception is silenced. In our case, the server parsing fails because we find an illegal character, as only alphanumeric and dash characters are allowed.
>
> From a quick look at the proposed change, I got the feeling that this change might not be appropriate: I suspect it will let `host` be assigned to the reg_name.
> We want to preserve the long standing behavior that:
> 
> jshell> new URI("http://foo_bar:8080/").getHost()
> $1 ==> null
> 
> Is this still the case after your proposed changes?

Thanks for reviewing @dfuch,
With this change, the below operation returns hostname "foo_bar"

jshell> new URI("http://foo_bar:8080/").getHost()

I will work on addressing this to keep the old behavior unchanged.

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

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

From dfuchs at openjdk.org  Tue Apr 25 18:23:11 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Apr 2023 18:23:11 GMT
Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a
 silent exception, negatively impacting performance
In-Reply-To: <gefFeVXa_HrxO6TyD-7G9F-vVgkOY2QoiZmcVIqnhUs=.482a8cfa-686d-441c-b102-e7ba26149d86@github.com>
References: <R-8rkmjYNi9PHYXJPpp3nRc09kcg-qcpRScNwDyahxQ=.8f0afbff-98bc-4b13-ba18-eb90f2306225@github.com>
 <z7BTybOZSsBQQrFx_MgGnaWc1HTrC-sX9PHvnZGIfv8=.ae1b12c5-3432-4ebc-baa2-c6b688fdaa58@github.com>
 <gefFeVXa_HrxO6TyD-7G9F-vVgkOY2QoiZmcVIqnhUs=.482a8cfa-686d-441c-b102-e7ba26149d86@github.com>
Message-ID: <E2nNyZZOWBxiYzfrvC77SOfUm9JPjZaKQrWARVIk5Us=.fe852045-fc5e-41b5-b933-a6193c1f77af@github.com>

On Tue, 25 Apr 2023 17:45:24 GMT, Dhamoder Nalla <duke at openjdk.org> wrote:

> I will work on addressing this to keep the old behavior unchanged.

Please make sure to run the java/net/URI tests - and when these are successful, tier1, tier2 and tier3.

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

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

From ccleary at openjdk.org  Wed Apr 26 15:00:24 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Wed, 26 Apr 2023 15:00:24 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v5]
In-Reply-To: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
Message-ID: <AnTvwcQqF01yaqL3VS6-1oNtlRBeKncfjiarNm0qDDI=.1d1b7b9c-cfaf-4ef6-b6f7-afad712a576b@github.com>

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

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

  8293786: Handle neg con length and closing bos in handler

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

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

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

  Stats: 83 lines in 4 files changed: 58 ins; 11 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/12694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12694/head:pull/12694

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

From ccleary at openjdk.org  Wed Apr 26 15:00:56 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Wed, 26 Apr 2023 15:00:56 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v4]
In-Reply-To: <Mgn-qzdyDKn85a8WkPFCTKqm0pzbiNqWTlmUJvifVys=.190cf5fa-e197-4b94-a414-493385096b6e@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <p6d4MbKArIpG0X4_gMpsLMA7nr4A6C_L6kzjAV93zKU=.3433ab41-6c54-49a3-a1b0-3e59e77c31a7@github.com>
 <zAofQ8qApMMewmENbyRJFuxvfPxhqovTGJuMPuPgNgM=.63c33609-8e03-4b58-8e72-4aa7ea1fbca8@github.com>
 <Mgn-qzdyDKn85a8WkPFCTKqm0pzbiNqWTlmUJvifVys=.190cf5fa-e197-4b94-a414-493385096b6e@github.com>
Message-ID: <UiU1QdzyEnPSkdxxcWddMRzDRDYcVyeYmkSzijFbMzQ=.e3747f1b-d09a-4a83-bd58-47a2de570762@github.com>

On Mon, 17 Apr 2023 10:28:47 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestServerConnection.java line 737:
>> 
>>> 735:                 // the error code NO_ERROR will be sent to the client before closing.
>>> 736:                 if (bis instanceof BodyInputStream inputStream && (!inputStream.isEof() || inputStream.q.size() > 0)) {
>>> 737:                     bos.sendResetOnClose(ResetFrame.NO_ERROR);
>> 
>> I share @dfuch concern. This line will have no effect if `bos` is already closed at this point. We still need to reset the stream to let the peer know that we won't consume `bis`.
>> (edit) To illustrate that, try changing `PostPutTest.TestHandler.handle` to one of:
>> 
>>             exchange.sendResponseHeaders(200, -1);
>> 
>> or:
>> 
>>             exchange.sendResponseHeaders(200, 0);
>>             exchange.getResponseBody().close();
>> 
>> it will time out again.
>
> Thanks for the feedback Daniel. I see the issue that my implementation causes if the handler closes the `bos` early. Working on this now as a priority, solution will try to make sure that this RST_STREAM is sent even if the handler looks like the example you gave above. Probably worth inluding these handlers as test cases also.

So to address this in the most recent commit, the BodyOutputStream initalised in the try-with-resources block is now passed a reference to the given BodyInputStream and it is used to check if a reset is required there once it is closed. This is done with the following in BodyOutputStream.java:


private boolean resetNeeded() throws IOException {
        return (bis != null && (!bis.isEof() || bis.q.size() > 0));
}


For the `sendResponseHeaders(200, -1)` case, a reset has to be triggered to send instead once the BodyOutputStream is closed at the beginning of the exchange (because of the negative content length).

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

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

From ccleary at openjdk.org  Wed Apr 26 15:04:24 2023
From: ccleary at openjdk.org (Conor Cleary)
Date: Wed, 26 Apr 2023 15:04:24 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v4]
In-Reply-To: <UiU1QdzyEnPSkdxxcWddMRzDRDYcVyeYmkSzijFbMzQ=.e3747f1b-d09a-4a83-bd58-47a2de570762@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <p6d4MbKArIpG0X4_gMpsLMA7nr4A6C_L6kzjAV93zKU=.3433ab41-6c54-49a3-a1b0-3e59e77c31a7@github.com>
 <zAofQ8qApMMewmENbyRJFuxvfPxhqovTGJuMPuPgNgM=.63c33609-8e03-4b58-8e72-4aa7ea1fbca8@github.com>
 <Mgn-qzdyDKn85a8WkPFCTKqm0pzbiNqWTlmUJvifVys=.190cf5fa-e197-4b94-a414-493385096b6e@github.com>
 <UiU1QdzyEnPSkdxxcWddMRzDRDYcVyeYmkSzijFbMzQ=.e3747f1b-d09a-4a83-bd58-47a2de570762@github.com>
Message-ID: <UA9p-nZcbdLelItTgEzDm9ebzLk9wMSXsFmkCbbJ_7U=.5f0c238c-846c-42fd-8e84-00be30f0458a@github.com>

On Wed, 26 Apr 2023 14:51:23 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Thanks for the feedback Daniel. I see the issue that my implementation causes if the handler closes the `bos` early. Working on this now as a priority, solution will try to make sure that this RST_STREAM is sent even if the handler looks like the example you gave above. Probably worth inluding these handlers as test cases also.
>
> So to address this in the most recent commit, the BodyOutputStream initalised in the try-with-resources block is now passed a reference to the given BodyInputStream and it is used to check if a reset is required there once it is closed. This is done with the following in BodyOutputStream.java:
> 
> 
> private boolean resetNeeded() throws IOException {
>         return (bis != null && (!bis.isEof() || bis.q.size() > 0));
> }
> 
> 
> For the `sendResponseHeaders(200, -1)` case, a reset has to be triggered to send instead once the BodyOutputStream is closed at the beginning of the exchange (because of the negative content length).

I could use opinions on the handling of the negative content length (i.e. no content) case. The following code in `Http2TestExchangeImpl.sendResponseHeaders()` handles this and the `rCode == 204` case like so:

        if (responseLength < 0 || rCode == 204) {
            response.setFlag(HeadersFrame.END_STREAM);
            conn.outputQ.put(response);
            conn.outputQ.put(new ResetFrame(streamid, ResetFrame.NO_ERROR));
            os.markClosed();
        } else {
            conn.outputQ.put(response);
        }
        os.goodToGo();
        System.err.println("Sent response headers " + rCode);

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

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

From dfuchs at openjdk.org  Wed Apr 26 16:16:01 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Apr 2023 16:16:01 GMT
Subject: RFR: 8306940: test/jdk/java/net/httpclient/XxxxInURI.java should call
 HttpClient::close
Message-ID: <fmTlzRE-tLY3efYE5JDsi4Fkmd2ZLL3Wzp0HL-mOhz4=.dfd57c84-3103-4868-873e-8ba0413ff5a0@github.com>

The tests test/jdk/java/net/httpclient/*InURI.java create a lot of HttpClient instances.
They should call HttpClient::close when the client is no longer needed.

The fix includes some cleanup of the test code, as well as an additional check on the response version.

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

Commit messages:
 - 8306940

Changes: https://git.openjdk.org/jdk/pull/13673/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13673&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306940
  Stats: 383 lines in 3 files changed: 180 ins; 59 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/13673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13673/head:pull/13673

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

From dfuchs at openjdk.org  Wed Apr 26 16:56:55 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Apr 2023 16:56:55 GMT
Subject: RFR: 8293786: HttpClient will not send more than 64 kb of data
 from the 2nd request in http2 [v5]
In-Reply-To: <AnTvwcQqF01yaqL3VS6-1oNtlRBeKncfjiarNm0qDDI=.1d1b7b9c-cfaf-4ef6-b6f7-afad712a576b@github.com>
References: <ZIXpm1_iPt0jpIA5TmwvJN_BOi5HOD2rfDt2S4Q9zrU=.f3f3c705-753a-482e-9290-bf2e26ec338b@github.com>
 <AnTvwcQqF01yaqL3VS6-1oNtlRBeKncfjiarNm0qDDI=.1d1b7b9c-cfaf-4ef6-b6f7-afad712a576b@github.com>
Message-ID: <5dctVoAItfiCl9MXbdvkdqVMvrqIXzph-lrep-wWhCk=.f5ddbaf4-b8a2-4a01-b550-463a77430f96@github.com>

On Wed, 26 Apr 2023 15:00:24 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

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

test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/http2/Http2TestExchangeImpl.java line 154:

> 152:             response.setFlag(HeadersFrame.END_STREAM);
> 153:             conn.outputQ.put(response);
> 154:             conn.outputQ.put(new ResetFrame(streamid, ResetFrame.NO_ERROR));

This doesn't seem right as reset should not be sent in the general case. Reset should only be sent if there remain data to read and we are unwilling to read it. In other words - this should be handled by closing the exchange (when the exchange is closed).

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

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

From jpai at openjdk.org  Thu Apr 27 01:44:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Apr 2023 01:44:23 GMT
Subject: RFR: 8306940: test/jdk/java/net/httpclient/XxxxInURI.java should
 call HttpClient::close
In-Reply-To: <fmTlzRE-tLY3efYE5JDsi4Fkmd2ZLL3Wzp0HL-mOhz4=.dfd57c84-3103-4868-873e-8ba0413ff5a0@github.com>
References: <fmTlzRE-tLY3efYE5JDsi4Fkmd2ZLL3Wzp0HL-mOhz4=.dfd57c84-3103-4868-873e-8ba0413ff5a0@github.com>
Message-ID: <kU0T7n2HZLdhluakg4O_n8ovDO-wNp-tfAGR2RuTpuo=.cb169ae1-570d-4c89-850c-208b5fd7c69f@github.com>

On Wed, 26 Apr 2023 15:51:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The tests test/jdk/java/net/httpclient/*InURI.java create a lot of HttpClient instances.
> They should call HttpClient::close when the client is no longer needed.
> 
> The fix includes some cleanup of the test code, as well as an additional check on the response version.

Hello Daniel, these changes look fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13673#pullrequestreview-1403049484

From djelinski at openjdk.org  Thu Apr 27 06:29:23 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 27 Apr 2023 06:29:23 GMT
Subject: RFR: 8306940: test/jdk/java/net/httpclient/XxxxInURI.java should
 call HttpClient::close
In-Reply-To: <fmTlzRE-tLY3efYE5JDsi4Fkmd2ZLL3Wzp0HL-mOhz4=.dfd57c84-3103-4868-873e-8ba0413ff5a0@github.com>
References: <fmTlzRE-tLY3efYE5JDsi4Fkmd2ZLL3Wzp0HL-mOhz4=.dfd57c84-3103-4868-873e-8ba0413ff5a0@github.com>
Message-ID: <kX-ECHP2TGO5Et8v1zkUgYkD6FNW1jQT026SaSYBKG4=.43b8a0dc-f402-4146-aa3e-00685c29d507@github.com>

On Wed, 26 Apr 2023 15:51:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The tests test/jdk/java/net/httpclient/*InURI.java create a lot of HttpClient instances.
> They should call HttpClient::close when the client is no longer needed.
> 
> The fix includes some cleanup of the test code, as well as an additional check on the response version.

LGTM.

test/jdk/java/net/httpclient/EscapedOctetsInURI.java line 279:

> 277:         public void handle(HttpTestExchange t) throws IOException {
> 278:             String asciiUriString = t.getRequestURI().toASCIIString();
> 279:             out.println("Http2ASCIIUriString received, asciiUriString: " + asciiUriString);

Suggestion:

            out.println("HttpASCIIUriString received, asciiUriString: " + asciiUriString);

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13673#pullrequestreview-1403268111
PR Review Comment: https://git.openjdk.org/jdk/pull/13673#discussion_r1178671412

From dfuchs at openjdk.org  Thu Apr 27 08:45:25 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Apr 2023 08:45:25 GMT
Subject: RFR: 8306940: test/jdk/java/net/httpclient/XxxxInURI.java should
 call HttpClient::close [v2]
In-Reply-To: <fmTlzRE-tLY3efYE5JDsi4Fkmd2ZLL3Wzp0HL-mOhz4=.dfd57c84-3103-4868-873e-8ba0413ff5a0@github.com>
References: <fmTlzRE-tLY3efYE5JDsi4Fkmd2ZLL3Wzp0HL-mOhz4=.dfd57c84-3103-4868-873e-8ba0413ff5a0@github.com>
Message-ID: <4yvunr9ZJqYpTxRTOoGKqwDzUpWLLEe1Uz_mHHpjHJA=.1252e42a-c643-4846-b4b4-a461f54e55b2@github.com>

> The tests test/jdk/java/net/httpclient/*InURI.java create a lot of HttpClient instances.
> They should call HttpClient::close when the client is no longer needed.
> 
> The fix includes some cleanup of the test code, as well as an additional check on the response version.

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

  Update test/jdk/java/net/httpclient/EscapedOctetsInURI.java
  
  Review suggestion accepted
  
  Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13673/files
  - new: https://git.openjdk.org/jdk/pull/13673/files/9a143f3c..a1988527

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

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

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

From dfuchs at openjdk.org  Thu Apr 27 08:46:23 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Apr 2023 08:46:23 GMT
Subject: Integrated: 8306940: test/jdk/java/net/httpclient/XxxxInURI.java
 should call HttpClient::close
In-Reply-To: <fmTlzRE-tLY3efYE5JDsi4Fkmd2ZLL3Wzp0HL-mOhz4=.dfd57c84-3103-4868-873e-8ba0413ff5a0@github.com>
References: <fmTlzRE-tLY3efYE5JDsi4Fkmd2ZLL3Wzp0HL-mOhz4=.dfd57c84-3103-4868-873e-8ba0413ff5a0@github.com>
Message-ID: <1uZqIorFL0pFAZ_0SRmDPUQBLgiZUt-ClVkFfYJLj1M=.738d032b-0028-41b5-a7a2-79886d8b94f3@github.com>

On Wed, 26 Apr 2023 15:51:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The tests test/jdk/java/net/httpclient/*InURI.java create a lot of HttpClient instances.
> They should call HttpClient::close when the client is no longer needed.
> 
> The fix includes some cleanup of the test code, as well as an additional check on the response version.

This pull request has now been integrated.

Changeset: 41d58533
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41d58533aca29d439db264540e85c4fa165f19f6
Stats:     384 lines in 3 files changed: 180 ins; 59 del; 145 mod

8306940: test/jdk/java/net/httpclient/XxxxInURI.java should call HttpClient::close

Reviewed-by: jpai, djelinski

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

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

From duke at openjdk.org  Thu Apr 27 12:08:53 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Thu, 27 Apr 2023 12:08:53 GMT
Subject: RFR: 8054022: HttpURLConnection timeouts with Expect: 100-Continue
 and no chunking [v3]
In-Reply-To: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
References: <cGqZ9E81bV55OwPtSn-ySd6TY7voy-HU1iM0xuEBXbg=.edf85f76-131a-4739-b089-007a4b0c38d0@github.com>
Message-ID: <9nvO7MHtyoB0Svr_CKsuiofe3hsNI2K9FAuIQBiRDc0=.0f95ab64-70b1-4879-a081-c58066c1f448@github.com>

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

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

  Made the individual variables in Control volatile instead of the class declaration itself

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

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

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

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

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

From michaelm at openjdk.org  Thu Apr 27 14:14:23 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 27 Apr 2023 14:14:23 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v5]
In-Reply-To: <32LnosjQ6BjtjndPmWiXGsnT_M2V23eiKf1g2sf__mM=.f80efa43-d669-4c68-81dc-5db1c3a44d97@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <32LnosjQ6BjtjndPmWiXGsnT_M2V23eiKf1g2sf__mM=.f80efa43-d669-4c68-81dc-5db1c3a44d97@github.com>
Message-ID: <41oJNq2m5C4tJe857tiFnCqn3kzidORfy_l0tsawgBQ=.c1bb39a6-01e3-4ffc-82c5-87280009e60b@github.com>

On Fri, 21 Apr 2023 18:23:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

I think this is a very useful enhancement, and I like the approach. To aid understanding can I suggest renaming a couple of the implementation classes (one already existing) and adding some apidoc as follows. I'd like to spend some more time studying the change also.


/**
 * A cached result of a name service lookup. The result
 * can be either valid addresses or invalid (ie a failed lookup) 
 * containing no addresses
 */
CachedAddresses -> CachedLookup

/**
 * A cached valid lookup containing addresses whose validity
 * may be temporarily extended by an additional stale period
 * pending the mapping being refreshed or updated
 */
ValidAddresses -> ValidCachedLookup

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

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

From serb at openjdk.org  Fri Apr 28 05:59:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Apr 2023 05:59:54 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v5]
In-Reply-To: <32LnosjQ6BjtjndPmWiXGsnT_M2V23eiKf1g2sf__mM=.f80efa43-d669-4c68-81dc-5db1c3a44d97@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <32LnosjQ6BjtjndPmWiXGsnT_M2V23eiKf1g2sf__mM=.f80efa43-d669-4c68-81dc-5db1c3a44d97@github.com>
Message-ID: <pTsfgdt5jcmOmZ6ASjf2ePgV_tMa3Yl_DAmp9kUYXZ8=.2c31165d-b9b7-4be4-9bdf-7305dbfe4a16@github.com>

On Fri, 21 Apr 2023 18:23:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

The comments were updated as requested. I have also merged the master to make sure the GitHub actions will be green.

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

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

From serb at openjdk.org  Fri Apr 28 05:56:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Apr 2023 05:56:53 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v6]
In-Reply-To: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
Message-ID: <cn5Hv_83UMHaoxbUDMBAVNlc3CEPISehmRq90Ap188U=.117f5424-4721-4c30-9112-33aca722b5c1@github.com>

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

Sergey Bylokhov has updated the pull request 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 13 additional commits since the last revision:

 - Merge branch 'master' into JDK-8304885
 - Merge remote-tracking branch 'upstream/master' into JDK-8304885
 - Rename the classes and add the javadoc.
 - Merge branch 'master' into JDK-8304885
 - documentation
 - PR feedback
 - Merge remote-tracking branch 'upstream/master' into JDK-8304885
 - Use "maximum stale timer" instead of the extended timeout, and bump it on each successful lookup
 -  the suggested cap is 7 days
 - simplify
 - ... and 3 more: https://git.openjdk.org/jdk/compare/bcff4747...22a0bd01

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

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

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

  Stats: 41182 lines in 684 files changed: 28291 ins; 8990 del; 3901 mod
  Patch: https://git.openjdk.org/jdk/pull/13285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285

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

From michaelm at openjdk.org  Fri Apr 28 11:15:23 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 28 Apr 2023 11:15:23 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v6]
In-Reply-To: <cn5Hv_83UMHaoxbUDMBAVNlc3CEPISehmRq90Ap188U=.117f5424-4721-4c30-9112-33aca722b5c1@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <cn5Hv_83UMHaoxbUDMBAVNlc3CEPISehmRq90Ap188U=.117f5424-4721-4c30-9112-33aca722b5c1@github.com>
Message-ID: <sNzwfN13nWHfKJfivmmq7WsS_-F7i8IzlLirE9llduc=.086b7f9d-648a-4e2b-913e-d1679e273350@github.com>

On Fri, 28 Apr 2023 05:56:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

src/java.base/share/classes/sun/net/InetAddressCachePolicy.java line 130:

> 128:                 staleCachePolicy = (int) Math.max(tmp, max);
> 129:             }
> 130:         }

Maybe there was discussion of this which I missed, but this seems to be saying if the cache policy is less than seven days, then the stale policy is set no less than seven days. What is the reason for that? I think it would need to be documented if we stick with it.

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

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

From serb at openjdk.org  Fri Apr 28 15:26:23 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Apr 2023 15:26:23 GMT
Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency
 [v6]
In-Reply-To: <sNzwfN13nWHfKJfivmmq7WsS_-F7i8IzlLirE9llduc=.086b7f9d-648a-4e2b-913e-d1679e273350@github.com>
References: <bjqtUuzOzxlzF4bvmuXGMJ1wzAw9m4UdIl8akUrp9G4=.4e99a1fe-f0ce-4756-bc7f-20778c0fd5df@github.com>
 <cn5Hv_83UMHaoxbUDMBAVNlc3CEPISehmRq90Ap188U=.117f5424-4721-4c30-9112-33aca722b5c1@github.com>
 <sNzwfN13nWHfKJfivmmq7WsS_-F7i8IzlLirE9llduc=.086b7f9d-648a-4e2b-913e-d1679e273350@github.com>
Message-ID: <HD0R3rRJ78heAbPdJHzORwwg8VcSNorZn2rtcvydA6c=.f8e0143a-d799-453e-a122-ca82960cdfa1@github.com>

On Fri, 28 Apr 2023 11:00:31 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8304885
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8304885
>>  - Rename the classes and add the javadoc.
>>  - Merge branch 'master' into JDK-8304885
>>  - documentation
>>  - PR feedback
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8304885
>>  - Use "maximum stale timer" instead of the extended timeout, and bump it on each successful lookup
>>  -  the suggested cap is 7 days
>>  - simplify
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/0f472c3b...22a0bd01
>
> src/java.base/share/classes/sun/net/InetAddressCachePolicy.java line 130:
> 
>> 128:                 staleCachePolicy = (int) Math.max(tmp, max);
>> 129:             }
>> 130:         }
> 
> Maybe there was discussion of this which I missed, but this seems to be saying if the cache policy is less than seven days, then the stale policy is set no less than seven days. What is the reason for that? I think it would need to be documented if we stick with it.

It is come from the recommendation in the "RFC 8767" see the notion about "cap of 7 days":
https://www.rfc-editor.org/rfc/rfc8767
Depending on the final implementation I can document this, or delete it in the code.

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

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