On 5/31/2022 9:36 AM, Christopher Schultz wrote:
Thread pool or connection pool? Usually, you want your application
threads to be waiting on that data, not handing execution off to
another thread, only to wait for it to complete. Any asynchronous
environment should be providing its own threads. I would find it very
surprising if the Solr client provided a thread pool internally.
HttpSolrClient uses Apache httpclient, version 4.5. Http2SolrClient uses
the Jetty http client.
The Apache httpclient defaults to only allowing two simultaneous
connections. At one point, HttpSolrClient was improved to build a
client that allows more connections, but it looks like that got lost in
the conversion to the Builder paradigm, so now we are back to only
having two by default.
This code is in the method that actually creates Http2SolrClient:
ThreadPoolExecutor httpClientExecutor = new
ExecutorUtil.MDCAwareThreadPoolExecutor(32,
256, 60, TimeUnit.SECONDS, queue, new
SolrNamedThreadFactory("h2sc"));
And then that executor is used in the actual httpClient creation.
I'm looking at the createHttpClient method in Http2SolrClient.java in
branch_8_11 from the lucene-solr repo.
Thanks,
Shawn