You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: