Thanks for all your advices! We will track this further down by either switching to 8.11/9 and/or switch to Http2SolrClient or (as a first try) apply Jan's approach of injecting a "preconfigured httpClient".
Final solution will be 9.0 using Http2SolrClient (with, if necessary, additional connections 😉) Regards -Clemens -----Ursprüngliche Nachricht----- Von: Shawn Heisey <[email protected]> Gesendet: Montag, 30. Mai 2022 16:06 An: [email protected] Betreff: Re: SolrJ connection handling, best practice(s)? [Sie erhalten nicht oft eine E-Mail von [email protected]. Weitere Informationen dazu, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification.] 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. 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. 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. Thanks, Shawn
