[
https://issues.apache.org/jira/browse/SOLR-14934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-14934:
--------------------------------------
Attachment: SOLR-14934.poc.patch
Assignee: Chris M. Hostetter
Status: Open (was: Open)
I've attached a "PoC" patch implementing (most of) the strawman changes i
suggested -- with some nocommit comments showing where certain changes would
only be committed to master w/o backporting to 8x (but are included to
demonstrate tests would still pass) and other nocommit comments indicating
where additional steps would be taken after backporting the "meat" of the
changes to refactor/remove functionality from master.
(The idea here is that this patch gives an overview of "the long view" and
helps prove that tests will pass even once the methods we want to deprecate are
removed)
> 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
