> 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

Daniel Fuchs has updated the pull request incrementally with one additional 
commit since the last revision:

  More test updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28430/files
  - new: https://git.openjdk.org/jdk/pull/28430/files/56643d23..5bbe9042

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=05-06

  Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 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

Reply via email to