[
https://issues.apache.org/jira/browse/SOLR-14958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17218640#comment-17218640
]
Chris M. Hostetter commented on SOLR-14958:
-------------------------------------------
Straw man proposal for improvement...
* SolrDispatchFilter should be the *only* place checking
{{System.getProperty("zkHost")}}
** should be a fallback if and only if the "solr.properites" {{Properties}}
attribute doesn't contain a value
** if sys prop is used, value should be added to the {{Properites}} before
solr.xml is parsed
* {{SolrXmlConfig.fillSolrCloudSection}} should be refactored to call call
{{CloudConfigBuilder.setZkHost(...)}} using the value from the node properties
(if any) _before_ parsing the entries in the {{<solrcloud>}} section
** so {{solr.xml}} setting can still override whatever zkHost _may_ have been
used to load the {{solr.xml}} from (for the folks that run cloud clusters, but
still don't keep solr.xml zk)
** the hard coded default of {{System.getProperty("zkHost")}} should be
removed from {{CloudConfigBuilder}}
* update the checkChroot method in ZkContainer to compare against the node
props instead of directly against the sys prop
* add a new test that spins up multiple MiniSolrCloudClusters using isolated
zkHost settings, and confirm we can add new nodes to each of them w/o impacting
each other.
> 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
> Priority: Major
>
> (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
