Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-14934

Multiple Code Paths for determining "solr home" can return differnet answers



    • Bug
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • None
    • 8.8, 9.0
    • None
    • None


      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.


        1. SOLR-14934.poc.patch
          44 kB
          Chris M. Hostetter

        Issue Links



              hossman Chris M. Hostetter
              hossman Chris M. Hostetter
              0 Vote for this issue
              4 Start watching this issue