Re: Dozens of "HttpClient-N-SelectorManager" threads created

[Bernd]

You Can take an Heap dump and Check how many selectormanager Instances you have and who own them. Maybe you had close/reconnects or Deal with multiple Class Loaders?

Gruß

Bernd

--

http://bernd.eckenfels.net

 

---

Von: net-dev <net-dev-r...@openjdk.org> im Auftrag von Ruslan Ibragimov <rus...@heapy.io>
Gesendet: Donnerstag, Januar 23, 2025 7:59 PM
An: net-dev@openjdk.org <net-dev@openjdk.org>
Betreff: Dozens of "HttpClient-N-SelectorManager" threads created

 

I encounter strange behavior of java.net.http.HttpClient in my application running in amazoncorretto:17.0.13, after some time instead of just one HttpClient-1-SelectorManager thread I'm starting observing dozens of such threads.

I'm creating only one instance of HttpClient in whole application, and confirming with logging that following snippet called only once:

val httpClient = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_2)
    .followRedirects(HttpClient.Redirect.NEVER)
    .connectTimeout(Duration.ofSeconds(60))
    .build()

I also verified that no dependencies using HttpClient under the hood.

"HttpClient-18-SelectorManager" #20791 daemon prio=5 os_prio=0 cpu=31.77ms elapsed=3679.62s allocated=178K defined_classes=0 tid=0x00007f212c5dfce0 nid=0x541f runnable  [0x00007f21993ee000]
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.EPoll.wait(java.base@17.0.13/Native Method)
	at sun.nio.ch.EPollSelectorImpl.doSelect(java.base@17.0.13/EPollSelectorImpl.java:118)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@17.0.13/SelectorImpl.java:129)
	- locked <0x000000008c488e38> (a sun.nio.ch.Util$2)
	- locked <0x000000008c488de8> (a sun.nio.ch.EPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.select(java.base@17.0.13/SelectorImpl.java:141)
	at jdk.internal.net.http.HttpClientImpl$SelectorManager.run(java.net.http@17.0.13/HttpClientImpl.java:894)

   Locked ownable synchronizers:
	- None

So now I'm in situation when I see a lot (a few times they grow to 150+ threads) of such threads created over time and stay alive. I believe it's also hurting application performance which lead even to timeouts on http stack (but this is unconfirmed).

Any hint to understand why this might happen and how to debug root cause would be appreciated.

--

Best regards,

Ruslan Ibragimov

https://heapy.io/

--

http://bernd.eckenfels.net