[
https://issues.apache.org/jira/browse/SOLR-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-9182:
-----------------------------------
Attachment: SOLR-9182.patch
[^SOLR-9182.patch] reproduces the "leak".
java.lang.AssertionError: oh \[leased: 0; pending: 0; available: 5000; max:
10000] expected:<1> but was:<5000>
at ...
at org.junit.Assert.assertEquals(Assert.java:472)
at
org.apache.solr.client.solrj.impl.HttpSolrClientSSLAuthConPoolTest.testPoolSize(HttpSolrClientSSLAuthConPoolTest.java:52)
It's worth to add more (probably concurrent) testing and hit few entpoints.
it's questionable when to evict that context from cache, now it's happen on any
exception, but there is no test coverage. Do "http routes" might mess something
with those contexts and Principals??
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
