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

Admin UI cannot find dataimport handlers

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.4
    • Fix Version/s: 6.4.1, 7.0
    • Component/s: Admin UI
    • Security Level: Public (Default Security Level. Issues are Public)
    • Labels:

      Description

      The 6.4.0 version of Solr has a problem with the Dataimport tab in the admin UI. It will say "Sorry, no dataimport-handler defined" when trying to access that tab.

      The root cause of the problem is a change in the /admin/mbeans handler, by SOLR-9947. The section of the output where defined dataimport handlers are listed was changed from QUERYHANDLER to QUERY.

      1. screenshot-1.png
        64 kB
        Andrzej Bialecki
      2. SOLR-10035.patch
        12 kB
        Andrzej Bialecki
      3. SOLR-10035.patch
        10 kB
        Andrzej Bialecki

        Issue Links

          Activity

          Hide
          elyograg Shawn Heisey added a comment -

          The changes to the mbean output are going to make my life interesting beyond the admin UI. I have a SolrJ program that accesses this information and isn't going to work with newer versions of Solr. Because it will need to deal with multiple versions, it's going to have to handle both the old and the new output.

          Show
          elyograg Shawn Heisey added a comment - The changes to the mbean output are going to make my life interesting beyond the admin UI. I have a SolrJ program that accesses this information and isn't going to work with newer versions of Solr. Because it will need to deal with multiple versions, it's going to have to handle both the old and the new output.
          Hide
          elyograg Shawn Heisey added a comment -

          A binary install of Solr 6.4.0 can be fixed without a new version. Edit the following file:

          solr/server/solr-webapp/webapp/js/angular/controllers/dataimport.js

          The string "QUERYHANDLER" will show up once in the file. Change this text to "QUERY". Be sure to only change the one that's all uppercase.

          Show
          elyograg Shawn Heisey added a comment - A binary install of Solr 6.4.0 can be fixed without a new version. Edit the following file: solr/server/solr-webapp/webapp/js/angular/controllers/dataimport.js The string "QUERYHANDLER" will show up once in the file. Change this text to "QUERY". Be sure to only change the one that's all uppercase.
          Hide
          elyograg Shawn Heisey added a comment -

          Something that would be good to add is a test of the dataimport tab in the admin UI ... I've got absolutely no idea how to write that test. Code that can run javascript like a browser would be required.

          Show
          elyograg Shawn Heisey added a comment - Something that would be good to add is a test of the dataimport tab in the admin UI ... I've got absolutely no idea how to write that test. Code that can run javascript like a browser would be required.
          Hide
          janhoy Jan Høydahl added a comment -

          Hmm, we should not change the mbeans API between minor versions. Can we publish these metrics in both sections until 7.0 and publish a deprecation message in changes? This should go in 6.4.1

          Show
          janhoy Jan Høydahl added a comment - Hmm, we should not change the mbeans API between minor versions. Can we publish these metrics in both sections until 7.0 and publish a deprecation message in changes? This should go in 6.4.1
          Hide
          ab Andrzej Bialecki added a comment -

          Can we publish these metrics in both sections until 7.0 and publish a deprecation message in changes?

          Yes, I'll take care of this.

          Show
          ab Andrzej Bialecki added a comment - Can we publish these metrics in both sections until 7.0 and publish a deprecation message in changes? Yes, I'll take care of this.
          Hide
          elyograg Shawn Heisey added a comment -

          Hmm, we should not change the mbeans API between minor versions

          I was thinking the same thing as I filed this issue, but I was worried that anything I said about it would be seen as hindering progress. The changelog mention for SOLR-9947 was not adequate enough for a reader to realize that a user program consuming the mbeans would need to be changed.

          Show
          elyograg Shawn Heisey added a comment - Hmm, we should not change the mbeans API between minor versions I was thinking the same thing as I filed this issue, but I was worried that anything I said about it would be seen as hindering progress. The changelog mention for SOLR-9947 was not adequate enough for a reader to realize that a user program consuming the mbeans would need to be changed.
          Hide
          ab Andrzej Bialecki added a comment -

          I wasn't aware of back-compat concerns in Dataimport UI ... which says something about tests, too (unfortunately I don't know anything about writing UI tests...). I can either revert the name changes, or do as you proposed, ie. register them under both the new and the old names.

          Show
          ab Andrzej Bialecki added a comment - I wasn't aware of back-compat concerns in Dataimport UI ... which says something about tests, too (unfortunately I don't know anything about writing UI tests...). I can either revert the name changes, or do as you proposed, ie. register them under both the new and the old names.
          Hide
          elyograg Shawn Heisey added a comment -

          Fixing the UI (the focus of this issue) is easy - one string on one line.

          The larger concern is that the API for getting statistical information out of Solr has changed in a minor release, in a way that can break clients, and nothing in CHANGES.txt indicated that there was such a change. I understand the desire to remove "HANDLER" from the category names – it's unnecessarily verbose. If it were me making the improvements, I would have left the category names unchanged in 6.x, only making the changes in master.

          Users expect that their client code will continue working if they make a minor version upgrade, and for the most part Solr has kept that promise. Sometimes progress requires changes that break user expectations, but in that case, it should be mentioned in the changelog.

          Show
          elyograg Shawn Heisey added a comment - Fixing the UI (the focus of this issue) is easy - one string on one line. The larger concern is that the API for getting statistical information out of Solr has changed in a minor release, in a way that can break clients, and nothing in CHANGES.txt indicated that there was such a change. I understand the desire to remove "HANDLER" from the category names – it's unnecessarily verbose. If it were me making the improvements, I would have left the category names unchanged in 6.x, only making the changes in master. Users expect that their client code will continue working if they make a minor version upgrade, and for the most part Solr has kept that promise. Sometimes progress requires changes that break user expectations, but in that case, it should be mentioned in the changelog.
          Hide
          janhoy Jan Høydahl added a comment -

          If we revert then the new metrics stuff will break or need to change later, right?

          Now that 7.0 is discussed in a may timeframe perhaps some things can wait?

          Show
          janhoy Jan Høydahl added a comment - If we revert then the new metrics stuff will break or need to change later, right? Now that 7.0 is discussed in a may timeframe perhaps some things can wait?
          Hide
          ab Andrzej Bialecki added a comment -

          The original reason for this change was that the names with "HANDLER" suffixes didn't fit the metrics, and I wanted to avoid creating too many category names... If we change this back to use the old names, it won't unbreak 6.4.0 and it will create a weird situation where names flipped back and forth between 6.x releases. And we need to keep the changed names anyway in 7.0, again in order to cover broader set of plugins and metrics and to avoid creating too many category names.

          So I think that the least confusing option at this point would be to add a very clear note in CHANGES and keep the new names (and avoid breaking back-compat in the future!) Keeping both new and old names is an option, too, but it may be more confusing in the UI / JMX.

          Show
          ab Andrzej Bialecki added a comment - The original reason for this change was that the names with "HANDLER" suffixes didn't fit the metrics, and I wanted to avoid creating too many category names... If we change this back to use the old names, it won't unbreak 6.4.0 and it will create a weird situation where names flipped back and forth between 6.x releases. And we need to keep the changed names anyway in 7.0, again in order to cover broader set of plugins and metrics and to avoid creating too many category names. So I think that the least confusing option at this point would be to add a very clear note in CHANGES and keep the new names (and avoid breaking back-compat in the future!) Keeping both new and old names is an option, too, but it may be more confusing in the UI / JMX.
          Hide
          janhoy Jan Høydahl added a comment -

          So I think that the least confusing option at this point would be to add a very clear note in CHANGES and keep the new names (and avoid breaking back-compat in the future!) Keeping both new and old names is an option, too, but it may be more confusing in the UI / JMX.

          Or some middle ground. Expose both old and new for the rest of 6.x and add a -Dsolr.mbeans.useOnlyNewNaming=true flag which removes the old names with a warning in release notes that this breaks back compat to gain less confusing GUI output. Anyway most users will not even notice, except those that use a monitoring solution which suddenly breaks. Then again, very few have had the chance to upgrade to 6.4 yet

          Show
          janhoy Jan Høydahl added a comment - So I think that the least confusing option at this point would be to add a very clear note in CHANGES and keep the new names (and avoid breaking back-compat in the future!) Keeping both new and old names is an option, too, but it may be more confusing in the UI / JMX. Or some middle ground. Expose both old and new for the rest of 6.x and add a -Dsolr.mbeans.useOnlyNewNaming=true flag which removes the old names with a warning in release notes that this breaks back compat to gain less confusing GUI output. Anyway most users will not even notice, except those that use a monitoring solution which suddenly breaks. Then again, very few have had the chance to upgrade to 6.4 yet
          Hide
          ab Andrzej Bialecki added a comment - - edited

          This patch changes the output of /admin/mbeans to return affected mbeans under both new and old names, and supports selecting beans by both new and old categories.

          I also modified the UI to indicate that old names are deprecated (see the screenshot).

          Show
          ab Andrzej Bialecki added a comment - - edited This patch changes the output of /admin/mbeans to return affected mbeans under both new and old names, and supports selecting beans by both new and old categories. I also modified the UI to indicate that old names are deprecated (see the screenshot).
          Hide
          janhoy Jan Høydahl added a comment -

          Looks awesome
          The obvious question then is, if you specify -Dsolr.mbeans.useOnlyNewNaming=true, will then the DIH UI work? I think we should flip the constant QUERYHANDLER -> QUERY in that dih JS file...

          Show
          janhoy Jan Høydahl added a comment - Looks awesome The obvious question then is, if you specify -Dsolr.mbeans.useOnlyNewNaming=true , will then the DIH UI work? I think we should flip the constant QUERYHANDLER -> QUERY in that dih JS file...
          Hide
          ab Andrzej Bialecki added a comment -

          Jan Høydahl good point I'll change that JS file, and commit it shortly - thanks!

          Show
          ab Andrzej Bialecki added a comment - Jan Høydahl good point I'll change that JS file, and commit it shortly - thanks!
          Hide
          ab Andrzej Bialecki added a comment -

          Final patch. I manually verified that DIH works also when "-Dsolr.mbeans.useOnlyNewNaming=true" is specified.

          Show
          ab Andrzej Bialecki added a comment - Final patch. I manually verified that DIH works also when "-Dsolr.mbeans.useOnlyNewNaming=true" is specified.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit f51a38fd4cd5f98da3a26df55970d662227b633a in lucene-solr's branch refs/heads/branch_6x from Andrzej Bialecki
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f51a38f ]

          SOLR-10035 Admin UI cannot find dataimport handlers.

          Show
          jira-bot ASF subversion and git services added a comment - Commit f51a38fd4cd5f98da3a26df55970d662227b633a in lucene-solr's branch refs/heads/branch_6x from Andrzej Bialecki [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f51a38f ] SOLR-10035 Admin UI cannot find dataimport handlers.
          Hide
          janhoy Jan Høydahl added a comment -

          This can be RESOLVED, not?

          Show
          janhoy Jan Høydahl added a comment - This can be RESOLVED, not?
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 51ff50d76da23137e2b0afe4af130601ba17eab1 in lucene-solr's branch refs/heads/master from Andrzej Bialecki
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=51ff50d ]

          SOLR-10035 Fix dataimport to use the new names.

          Show
          jira-bot ASF subversion and git services added a comment - Commit 51ff50d76da23137e2b0afe4af130601ba17eab1 in lucene-solr's branch refs/heads/master from Andrzej Bialecki [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=51ff50d ] SOLR-10035 Fix dataimport to use the new names.
          Hide
          ab Andrzej Bialecki added a comment -

          This needed also a small fix on master so that the UI uses only the new names.

          Show
          ab Andrzej Bialecki added a comment - This needed also a small fix on master so that the UI uses only the new names.

            People

            • Assignee:
              ab Andrzej Bialecki
              Reporter:
              elyograg Shawn Heisey
            • Votes:
              2 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development