> Each HttpClient instance creates an additional platform thread for its 
> SelectorManager. With recent updates to NIO/VirtualThreads that thread could 
> now become a VirtualThread. This would avoid having each HttpClient instance 
> use up one platform thread.
> This is similar to what was done for the HttpClient QuicSelectorThread in 
> [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
> This should be transparent for users of the API. 
> An undocumented internal system property is introduced that can revert the 
> change in case of unforeseen trouble.

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 five additional commits since 
the last revision:

 - Merge branch 'master' into SelectorManagerVT-8372159
 - Copyright years
 - Review feedback on test
 - Revert changes to SelectorManager::shutdown
 - 8372159: HttpClient SelectorManager thread could be a VirtualThread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28395/files
  - new: https://git.openjdk.org/jdk/pull/28395/files/371dfced..d082d909

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=03-04

  Stats: 19751 lines in 348 files changed: 10987 ins; 5712 del; 3052 mod
  Patch: https://git.openjdk.org/jdk/pull/28395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28395/head:pull/28395

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

Reply via email to