[
https://issues.apache.org/jira/browse/SOLR-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-9040:
---------------------------
Attachment: SOLR-9040.patch
Here's a really hacked together patch that gets things working again.
The root problem is that the (default) SchemaRegistryProvider in HttpClientUtil
is hardcoded to only know about http. With the older style
HttpClientConfigurer code in SolrCLI pre-SOLR-4509, the default behavior of
HttpClientUtil came from DefaultHttpClient and automatically included http &
https protocols, using the various javax system properties (for things like
keystore & truststore)
In this patch, i eliminate the hardcoded default behavior of only supporting
"http" in HttpClientUtil and instead changed the Registry returned by the
default SchemaRegistryProvider to "null", with caller coded updated to know
that if/when the result is null, they should use the no-arg {{new
PoolingHttpClientConnectionManager()}} constructor, instead of {{new
PoolingHttpClientConnectionManager(reg)}} -- because unfortunately
PoolingHttpClientConnectionManager doesn't provide public access to it's
default registry.
This seems to work in my manual testing - still running full test suite, but
because of SOLR-9028 I don't have a whole lot of confidence even if the tests
do all pass. i have some ideas of how to write an explicit test for this bug,
but it will probably require most of the changes in SOLR-9028 as well, so we
may just want to roll these bugs together?
The big question is what the final API should look like -- whether
{{HttpClientUtil.getSchemaRegisteryProvider().getSchemaRegistry()}} should
return null when this default behavior is desired, or if
{{HttpClientUtil.getSchemaRegisteryProvider()}} should return null directly ...
also: should the conditional instantiation of
PoolingHttpClientConnectionManager be rolled into a public method in
HttpClientUtil so it isn't duplicated in UpdateShardHandler (and any other
client that wantsSchemaRegistryProvider to customize the connection manager)
... and more generally: WTF is up with the {{SchemaRegistryProvider}} API
anyway? why is it a distinct class with distinct setters in HttpClientUtil,
instead of being part of SolrHttpClientBuilder ?
---
[[email protected]] - i'd really appreciate your thoughts on all of this.
> bin/solr SSL support for client->server communcation broken on master
> ---------------------------------------------------------------------
>
> Key: SOLR-9040
> URL: https://issues.apache.org/jira/browse/SOLR-9040
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Hoss Man
> Attachments: SOLR-9040.patch
>
>
> Working on SOLR-9028 lead me to realize that {{bin/solr}} actions which
> require communicating with solr over HTTP are broken on master when SSL is
> enabled. My testing suggests that this doesn't affect branch 6x or 6.0.
> (Long) detailed steps to reproduce to follow in first comment
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
