Major Description
(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.
Attachments
Attachments
Issue Links
- is related to
-
SOLR-14934 Multiple Code Paths for determining "solr home" can return differnet answers
-
- Closed
-