Hi Tim, thanks for letting me know, I experienced the same problem, my application became unstable and crashed. My first implementation was very similar to yours and relied heavily on try-with-resources java statements with CloudSolrClient. As said in my previous email, I ended up using the solr clients as singletons reusing one instance per solr instance/collection.
On Mon, Aug 28, 2023 at 1:48 PM Tim Funk <funk...@apache.org> wrote: > I reverted to HttpSolrClient. That seems to have plugged the leak. > As for root cause, I haven't had time to dig farther. Since this happens > regardless of reusing SolrClient vs instantiating a new one, I'm hoping > that's a data point of interest. But as for constructing a "simple" test > to reproduce, I'm not sure if I'll find the time in the near future to do > other $work priorities. > > As for future triage, I'd try the any of the following > - Change my endpoint and use Http2 ( disable: builder.useHttp1_1(true)) > - Revert to Http2Client and add a timer / logger in existing apps servers > counting threadlocals and look for patterns > - Write a standalone client, single thread. See if I can count the > threadlocals over time. > - Write a standalone client - Make all executions in new different threads > with occasional reuse of thread > > -Tim > > > On Mon, Aug 28, 2023 at 7:17 AM Vincenzo D'Amore <v.dam...@gmail.com> > wrote: > > > 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. > > > > > > > > -- Vincenzo D'Amore
