Open pintomau opened 9 months ago
We didn't experiment yet with virtual threads.
When I remember it right the executor wasn't forwarded to the OkHttp dispatcher for backwards compatibility reasons as it potentially would have changed the behavior.
In case you want to forward the executor to OkHttp use one of the methods with the maxRequest arguments or rebuild the functionality
ExecutorService executor = ForkJoinPool.commonPool();
final okhttp3.Dispatcher dispatcher = new okhttp3.Dispatcher(executor);
dispatcher.setMaxRequests(CtOkHttp4Client.MAX_REQUESTS);
dispatcher.setMaxRequestsPerHost(CtOkHttp4Client.MAX_REQUESTS);
new CtOkHttp4Client(executor, builder -> builder.dispatcher(dispatcher));
Besides you should load test any changes to the default executor as OkHttp by default instantiates an unbound ThreadPool executor with a SynchronousQueue.
Hey.
We're evaluating the usage of Virtual Threads with
Executors.newVirtualThreadPerTaskExecutor();
.I've noticed that there's an inconsistency in the usage of
ExecutorService executor
inCtOkHttp4Client
:The second constructor doesn't reuse the passed
executorService
when creating the dispatcher, while all others that get the same argument do.It just so happens that this one would be the ideal one for us 🤠.
Is there a reason for this, or is it an oversight?
Besides this, any thoughts or recommendations on using the Virtual Threads executor with the SDK? Maybe you've already done experimenting on your end? Is the SDK prone to Thread Pinning?
Thanks.