Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.4, 6.0
    • Component/s: multicore
    • Labels:
      None

      Description

      When the solr.xml file is set to persistent="true", the logging element that contains the LogWatcher configuration is not persisted to the new solr.xml file that is written when managing the cores via core admin.

        Issue Links

          Activity

          Hide
          Michael Garski added a comment -

          I have some time available and was going to start working on this (I have a custom logback watcher), however I noticed more than once on the mailing list that there is a desire to move away from using solr.xml and instead determining the cores by walking the directories. Would solr.xml still exist in this case but only for configuring application-level items such as a LogWatcher and not contain any core info?

          Show
          Michael Garski added a comment - I have some time available and was going to start working on this (I have a custom logback watcher), however I noticed more than once on the mailing list that there is a desire to move away from using solr.xml and instead determining the cores by walking the directories. Would solr.xml still exist in this case but only for configuring application-level items such as a LogWatcher and not contain any core info?
          Hide
          Erick Erickson added a comment -

          The current thinking (subject to change) is that there will be a properties file (typical, simple Java Properties-compliant file of name=value pairs) that'll hold what would currently go in the <solr> or <cores> tags. All of the individual <core> tags would be obsoleted, and found through discovery. So you'd have entries like
          solr.cores.adminpath=
          solr.cores.defaultCoreName=

          etc. in solr.properties, all of which could be overridden on by system properties.

          Currently SOLR-4196 is where the action on this is coming from. This will not be available until 4.2, and of course the whole 4.x code line will continue to read the solr.xml file.

          Show
          Erick Erickson added a comment - The current thinking (subject to change) is that there will be a properties file (typical, simple Java Properties-compliant file of name=value pairs) that'll hold what would currently go in the <solr> or <cores> tags. All of the individual <core> tags would be obsoleted, and found through discovery. So you'd have entries like solr.cores.adminpath= solr.cores.defaultCoreName= etc. in solr.properties, all of which could be overridden on by system properties. Currently SOLR-4196 is where the action on this is coming from. This will not be available until 4.2, and of course the whole 4.x code line will continue to read the solr.xml file.
          Hide
          Michael Garski added a comment -

          Thanks Erick! I'll close this and keep an eye on SOLR-4196.

          Show
          Michael Garski added a comment - Thanks Erick! I'll close this and keep an eye on SOLR-4196 .
          Hide
          Michael Garski added a comment -

          This will be resolved when SOLR-4196 is completed.

          Show
          Michael Garski added a comment - This will be resolved when SOLR-4196 is completed.
          Hide
          Erick Erickson added a comment -

          Michael:

          I'm re-opening this issue, since we'll be supporting solr.xml through the 4.x life cycle. There are a lot of changes necessary for 4196 and this might well be lost if we don't have an open JIRA for it.

          Treat the re-opening as a suggestion, feel free to re-close it if you think it should be.

          Show
          Erick Erickson added a comment - Michael: I'm re-opening this issue, since we'll be supporting solr.xml through the 4.x life cycle. There are a lot of changes necessary for 4196 and this might well be lost if we don't have an open JIRA for it. Treat the re-opening as a suggestion, feel free to re-close it if you think it should be.
          Hide
          Erick Erickson added a comment -

          I'm not going to be able to work on this, plus I only took it because I was in the code, plus logging is currently changing so I'll leave it to more ambitious souls.

          FWIW, solr.xml is making a resurgence so if Michael wants to pick it back up that'd be great!

          Show
          Erick Erickson added a comment - I'm not going to be able to work on this, plus I only took it because I was in the code, plus logging is currently changing so I'll leave it to more ambitious souls. FWIW, solr.xml is making a resurgence so if Michael wants to pick it back up that'd be great!
          Hide
          Erick Erickson added a comment -

          Fixed as part of SOLR-4910

          Show
          Erick Erickson added a comment - Fixed as part of SOLR-4910
          Hide
          Steve Rowe added a comment -

          Bulk close resolved 4.4 issues

          Show
          Steve Rowe added a comment - Bulk close resolved 4.4 issues

            People

            • Assignee:
              Erick Erickson
              Reporter:
              Michael Garski
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development