[
https://issues.apache.org/jira/browse/SOLR-14934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214335#comment-17214335
]
Chris M. Hostetter commented on SOLR-14934:
-------------------------------------------
The most prominent place I've seen {{SolrPaths.locateSolrHome()}} get used
(outside of the {{SolrDispatchFilter}}) is in the no-arg constructor to
{{SolrResourceLoader}}, or in the case that {{new SolrResourceLoader(...)}} is
called with a null {{Path}} -- something that doesn't seem like it was ever
ment to be a valid useage, it looks like it was just there so the no-arg
constructor could call the multi-arg constructor)
----
Here's my straw man proposal....
* on master & backported to 8x
** {{SolrPaths.locateSolrHome()}}
*** mark deprecated
*** move the "guts" of this logic directly into {{SolrDispatchFilter}}
*** fix sole remaining "real code" usage (XmlConfigFile, in what appears to be
a dead code path) to throw NullPointerException if situation encountered
*** replace all direct usage in tests with direct access to the {{Path}}
created by the test framework
** {{SolrResourceLoader}}
*** mark the no-arg constructor deprecated
*** update the javadocs of other constructors to note that the behavior with a
null {{Path}} is specified is un-specified and will fail in 9.x
*** fix sole "real code" usage (SolrCoreParser, in what appears to be a dead
code path) to throw NullPointerException if situation encountered
*** replace all direct usage of {{new SolrResourceLoader()}} in tests with
constructor that takes in the (test's) {{solrHome}} Path.
** update test's security policy to blacklist
{{System.setProperty("solr.solr.home",...)}}
* on master only
** delete {{SolrPaths.locateSolrHome()}}
** delete no-arg {{SolrResourceLoader}} constructor
** make remaining {{SolrResourceLoader}} constructors throw
NullPointerException if {{Path}} arg is null
> Multiple Code Paths for determining "solr home" can return differnet answers
> ----------------------------------------------------------------------------
>
> Key: SOLR-14934
> URL: https://issues.apache.org/jira/browse/SOLR-14934
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Minor
>
> While looking into some possible ways to make our tests more closely match
> "real" solr installs, I realized that we currently have 2 different methods
> for determining the "solr home" for a node...
> * {{SolrPaths.locateSolrHome()}}
> ** static method that uses a hueristic that typically results in using
> {{System.getProperty("solr.solr.home");}}
> *** NOTE: the result is not stored in any static/final variables
> ** this method
> * {{SolrDispatchFilter}}
> ** starts by checking if an explicit {{ServletContext}} attribute is
> specified
> *** falls back to using {{SolrPaths.locateSolrHome()}}
> ** whatever value is found gets set on {{CoreContainer}}
> In a typical Solr install, the {{"solr.solr.home"}} system property is set by
> {{bin/solr}} and we get a consistent value for the life of the server
> instance regardless of code path.
> In tests, we have {{SolrTestCaseJ4}} (and a handful of other places) that
> calls {{System.setProperty("solr.solr.home",...)}} *AND* in jetty based tests
> (including {{MiniSolrCloudCluster}} based tests) we rely on the
> {{ServletContext}} attribute based approach to have a unique "Solr Home" for
> each node. ({{JettySOlrRunner}} injects the value when wiring up the
> {{Server}} instance)
> This means that:
> * in jetty based test - even if it's a single jetty instance - each of the
> node's CoreContainer has a unique value of "solr home", but any code paths in
> solr that directly call {{SolrPaths.locateSolrHome()}} will get a consistent
> value across all nodes (different from the value in the CoreContainer for any
> node)
> * allthough i don't think it happens now: a test could call
> {{System.setProperty("solr.solr.home",...)}} while a node is running, and
> potentially get inconsistent behavior from even a jetty node over time.
> ----
> In practice, I don't think that any of this is currently causing "real bugs"
> in actual solr code; nor do i _think_ we're seeing any "false positives" or
> "false failures" in tests as a result of this - but it is a big huge land
> mine just waiting to go off if we step too close, and i think we should
> recitfy this.
--
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
