On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
> Hi, please find here a patch that solves a rare intermittent test failure
> observed in the test `java/net/httpclient/ExecutorShutdown.java`
>
> A race condition coupled with some too eager synchronization was causing a
> deadlock between an Http2Connection close, a thread trying to shutdown the
> HttpClient due to a RejectedTaskException, and the SelectorManager thread
> trying to exit.
>
> The fix comprises several cleanup - in particular:
>
> - `Http2Connection`: no need to try to send a `GOAWAY` frame if the
> underlying TCP connection is already closed
> - `SSLFlowDelegate`/`SubscriberWrapper`: no need to trigger code that will
> request more data from upstream if the sequential scheduler that is supposed
> to handle that data once it arrives is already closed
> - `Http1Exchange`/`Http1Request`: proper cancellation of subscription if an
> exception is raised before `onSubscribe()` has been called
> - `HttpClientImpl`: avoid calling callbacks from within synchronized blocks
> when not necessary
> - `ReferenceTracker`: better thread dumps in case where the selector is still
> alive at the end of the test (remove the limit that limited the stack traces
> to 8 element max by no longer relying on `ThreadInfo::toString`)
src/java.net.http/share/classes/jdk/internal/net/http/common/SSLFlowDelegate.java
line 784:
> 782:
> 783: while (Utils.synchronizedRemaining(writeList) > 0 ||
> hsTriggered() || needWrap()) {
> 784: if (scheduler.isStopped()) return;
If the `scheduler` is stopped then would this task instance be ever called
again? If it won't be called again, then do you think we should perhaps drain
the queued `writeList` to reduce any memory resource accumulation till the next
GC cycle?
-------------
PR: https://git.openjdk.java.net/jdk/pull/8562
