Hi Oleg, > The classic (blocking) HttpClient does not maintain its own pool of execution > threads at all. Thread creation and management is entirely up to you.
--> I understand. Then if I'm executing the following code in a tomcat virtual thread, where ' httpClient' is a CloseableHttpClient: DocOutput output =httpClient.execute(httpMethod, context, new ServerHttpResponse()); This "blocking" execute method will free the OS thread that is managing the VT while no data is read from the backend, simply because you are using structures (socket, input/output streams) that inherently release the OS thread in java versions >= 21. Am I right? Thanks as usual, Joan. -----Original Message----- From: Oleg Kalnichevski <ol...@apache.org> Sent: Friday, January 10, 2025 2:41 PM To: HttpClient User Discussion <httpclient-users@hc.apache.org> Subject: Re: httpclient 5.4.1 with java >= 21 On Fri, 2025-01-10 at 09:04 +0100, joan.balagu...@ventusproxy.com wrote: > Hi Oleg, > > We are going to try 5.4.1 with java24 and check the virtual threads > performance. Just a couple of questions: > > 1. To make use of VT, do we need to enable some flag (like we do in > tomcat with "useVirtualThreads=true" in the http connector)? Or simply > using the classic (blocking) connection management APIs is enough to > automatically make use of VT if we are in a java version >= 21? > Hi Joan The classic (blocking) HttpClient does not maintain its own pool of execution threads at all and async HttpClient runs a very small pool of i/o dispatch threads (one per CPU core). Thread creation and management is entirely up to you. This is of course different from the server side message processing that usually involves a dedicated pool of worker threads. > 2. If I'm not wrong, I remember the classic pool has a global lock to > control the max connections in use. I think you created the LAX mode > to mitigate some contention on this pool due to this global lock. Due > to our internal implementation, we will need to control the number of > requests sent to the backend by ourselves with a semaphore or an > atomic counter or whatever ... If we want to completely remove the use > of this lock, is it enough by setting the maxConnections to 0 (no > matter if we are using the strict or lax mode)? > I suppose setting maxConnections to 0 would render the pool non- functional. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
