Cool - For now I'll either revert to HttpSolrClient or use a single client (depending on what I have to refactor)
My only concern with a shared client is if one calls close() "accidently", i don't see an easy way to query the client to see if it was closed so I can destroy it and create a new one. (Without resorting to an webapp restart) -Tim On Tue, Aug 22, 2023 at 6:42 PM Shawn Heisey <apa...@elyograg.org> wrote: > > That kind of try-with-resources approach should take care of the > problem, because it would run the close() method on the SolrClient object. > > The classes in the error are Jetty classes. This probably means that > the problem is in Jetty, but I couldn't guarantee that. > > You do not need multiple client objects just because you have multiple > cores. You only need one Http2SolrClient object per hostname:port > combination used to access Solr, and you should only need to create them > when the application starts and close them when the application ends. > > One thing I found about Http2SolrClient compared to HttpSolrClient: The > latter creates the inner http client threads as Daemon threads, so they > are automatically cleaned up by Java. The former doesn't. Here's some > code to change the Http2SolrClient creation so that it creates the > internal jetty http client threads as Daemon threads: > >
