On Wed, 24 May 2023 11:48:06 GMT, Jaikiran Pai <[email protected]> wrote:
>> Daniel Fuchs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 11 commits: >> >> - Merge branch 'master' into HttpClient-Logging-8308310 >> - Merge branch 'master' into HttpClient-Logging-8308310 >> - Fix whitespace >> - make stateLock final >> - Add debug traces to ExpectContinueTest.java >> - failedRef should be final >> - Align parameters >> - Update >> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java >> >> Co-authored-by: Andrey Turbanov <[email protected]> >> - Update >> src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java >> >> Co-authored-by: Andrey Turbanov <[email protected]> >> - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java >> >> Co-authored-by: Andrey Turbanov <[email protected]> >> - ... and 1 more: https://git.openjdk.org/jdk/compare/c0c4d771...c5d2f1f2 > > test/jdk/java/net/httpclient/ManyRequests.java line 274: > >> 272: } catch (CompletionException e) { >> 273: if (!Platform.isWindows()) throw e; >> 274: if (LIMIT.get() < MAX_LIMIT) throw e; > > Previously, `LIMIT.get()` was being compared against `MAX_COUNT`, because > `REQUEST` was initialized (as `final`) to that value. Now it's being compared > to `MAX_LIMIT`. Is this intentional? Yes. I think the previous behaviour was buggy. The idea is to reduce concurrency if the underlying OS has trouble with too many concurrent connections. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14038#discussion_r1204046449
