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. >> >>
