[
https://issues.apache.org/jira/browse/SOLR-14934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242702#comment-17242702
]
ASF subversion and git services commented on SOLR-14934:
--------------------------------------------------------
Commit 05a8477a362beb6b0e5a02b6ee4dfa106a2e6a76 in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=05a8477 ]
SOLR-14934: Fix some additional test helper methods that aren't used on master
but triggered problems when when backporting to branch_8x
> 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
> Assignee: Chris M. Hostetter
> Priority: Minor
> Attachments: SOLR-14934.poc.patch
>
>
> 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
