Just my 2 cent:, I have always used solr clients as singletons. You have to instantiate them only once and reuse them forever.
On Fri, 25 Aug 2023 at 15:35, Tim Funk <funk...@apache.org> wrote: > Update - It looks like the ThreadLocal leak is different and unrelated to > creating / closing a new Http2SolrClient every request. Even using a > shared > Http2SolrClient for my webapp - I noticed the same issue in a QA > environment > of leaking ThreadLocals. Falling back to HttpSolrClient optimistically is > the fix so far. > > Client is OpenJDK 11.0.17 > > -Tim > > On Wed, Aug 23, 2023 at 9:46 AM Tim Funk <funk...@apache.org> wrote: > > > 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. > >> > >> >
