[
https://issues.apache.org/jira/browse/SOLR-14958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-14958:
--------------------------------------
Attachment: SOLR-14958.patch
Assignee: Chris M. Hostetter
Status: Open (was: Open)
Attaching patch with suggested changes...
This isn't quite as clean as i was hoping, just because of how many different
places in this call stack tests expect to be able to call directly and have a
zkHost sys prop picked up -- i didn't want to try to "fix" all of those tests
here and now, but it helped to ensure all the basis were covered in the new
code.
what's important is that in the new code, there is never any chance that zkHost
sys prop will be read by mistake in place of an explicitly configured zkHost
node property -- so MiiSolrCloudCluster (and future work in SOLR-14903) can
work sanely w/o depending on action at a distance from a system property
> 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
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-14958.patch
>
>
> (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
