Thank you for the clarifications, it was helpful. Did I understand you correctly that from the point of view of I/O in HTTP/1.1, synchronous and asynchronous clients are identical? The main difference is the API: asynchronous uses a reactor, while synchronous uses a threading model.
-----Original Message----- From: Oleg Kalnichevski <ol...@apache.org> Sent: Monday, August 5, 2024 7:30 PM To: HttpClient User Discussion <httpclient-users@hc.apache.org> Subject: Re: Virtual Threads vs Async Http Client On Mon, 2024-08-05 at 13:43 +0000, Олег В. Кандауров wrote: > Hi! > > I have a question regarding the use of Virtual Threads. > I understand that migrating to Java 21 is impossible due to the many > clients using older versions of Java. HttpClient is going to remain Java 1.8 compatible in the foreseeable future. This, however, does not prevent one from making use of virtual threads. HttpClient code base has been revised and made compatible with Java 21 and virtual threads as of version 5.4. One can use its functionality from virtual threads or provide a custom ThreadFactory configured to spawn virtual threads where supported by HttpClient APIs. HttpClient 5.4 is still considered BETA but GA should be coming out in September. > I saw that in previous discussions it was mentioned that Virtual > Threads can be useful for HTTP/2. > But what about HTTP/1.1? > I have not done any performance testing with Java 21 yet but if one needs thousands of concurrent connections virtual threads may help. > We use Async Http Client in cases where it is necessary to interact > with thousands of unstable partner systems. > Such systems can respond slowly and thus exhaust the pools of the > standard http client and engage a huge number of threads. > Using the asynchronous http client solved our problems. > > Now there is a task to switch all such interactions throughout the > system to the asynchronous http client. > Due to the fact that the API of the synchronous and asynchronous > clients is different, the task seems extensive. > > Therefore, I would prefer not to migrate all interactions to the > asynchronous http client, but instead configure the standard Http > client to use Virtual Threads in a special way. > > I am not very familiar with the internal architecture of the Http > Client, but are there any extension points where > Executors.newVirtualThreadExecutor could be used, or some other way to > benefit from virtual threads? With the classic APIs the caller manages worker threads [1]. There is nothing stopping one from using virtual threads to execute requests. > If this is possible, would this approach become an alternative to the > asynchronous http client in the future? The classic APIs will likely remain recommended for most of application scenarios that do not require HTTP/2 Hope this helps Oleg [1] https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientMultiThreadedExecution.java --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
