[
https://issues.apache.org/jira/browse/SOLR-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15543657#comment-15543657
]
Alan Woodward commented on SOLR-9182:
-------------------------------------
[~hossman] I meant that even with RandomizeSsl set to always use both ssl and
clientAuth, I still don't see the piling up of available connections when I run
the test on my Mac. No idea why.
[~mkhludnev] As far as I can tell from spelunking the HttpClient source, the
user-token key can be anything you like, it's just an object passed to the
CPool when retrieving connections, which is why I tried using a static
constant. Your method looks safer though.
As for testing, this is a bit of a pain as it appears there's no easy way of
getting access to the internal PoolStats object that tells you how many
connections are hanging around. You can't even use reflection, because
BasicHttpClient wraps things in an anonymous class
> 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
>
>
> 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]
