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

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

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

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

    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.

      Attachments

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            hossman Chris M. Hostetter
            hossman Chris M. Hostetter
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Issue deployment