Solr
  1. Solr
  2. SOLR-3980

Incorporate lazily-loaded cores into core listings for clients

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 4.1
    • Fix Version/s: 4.3, 5.0
    • Component/s: multicore, web gui
    • Labels:
      None

      Description

      Part of SOLR-1293 (supporting lots of cores) will require we do something to allow clients (particularly the admin GUI) to get a full list of all possible cores, whether they've been loaded or not.

        Issue Links

          Activity

          Hide
          Uwe Schindler added a comment -

          Closed after release.

          Show
          Uwe Schindler added a comment - Closed after release.
          Hide
          Erick Erickson added a comment -

          This has been fixed for a while, see SOLR-1533 for instance.

          Show
          Erick Erickson added a comment - This has been fixed for a while, see SOLR-1533 for instance.
          Hide
          Erick Erickson added a comment -

          Talking with Stefan, it seems like the right thing to do is make the admin STATUS command return all cores, loaded and unloaded.

          Show
          Erick Erickson added a comment - Talking with Stefan, it seems like the right thing to do is make the admin STATUS command return all cores, loaded and unloaded.
          Hide
          Steve Rowe added a comment -

          Same as SOLR-1533, I'll resolve all this stuff as a bunch for 4.2

          Ok, thanks, I've pushed Fix Version to 4.2.

          Show
          Steve Rowe added a comment - Same as SOLR-1533 , I'll resolve all this stuff as a bunch for 4.2 Ok, thanks, I've pushed Fix Version to 4.2.
          Hide
          Erick Erickson added a comment -

          Same as SOLR-1533, I'll resolve all this stuff as a bunch for 4.2

          Show
          Erick Erickson added a comment - Same as SOLR-1533 , I'll resolve all this stuff as a bunch for 4.2
          Hide
          Steve Rowe added a comment -

          Erick, can this issue be resolved?

          Show
          Steve Rowe added a comment - Erick, can this issue be resolved?
          Hide
          Erick Erickson added a comment -

          OK, this is really done as part of SOLR-1306. Lazily-loaded cores get returned with the usual STATUS listing. Do note, however, that for the case of a core that could be loaded but hasn't yet been loaded (or has aged out of the cache), only a subset of data is returned. All that can be relied on is
          "name", "isDefaultCore", and "instanceDir".

          Additional entries if the provider supplies them are:
          "dataDir", "config", "schema".

          Additionally, the STATUS command will return an additional value called isLoaded ("true"|"false") that can be used to determine what data set to expect.

          Show
          Erick Erickson added a comment - OK, this is really done as part of SOLR-1306 . Lazily-loaded cores get returned with the usual STATUS listing. Do note, however, that for the case of a core that could be loaded but hasn't yet been loaded (or has aged out of the cache), only a subset of data is returned. All that can be relied on is "name", "isDefaultCore", and "instanceDir". Additional entries if the provider supplies them are: "dataDir", "config", "schema". Additionally, the STATUS command will return an additional value called isLoaded ("true"|"false") that can be used to determine what data set to expect.
          Hide
          Erick Erickson added a comment -

          Duh, because it's late and I didn't think of it? But I think you're right, that would make more sense.

          Show
          Erick Erickson added a comment - Duh, because it's late and I didn't think of it? But I think you're right, that would make more sense.
          Hide
          Jack Krupansky added a comment -

          Why should STATUS force a core load - in the world of lazily loaded cores? I would think that STATUS should be changed to indicate that a core might not be loaded.

          Show
          Jack Krupansky added a comment - Why should STATUS force a core load - in the world of lazily loaded cores? I would think that STATUS should be changed to indicate that a core might not be loaded.
          Hide
          Erick Erickson added a comment -

          In looking at this a bit more, the only way that currently exists to get a list of cores is to do a core admin STATUS command. Unfortunately, that loads all the cores and in the case where there are a large number of them, this will be unacceptable.

          I propose a new core admin command LIST that will return a simple listing of the cores, just the name. The Admin UI will need to use this to display the actual list, then make a STATUS request when the user is drilling down....

          I suppose another solution would be an extra parameter for STATUS, namesOnly=true or some such, but I don't really like that, although I'd be willing to be persuaded otherwise.

          Show
          Erick Erickson added a comment - In looking at this a bit more, the only way that currently exists to get a list of cores is to do a core admin STATUS command. Unfortunately, that loads all the cores and in the case where there are a large number of them, this will be unacceptable. I propose a new core admin command LIST that will return a simple listing of the cores, just the name. The Admin UI will need to use this to display the actual list, then make a STATUS request when the user is drilling down.... I suppose another solution would be an extra parameter for STATUS, namesOnly=true or some such, but I don't really like that, although I'd be willing to be persuaded otherwise.
          Hide
          Erick Erickson added a comment -

          Breaking this out of SOLR-880 to track separately

          Show
          Erick Erickson added a comment - Breaking this out of SOLR-880 to track separately

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development