You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2020/12/02 17:25:00 UTC
[jira] [Commented] (SOLR-14934) Multiple Code Paths for determining
"solr home" can return differnet answers
[ https://issues.apache.org/jira/browse/SOLR-14934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242546#comment-17242546 ]
ASF subversion and git services commented on SOLR-14934:
--------------------------------------------------------
Commit 2e6a02394ec4eea6ba72d5bc2bf02c0139a54f39 in lucene-solr's branch refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2e6a023 ]
SOLR-14934: Refactored duplicate "Solr Home" logic into a single place to eliminate risk of tests using divergent values for a single solr node.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org