Hi Tim, have you figured out the problem? Just curious to know what you have done at the end.
On Fri, Aug 25, 2023 at 4:48 PM Vincenzo D'Amore <v.dam...@gmail.com> wrote: > 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. >> >> >> >> >> > -- Vincenzo D'Amore
