Shawn,
On 5/30/22 10:05, Shawn Heisey wrote:
On 5/30/2022 7:06 AM, Shawn Heisey wrote:
What version of SolrJ are you using in your code? For a long time,
SolrJ defaulted to an HttpClient that only allowed two threads per
destination. Then that was greatly increased. Now from what I can
decipher in current 8.x code using the Builder, we may be back to a
default of two connections per destination, which is NOT a good thing
when concurrency is expected.
From what I can decipher, Http2SolrClient may default to a max thread
pool size of 256.
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.
That might be a low number for HIGHLY concurrent
systems, but it should be a lot better than HttpSolrClient. And I see
that others have recommended using it. It also looks like the Builder
for that client lets you easily set the maximum number of connections
per host. From what I can tell, if you allow it to use http/2 it will
not honor max connections per host, but I do not think that's a problem,
as http/2 multiplexes many requests over a single connection. A
well-optimized http/2 setup really only needs one TCP connection for all
concurrent activity.
Yes. An h2 server can limit the number of simultaneous requests per
connection, but theoretically its quite high.
I do think that the http2 client builder should allow setting the max
size of the thread pool. But maybe its defaults will serve you well
until that happens.
Still seems weird to me.
-chris
