RFR: 8297200: java/net/httpclient/SpecialHeadersTest.java failed once in AssertionError due to selector thread remaining alive [v5]

[Jaikiran Pai]

On Mon, 28 Nov 2022 17:57:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/SpecialHeadersTest.java test has been observed failing once, due to a selector thread still running after all operations had terminated. This change slightly alter the test logic to check the shared client only at the end of the test when all methods have been executed, and focussed the checks performed by a test method to the only clients that this method is using. This may or may not prevent the observed issue to ever reproducing, but should at least provide more information on where the selector manager thread is at the time it is observed running, should the test fail again:
>> the logic of the HttpClient should have woken up the selector when the last operation finished, which should have ensured a prompt termination of the thread.
>> In addition this change fixes a small race condition in the logic that attempts to decide if the selector is still alive: the selector should be considered alive until its run() method has been called and has exited (or Thread::start has thrown).
>
> 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 seven additional commits since the last revision:
> 
>  - Merge branch 'master' into SpecialHeadersTest-8297200
>  - thrown should be thrown
>  - Merge branch 'master' into SpecialHeadersTest-8297200
>  - Update test/jdk/java/net/httpclient/ReferenceTracker.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Fixed race condition in detecting if selector is still alive
>  - 8297200
>  - 8297200

Hello Daniel,

> What I could see from the log - and that was enough to understand the issue, is that the test observed "alive" being false, so decided that it didn't need to wait, then immediately after saw "alive" being true - and handled that is if alive was observed after the timeout had expired - when it had waited 0ms for the thread to shutdown.

Thank you for that detail - that makes sense and answers the questions I had. I didn't notice that the tracker could completely skip the wait and then do an additional check which could trigger the failure. In context of this, what you propose for keeping track of start state of the selector manager looks good to me.

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

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