Solr
  1. Solr
  2. SOLR-723

SolrCore & aliasing/swapping may lead to confusing JMX

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.3
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      As mentioned by Yonik in SOLR-647, JMX registers the core with its name.
      After swapping or re-aliasing the core, the JMX tracking name does not correspond to the actual core anymore.

        Issue Links

          Activity

          Hide
          Erick Erickson added a comment -

          2013 Old JIRA cleanup

          Show
          Erick Erickson added a comment - 2013 Old JIRA cleanup
          Hide
          Greg Bowyer added a comment -

          Included the missing InfoRegistry.java from the patch

          I really need to get better at this :S

          Show
          Greg Bowyer added a comment - Included the missing InfoRegistry.java from the patch I really need to get better at this :S
          Hide
          Greg Bowyer added a comment -

          Initial attempt at making the core swapping do the right thing with regard to the JMX tree, I am also working on patches for SOLR-3083

          Show
          Greg Bowyer added a comment - Initial attempt at making the core swapping do the right thing with regard to the JMX tree, I am also working on patches for SOLR-3083
          Hide
          Greg Bowyer added a comment -

          So this is an issue with core swaps in 3.6 I have an interest in fixing this but does the solr-cloud work make this irrelevant ?

          My thoughts were more towards that the jmx tree should just exist for each alias as a duplicate of the original named core rather than links or aliases which are quite hard to get most monitoring tools to respect.

          Show
          Greg Bowyer added a comment - So this is an issue with core swaps in 3.6 I have an interest in fixing this but does the solr-cloud work make this irrelevant ? My thoughts were more towards that the jmx tree should just exist for each alias as a duplicate of the original named core rather than links or aliases which are quite hard to get most monitoring tools to respect.
          Hide
          Henri Biestro added a comment -

          The other simpler approach is just to state that the core name is immutable.
          Which would make this issue a moot point.

          Show
          Henri Biestro added a comment - The other simpler approach is just to state that the core name is immutable. Which would make this issue a moot point.
          Hide
          Henri Biestro added a comment - - edited

          Yonik's comment in solr-725 makes an analogy between name/aliases and the SolrCore that's close to what hard-links are to inodes.
          What if we were to consider the 'inode' as the sole think that really uniquely identifies a SolrCore, that is it's dataDir?
          The SolrCore name would not be used for that purpose and would only happen to be the first alias (as it stands now).
          This would allow solving this issue by changing how we register a core into JMX (with its relative path to the solr.solr.home dir or something close to that) and have no swapping, etc.
          Just a thought.

          Show
          Henri Biestro added a comment - - edited Yonik's comment in solr-725 makes an analogy between name/aliases and the SolrCore that's close to what hard-links are to inodes. What if we were to consider the 'inode' as the sole think that really uniquely identifies a SolrCore, that is it's dataDir ? The SolrCore name would not be used for that purpose and would only happen to be the first alias (as it stands now). This would allow solving this issue by changing how we register a core into JMX (with its relative path to the solr.solr.home dir or something close to that) and have no swapping, etc. Just a thought.

            People

            • Assignee:
              Unassigned
              Reporter:
              Henri Biestro
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development