Solr
  1. Solr
  2. SOLR-2314

replicate/index.jsp UI does not work with repeaters (both master and slave)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 1.4.1
    • Fix Version/s: None
    • Component/s: web gui
    • Labels:
      None
    • Environment:

      jdk 1.6.0.23 ; both jetty and jboss/tomcat.

      Description

      Summary:
      ==========

      • Admin UI replication/index.jsp checks for master or slave with the following code:
        if ("true".equals(detailsMap.get("isSlave")))
      • if slave, replication/index.jsp displays the "Master" and "Poll Intervals", etc. sections (everything up to "Cores")
      • if false, replication/index.jsp does not display the "Master", "Poll Intervals" sections
        -This "slave check/UI difference" works correctly if the solrconfig.xml has a "slave" but not "master" section or vice versa

      Expected results:
      ==================
      Same UI difference would occur in the following scenario:
      a) solrconfig.xml has both master and slave entries
      b) use java.properties (-Dsolr.enable.master -Dsolr.enable.slave) to set "master" or "slave" at runtime

      OR
      c) use solrcore.properties to set "master" and "slave" at runtime

      Actual results:
      ==================
      If solrconfig.xml has both master and slave entries, replication/index.jsp shows both "master" and "slave" section regardless of system.properties or solrcore.properties

        Issue Links

          Activity

          Hide
          Jan Høydahl added a comment -

          Closing old issue as the JSP's are now gone from Solr. Please re-open if still a problem.

          Show
          Jan Høydahl added a comment - Closing old issue as the JSP's are now gone from Solr. Please re-open if still a problem.
          Hide
          Hoss Man added a comment -

          will: if you can try out the patch i've attached to SOLR-2320 and let me know if that solves the problem you were trying to describe, it would be much appreciated.

          Show
          Hoss Man added a comment - will: if you can try out the patch i've attached to SOLR-2320 and let me know if that solves the problem you were trying to describe, it would be much appreciated.
          Hide
          Hoss Man added a comment -

          I've opened SOLR-2320 to track the bug i've identified, since it doesn't seem to be the same issue will was reporting.

          Will: if you can clarify the behavior you are seeing, and how it fails to match your expectations (ie: by providing actual config snippets and screenshots) that would help erify if we are talking about the same bug or not.

          Show
          Hoss Man added a comment - I've opened SOLR-2320 to track the bug i've identified, since it doesn't seem to be the same issue will was reporting. Will: if you can clarify the behavior you are seeing, and how it fails to match your expectations (ie: by providing actual config snippets and screenshots) that would help erify if we are talking about the same bug or not.
          Hide
          Hoss Man added a comment -

          The more i look at this issue, the less i understand it. testing on the trunk (where index.jsp is identical to the 1.4.1 release)...

          • if i use a solrconfig.xml with only master settings, the h1 tag on the page includes "Master" and there are three pieces of data (Index Version, Location, and Size)
          • if i use a solrconfig.xml with only slave settings, the h1 tag on the page includes "Slave" and there are numerous additional pieces of information, including all three property returned as a master
          • if i use a solconfig.xml with both slave and master settings, the h1 tag includes "Master & Slave" and i get all of same data as before
          • this behavior doesn't change if i leave both the master/slave settings in the handler config, and use an "enable" attribute to activate them
          • all of this behavior remains the same regardless of whether i use a system property to drive the enable attributes.

          So based on that, i don't see a bug indicating that master details (or slave details) are displayed incorrectly by index.jsp when only one type is in use, but not when a box is a repeater.

          However...

          Looking at the code in index.jsp, i see that some of the details output when the handler is configured as a repeater come from the "master" details ("confFiles" and "replicateAfter") but the entire "master" section isn't returned by the details command when the replication handler is only a master.

          so there definitely seems to be a bug – i'm just not convinced it's what will ment when he filed this jira issue

          Show
          Hoss Man added a comment - The more i look at this issue, the less i understand it. testing on the trunk (where index.jsp is identical to the 1.4.1 release)... if i use a solrconfig.xml with only master settings, the h1 tag on the page includes "Master" and there are three pieces of data (Index Version, Location, and Size) if i use a solrconfig.xml with only slave settings, the h1 tag on the page includes "Slave" and there are numerous additional pieces of information, including all three property returned as a master if i use a solconfig.xml with both slave and master settings, the h1 tag includes "Master & Slave" and i get all of same data as before this behavior doesn't change if i leave both the master/slave settings in the handler config, and use an "enable" attribute to activate them all of this behavior remains the same regardless of whether i use a system property to drive the enable attributes. So based on that, i don't see a bug indicating that master details (or slave details) are displayed incorrectly by index.jsp when only one type is in use, but not when a box is a repeater. However... Looking at the code in index.jsp, i see that some of the details output when the handler is configured as a repeater come from the "master" details ("confFiles" and "replicateAfter") but the entire "master" section isn't returned by the details command when the replication handler is only a master. so there definitely seems to be a bug – i'm just not convinced it's what will ment when he filed this jira issue
          Hide
          Hoss Man added a comment -

          something to be clear about here: there is nothing special about the system properties you describe – they are completely meaningless to Solr, and nothing in the code does or should ever check for them explicitly. they only have meaning if you use them in your solrconfig.xml file, as a way to specify the values of the "enable" properties in the "master" and "slave" sections of the ReplicationHandler declaration.

          The bug seems to be that the JSP for pretty printing the replication handler status is broken and assumes that something is either a master or a slave and doesn't realize that it's possible for something to be both (in the case of a repeater). if you execute the "details" command against the replication handler directly, you should see the correct information in the response...

          http://localhost:8983/solr/replication?command=details

          Show
          Hoss Man added a comment - something to be clear about here: there is nothing special about the system properties you describe – they are completely meaningless to Solr, and nothing in the code does or should ever check for them explicitly. they only have meaning if you use them in your solrconfig.xml file, as a way to specify the values of the "enable" properties in the "master" and "slave" sections of the ReplicationHandler declaration. The bug seems to be that the JSP for pretty printing the replication handler status is broken and assumes that something is either a master or a slave and doesn't realize that it's possible for something to be both (in the case of a repeater). if you execute the "details" command against the replication handler directly, you should see the correct information in the response... http://localhost:8983/solr/replication?command=details
          Hide
          will milspec added a comment -

          Correction:
          Where the bug says "-Dsolr.enable.master" it should have said '-Denable.master' (similarly for slave)

          Show
          will milspec added a comment - Correction: Where the bug says "-Dsolr.enable.master" it should have said '-Denable.master' (similarly for slave)

            People

            • Assignee:
              Unassigned
              Reporter:
              will milspec
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development