[
https://issues.apache.org/jira/browse/SOLR-15026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249167#comment-17249167
]
Chris M. Hostetter commented on SOLR-15026:
-------------------------------------------
{quote}Hi Chris M. Hostetter I actually think the right fix for this test class
is to just add the SuppressSSL annotation as you've already done.
Alternatively, we could pass the SSLConfig from the SolrTestCaseJ4 to the
JettyConfig builder such as:
JettyConfig.builder().withSSLConfig(sslConfig.buildServerSSLConfig()).build().
But, that's already being done in TestMiniSolrCloudClusterSSL for SSL specific
tests, seems unnecessary to add SSL randomization to MiniSolrCloudClusterTest.
{quote}
I feel like that resolution sidesteps my broader concern: which is that at the
moment, regardless of what "jetty+ssl config" is used when constructing a
MiniSolrCloudCluster, the cluster is going to make assumptions about ssl that
can contradict the explicit config, based on external factors like system
properties _or lack of system properties_ that exist at the moment the cluster
is constructed.
saying that this is expected – that these "action at a distance" external
factors are needed for the cluster to work properly, and that SolrTestCaseJ4
takes care of this for you, implies that MiniSolrCloudCluster can _only_ be
used with SolrTestCaseJ4 – but it was originally designed intentionally so that
people didn't have to use SolrTestCaseJ4 (or SolrCloudTestCase)
The set of problems actually goes 2 directions:
* cluster user does _not_ want ssl, but might get bits of it based on
SolrTestCaseJr randomization
* cluster user _does_ want ssl, and specifies that via JettyConfig based to
MiniSolrCloudCluster, but ssl doesn't work in all operations
In the initial case i mentioned – IIUC – SolrTestCaseJ4 sets a 'urlScheme'
system property which the cluster picked up s part of it's solr.xml config
parsing, even though the user created the cluster with a jetty conig that
explicitly did not have SSL configured.
* this means if SolrTestCaseJ4 randomly decides to _default_ to ssl, then
every MiniSolrCloudCluster in a test must _also_ use ssl config options in it's
JettyConfig or the test will break
* it also means that SolrTestCaseJ4 randomly _not_ to decides to _default_ to
ssl, then any MiniSolrCloudCluster in that test must _not_ try to use ssl
config options in it's JettyConfig, or the test will break
* this should be an easy fix: as i mentioned we already have a way to
"override" sys properties via SolrDispatchFilter "extra" properties where
MiniSolrCloudCluster should specify any properties (like "urlScheme") that it
_knows_ it's solr.xml expects to be set properly, using whatever values make
sense based on the config options on the MiniSolrCloudCluster (ie: if the
Jetty's SSL Config says "use ssl" then set urlScheme="http" otherwise set it to
"https")
A bigger problem seems to be the _client_ side SSL config – right now
MiniSolrCloudCluster only knows about SSL via the ("action at a distance sys
props the test case may set, and) the JettyConfig's (Server) SSLConfig – but
the {{MiniSolrCloudCluster.buildSolrClient()}} doesn't know/do anything
regarding SSL – it evidently also expects someone else to have already done
"action at a distance" to have called
{{Http2SolrClient.setDefaultSSLConfig(...)}}
* so if you try to write a (non-SolrTestCaseJ4) test that uses...{{new
MiniSolrCloudCluster(3, createTempDir(),
JettyConfig.builder().withSSLConfig((new
org.apache.solr.util.SSLTestConfig(true,
false)_.buildServerSSLConfig()).build());}} .. it's not going to work, because
{{cluster.getSolrClinent()}} isn't going to be configred to use SSL.
----
I really feel like the "right" solution in the long run (although it may no be
very easy) is for MiniSolrCloudCluster constructure to take in an (optional)
SSLTestConfig, and if it's set then it should be used to determine the SSL
options for the jetty instances (overriding anything that might already be in
the JettyConfig) _and_ to derive the SSL options for the client instance, _and_
to set whatever SolrDispatchFilter "properties" need to be set to satisy
solr.xml variables related to the protocol (ie: "urlScheme")
{panel}
Side Note: I really have no idea _why_ {{MiniSolrCloudClusterTest extends
SolrTestCaseJ4}} ... this is only true on master, and was a change made by
[~mdrob] as part of SOLR-14223 w/o any other changes/additions to
MiniSolrCloudClusterTest ... making me suspicious as to why it was done unless
it's because of some _other_ "action at a distance" dependency/assumption
introduced in MiniSolrCloudCluster by that "PKI" related jira that is
satisfied by SolrTestCaseJ4 in a way that won't work for users trying to use
MiniSolrCloudCluster directly in their own test w/o extending SolrTestCaseJ4
{panel}
> MiniSolrCloudCluster can inconsistently get confused about when it's using SSL
> ------------------------------------------------------------------------------
>
> Key: SOLR-15026
> URL: https://issues.apache.org/jira/browse/SOLR-15026
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
>
> A new test added in SOLR-14934 caused the following reproducible failure to
> pop up on jenkins...
> {noformat}
> hossman@slate:~/lucene/dev [j11] [master] $ ./gradlew -p solr/test-framework/
> test --tests MiniSolrCloudClusterTest.testSolrHomeAndResourceLoaders
> -Dtests.seed=806A85748BD81F48 -Dtests.multiplier=2 -Dtests.slow=true
> -Dtests.locale=ln-CG -Dtests.timezone=Asia/Thimbu -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
> Starting a Gradle Daemon (subsequent builds will be faster)
> > Task :randomizationInfo
> Running tests with randomization seed: tests.seed=806A85748BD81F48
> > Task :solr:test-framework:test
> org.apache.solr.cloud.MiniSolrCloudClusterTest >
> testSolrHomeAndResourceLoaders FAILED
> org.apache.solr.client.solrj.SolrServerException: IOException occurred
> when talking to server at: https://127.0.0.1:38681/solr
> at
> __randomizedtesting.SeedInfo.seed([806A85748BD81F48:37548FA7602CB5FD]:0)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:712)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:269)
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251)
> at
> org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:390)
> at
> org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:360)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1168)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:931)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:865)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:229)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:246)
> at
> org.apache.solr.cloud.MiniSolrCloudClusterTest.testSolrHomeAndResourceLoaders(MiniSolrCloudClusterTest.java:125)
> ...
> Caused by:
> javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:439)
> {noformat}
> The problem sems to be that even though the MiniSolrCloudCluster being
> instantiated isn't _intentionally_ using any SSL randomization (it just uses
> {{JettyConfig.builder().build()}} the CloudSolrClient returned by
> {{cluster.getSolrClient()}} is evidnetly picking up the ranodmized SSL and
> trying to use it to talk to the cluster.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
