End of message is the getSolrClient() . (We have a different core per language). Also using http 1_1 since we have apache(http) reverse proxy in front of solr in non-prod tiers and haproxy load balancing in production.
As I was testing earlier (after initial question), there doesn't seem to be a leak in close(). It seems time out is deeper in the core. I reached that conclusion via hitting my app instance with `ab -n 5000000 -c 200` and other random hits. Then on app restart, I saw in the logs just 3 ThreadLocal leaks attributed to that webapp with the MonoEntry signature in the log. I did refactor a different app (since it was smaller) to share a single SolrClient and did the same amount of pound of traffic and didn't see the leak error message for that app. public SolrClient getSolrClient(String locale) { Http2SolrClient.Builder builder = null; try { String baseUrl = "http://"+solrHost+":"+solrPort+"/solr/" + getSolrCore(locale); builder = new Http2SolrClient.Builder(baseUrl); if (StringUtil.hasText(solrUser)) { builder = builder.withBasicAuthCredentials(solrUser, solrPassword); } builder.useHttp1_1(true); return builder.build(); } catch (Exception e) { log_.fatal("error getting client", e); } return null; } On Tue, Aug 22, 2023 at 2:45 PM Chris Hostetter <hossman_luc...@fucit.org> wrote: > > I suspect the source of this problem is either something low level in the > jetty HttpClient cleanup code ( which Solr should should already be > correctly cleaning up on Http2SolrClient.close() ) or it's some nuance of > how your 'createSolrClient()' method is impleemnted that creates an edge > case preventing 'Http2SolrClient.close()' from doing a full cleanup of the > underlying HttpClient. > > can you please share the details of createSolrClient() ? >