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

[Daniel Fuchs]

On Mon, 28 Nov 2022 15:47:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Coming to the part `#1` change - so it appears that we now maintain a state if the selector manager thread doesn't start (i.e. fails in the rare case where `Thread.start()` throws Exception). We consider the selector manager to be alive in such cases. But this "aliveness" is only used for reference tracking. I think, if the selector manager thread has failed to start, that would mean the `HttpClient` instance cannot function, isn't it? But as far as I can see it wouldn't start throwing up errors but would silently accumulate requests (I'm using the term `requests` loosely here, but I mean the internal `AsyncEvent` instances). Did I read the code correctly? If so, should we be somehow propagating this thread start failure as actual exceptions whenever requests are issued?

We don't consider the thread to be alive in this case, but we will consider that it has started. The combination started=true and alive=false means that it has finished running (in this degenerative case it has never run - as if run() had been a no-op)

start() is called from within the HttpClientImpl constructor, so if Thread::start fails I don't think it will be possible to get such a client - since the constructor will throw.  So it doesn't matter much anyway.

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

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