[
https://issues.apache.org/jira/browse/SOLR-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549309#comment-15549309
]
Hoss Man commented on SOLR-9604:
--------------------------------
bq. also, it's worth to remove @RandomSSL from HttpSolrClientSSLAuthConPoolTest
to make it really random.
bq. I think it's worth keeping the RandomizeSSL annotation on this test
though, as it's only really applicable to SSL+clientAuth situations.
Agreed, but I think I also see Mikhail's point: from a coverage standpoint, it
would be nice to have a test that helps ensure we are re-using connection pools
*regardless* of whether SSL+clientAuth is used or not (ie: as the test stands
now, we only ensure they are re-used with SSL, some future bug could break
connection re-use for non-ssl connections and we'd never know -- heck: in
theory the changes in this fix for SSL connection reuse could be breaking
connection reuse for non-SSL requests, and we wouldn't know it.)
So perhaps refactor the current {{HttpSolrClientSSLAuthConPoolTest}} class into
a {{HttpSolrClientConPoolTest}} that uses the default SSL randomization, and
then make {{HttpSolrClientSSLAuthConPoolTest}} a subclass that forces
{{\@RandomizeSSL(1.0)}} ?
(along with a "test the test" sanity assertion that the urls start with "https")
> 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-9604.patch, fails with null.png
>
>
> 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
