[SOLR-14934] Multiple Code Paths for determining "solr home" can return differnet answers

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Fix Version/s: 8.8, 9.0
• Assignee: Chris M. Hostetter
• Reporter: Chris M. Hostetter
• Created: 14/Oct/20 23:21
• Updated: 12/May/22 00:26
• Resolved: 03/Dec/20 00:20

Description

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.

Issue Links

• relates to: SOLR-14958 zkHost sys prop requirement prevents sane/safe cloud test usage