RFR: 8308310: HttpClient: Avoid logging or locking from within synchronized blocks [v8]

[Daniel Fuchs]

On Wed, 24 May 2023 11:48:06 GMT, Jaikiran Pai <jpai at openjdk.org> 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 <turbanoff at gmail.com>
>>  - Update src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - Update test/jdk/java/net/httpclient/AuthFilterCacheTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - ... 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