Chris M. Hostetter created SOLR-14958:
-----------------------------------------
Summary: zkHost sys prop requirement prevents sane/safe cloud test
usage
Key: SOLR-14958
URL: https://issues.apache.org/jira/browse/SOLR-14958
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter
(This is somewhat analogous to SOLR-14934, but AFAICT only affects tests)
MiniSolrCloudCluster - and/or any test that wants to run "cloud" nodes that
pull solr.xml from ZooKeeper - currently *only* works because it calls
{{System.setProperty("zkHost",...)}} - there is no other mechanism to
communicate a 'zkHost' connection information to a Solr node (w/o hardcoding
the value in a {{solr.xml}} file already on disk), making it unsafe to have
multiple "solr clusters" running in a single JVM.
SolrDispatchFilter already supports the ability to read properties from
"context" attributes (which is currently leveraged by our test infrastructure)
which are used to specify the "node properties" for the core container, and
allow per-node overrides of system properties with the same name when parsing
variables in solr.xml. But! ... SolrDispatchFilter does not consult these node
properties when deciding where to try and load solr.xml from.
Even if we "fix" SolrDispatchFilter to look for 'zkHost' in the node
properties, SolrXmlConfig supports a {{<str name="zkHost"/>}} option in the
{{<solrcloud>}} section. if that option is missing, then
{{System.getProperty("zkHost")}} is used as a default - *IGNORING ANY zkHost IN
THE NODE PROPERTIES*.
I think we should try to fix this discrepency, and make it possible to run a
{{MiniSolrCloud}} cluster w/o relying on setting 'zkHost' sys prop.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
