On Fri, 2025-01-10 at 15:21 +0100, joan.balagu...@grupoventus.com wrote: > 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? >
I must admit I do not know how exactly VTs are expected to behave but I am sure when running in a VT HttpClient should play nicely with the VM thread management. Oleg > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
