An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool. This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test. To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock. This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421 ------------- Depends on: https://git.openjdk.org/jdk/pull/28395 Commit messages: - 8372198: Avoid closing PlainHttpConnection while holding a lock Changes: https://git.openjdk.org/jdk/pull/28430/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372198 Stats: 48 lines in 3 files changed: 23 ins; 9 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/28430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430 PR: https://git.openjdk.org/jdk/pull/28430
