[
https://issues.apache.org/jira/browse/SOLR-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15546859#comment-15546859
]
Hoss Man commented on SOLR-9182:
--------------------------------
bq. ...it's questionable when to evict that context from cache...
If you now have a reproducible test that verifies if/when connections are
getting re-used by inspecting the PoolStats from the
PoolingHttpClientConnectionManager, then perhaps we don't need to a (solrj
coded/managed) cache of HttpClientContexts at all? ... why not revisit alan's
earlier patch of setting some simple singleton token so that the
ConnectionManager knows *every* request it gets can re-use the same connections
.. and then let the test verify that the ConnectionManager actually does that
for us.
or am i missunderstanding the root cause?
> Test OOMs when ssl + clientAuth
> -------------------------------
>
> Key: SOLR-9182
> URL: https://issues.apache.org/jira/browse/SOLR-9182
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Attachments: DistributedFacetPivotLongTailTest-heapintro.png,
> SOLR-9182.patch, SOLR-9182.patch, SOLR-9182.patch
>
>
> the combination of SOLR-9028 fixing SSLTestConfig to actually pay attention
> to clientAuth setting, and SOLR-9107 increasing the odds of ssl+clientAuth
> being tested has helped surface some more tests that seem to fairly
> consistently trigger OOM when running with SSL+clientAuth.
> I'm not sure if there is some underlying memory leak somewhere in the SSL
> code we're using, or if this is just a factor of increased request/response
> size when using (double) encrypted requests, but for now I'm just focusing on
> opening a tracking issue for them and suppressing SSL in these cases with a
> link here to clarify *why* we're suppressing SSL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
