> An experimental change to SelectorManager::shutdown unveil 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.
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 two additional commits since the last revision: - Merge branch 'SelectorManagerVT-8372159' into ConnectionCloseLock-8372198 - 8372198: Avoid closing PlainHttpConnection while holding a lock ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28421/files - new: https://git.openjdk.org/jdk/pull/28421/files/177e7ee3..97ce3737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=00-01 Stats: 19751 lines in 348 files changed: 10987 ins; 5712 del; 3052 mod Patch: https://git.openjdk.org/jdk/pull/28421.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28421/head:pull/28421 PR: https://git.openjdk.org/jdk/pull/28421
