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() ?
>

Reply via email to