[ https://issues.apache.org/jira/browse/SOLR-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Woodward updated SOLR-9604: -------------------------------- Attachment: SOLR-9604.patch Patch, based on [~mkhludnev]'s last patch on SOLR-9182. There are a few other places in addition to HttpSolrClient that need an HttpClientContext, so I added a cacheKey object to the context factory. HttpSolrClient can pass itself, as can ConcurrentUpdateSolrClient. The UpdateHandler client uses its parent CoreContainer as a key. It may make sense to allow users to pass in cache keys as well, particularly for CUSC, which is used by DistributedUpdateProcessor, and can share connection pools with other clients in a container. > Pooled SSL connections are not being reused with client authentication > ---------------------------------------------------------------------- > > Key: SOLR-9604 > URL: https://issues.apache.org/jira/browse/SOLR-9604 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Alan Woodward > Assignee: Alan Woodward > Attachments: SOLR-9604.patch > > > Solr isn't setting user tokens on any of its HttpClientContext objects when > requested new http connections. This means that when SSL + client > authentication is used, HttpClient is creating a new connection on every > request, to ensure that authentication tokens aren't shared between different > users. We end up with lots of unused open connections in the connection > pool, leading to slowness and out-of-memory errors. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org