Solr
  1. Solr
  2. SOLR-3633

web UI reports an error if CoreAdminHandler says there are no SolrCores

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0-ALPHA
    • Fix Version/s: 4.5, 5.0
    • Component/s: web gui
    • Labels:
      None

      Description

      Spun off from SOLR-3591...

      • having no SolrCores is a valid situation
      • independent of what may happen in SOLR-3591, the web UI should cleanly deal with there being no SolrCores, and just hide/grey out any tabs that can't be supported w/o at least one core
      • even if there are no SolrCores the core admin features (ie: creating a new core) should be accessible in the UI
      1. SOLR-3633.patch
        7 kB
        Hoss Man
      2. SOLR-3633.patch
        7 kB
        Mark Miller
      3. SOLR-3633.patch
        13 kB
        Stefan Matheis (steffkes)
      4. SOLR-3633.patch
        22 kB
        Stefan Matheis (steffkes)
      5. SOLR-3633.patch
        28 kB
        Stefan Matheis (steffkes)
      6. SOLR-3633.patch
        28 kB
        Stefan Matheis (steffkes)

        Issue Links

          Activity

          Hide
          Adrien Grand added a comment -

          4.5 release -> bulk close

          Show
          Adrien Grand added a comment - 4.5 release -> bulk close
          Hide
          Aaron Greenspan added a comment - - edited

          Erick,

          I suppose the problem has improved in 4.4.0 from 4.3.0 in that I no longer see a Java exception, but the red box error message in the web UI that no cores are active and that Solr can't work in such a state is completely unhelpful, as I pointed out in comments above. Either new users such as myself need some way to add a core back through the web UI, and/or the web UI should continue working even when there are zero active cores. Right now the only way out is to re-install since I have no idea which XML files to change or how.

          Hope this helps,

          Aaron

          Show
          Aaron Greenspan added a comment - - edited Erick, I suppose the problem has improved in 4.4.0 from 4.3.0 in that I no longer see a Java exception, but the red box error message in the web UI that no cores are active and that Solr can't work in such a state is completely unhelpful, as I pointed out in comments above. Either new users such as myself need some way to add a core back through the web UI, and/or the web UI should continue working even when there are zero active cores. Right now the only way out is to re-install since I have no idea which XML files to change or how. Hope this helps, Aaron
          Hide
          Erick Erickson added a comment -

          Aaron:

          Please define "trouble", and I suggest you ask the question on the user's list, this has been working for others.

          Show
          Erick Erickson added a comment - Aaron: Please define "trouble", and I suggest you ask the question on the user's list, this has been working for others.
          Hide
          Erick Erickson added a comment -

          Aaron:

          Please define "trouble", and I suggest you ask the question on the user's list, this has been working for others.

          Show
          Erick Erickson added a comment - Aaron: Please define "trouble", and I suggest you ask the question on the user's list, this has been working for others.
          Hide
          Aaron Greenspan added a comment -

          I'm still having this problem with 4.4.0.

          Show
          Aaron Greenspan added a comment - I'm still having this problem with 4.4.0.
          Hide
          Erick Erickson added a comment -

          OK, I did nothing except shut my computer down for the night and start it back up. And.. tadaaaaa! it "just works" now. I'll blame it on browser caching, although of course I stopped and started Jetty, rebuilt everything and even tried a different browser... Siiigggghhhh.

          Really nice, BTW.

          Show
          Erick Erickson added a comment - OK, I did nothing except shut my computer down for the night and start it back up. And.. tadaaaaa! it "just works" now. I'll blame it on browser caching, although of course I stopped and started Jetty, rebuilt everything and even tried a different browser... Siiigggghhhh. Really nice, BTW.
          Hide
          Stefan Matheis (steffkes) added a comment -

          Uhm, well .. works for me™? should work exactly as you've described it (however you manage it to disable the core) - reading from the code, the only way to still get the red box .. is, the request to /solr/admin/info/system?wt=json is failing .. does it for you?

          Show
          Stefan Matheis (steffkes) added a comment - Uhm, well .. works for me™? should work exactly as you've described it (however you manage it to disable the core) - reading from the code, the only way to still get the red box .. is, the request to /solr/admin/info/system?wt=json is failing .. does it for you?
          Hide
          Erick Erickson added a comment -

          Stefan Matheis (steffkes)

          Doesn't work for me, what did I miss?

          I took a stock trunk (and 4x, results identical). Renamed example/solr/collection1/core.properties to "eoe.properties". Now going to http://localhost:8983/solr/ still displays the big red box..... Or is that intended and I just don't understand? I did do an 'ant clean' from the top level and rebuilt...

          Show
          Erick Erickson added a comment - Stefan Matheis (steffkes) Doesn't work for me, what did I miss? I took a stock trunk (and 4x, results identical). Renamed example/solr/collection1/core.properties to "eoe.properties". Now going to http://localhost:8983/solr/ still displays the big red box..... Or is that intended and I just don't understand? I did do an 'ant clean' from the top level and rebuilt...
          Hide
          ASF subversion and git services added a comment -

          Commit 1503855 from Stefan Matheis (steffkes) in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1503855 ]

          SOLR-3633 - web UI reports an error if CoreAdminHandler says there are no SolrCores (merge r1503853)

          Show
          ASF subversion and git services added a comment - Commit 1503855 from Stefan Matheis (steffkes) in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1503855 ] SOLR-3633 - web UI reports an error if CoreAdminHandler says there are no SolrCores (merge r1503853)
          Hide
          ASF subversion and git services added a comment -

          Commit 1503853 from Stefan Matheis (steffkes) in branch 'dev/trunk'
          [ https://svn.apache.org/r1503853 ]

          SOLR-3633 - web UI reports an error if CoreAdminHandler says there are no SolrCores

          Show
          ASF subversion and git services added a comment - Commit 1503853 from Stefan Matheis (steffkes) in branch 'dev/trunk' [ https://svn.apache.org/r1503853 ] SOLR-3633 - web UI reports an error if CoreAdminHandler says there are no SolrCores
          Hide
          Stefan Matheis (steffkes) added a comment -

          Core-Selector is functional now, still needs a bit tweaking on the layout side

          Show
          Stefan Matheis (steffkes) added a comment - Core-Selector is functional now, still needs a bit tweaking on the layout side
          Hide
          Stefan Matheis (steffkes) added a comment -

          Updated Patch handles Core-Admin Page w/o any cores .. will add correct handling for Dropdown in the next Patch, hopefully coming shortly

          Show
          Stefan Matheis (steffkes) added a comment - Updated Patch handles Core-Admin Page w/o any cores .. will add correct handling for Dropdown in the next Patch, hopefully coming shortly
          Hide
          Stefan Matheis (steffkes) added a comment -

          After SOLR-4943 is committed .. first version of the UI-related part of the patch.

          Todo:

          • Core-Selector in left Column
          • Core-Admin Page
          Show
          Stefan Matheis (steffkes) added a comment - After SOLR-4943 is committed .. first version of the UI-related part of the patch. Todo: Core-Selector in left Column Core-Admin Page
          Hide
          Mark Miller added a comment -

          Chris Hostetter - I'm motivated to get something working here, so I spun off into that other issue to create a fast track path to getting this done. Thanks to some help from Stefan Matheis (steffkes), it looks like that fast track is going to bear fruit. How do you feel about that path? Do you think it covers this JIRA issue well enough?

          Show
          Mark Miller added a comment - Chris Hostetter - I'm motivated to get something working here, so I spun off into that other issue to create a fast track path to getting this done. Thanks to some help from Stefan Matheis (steffkes) , it looks like that fast track is going to bear fruit. How do you feel about that path? Do you think it covers this JIRA issue well enough?
          Hide
          Mark Miller added a comment -

          I've spun this part off to SOLR-4943.

          Show
          Mark Miller added a comment - I've spun this part off to SOLR-4943 .
          Hide
          Mark Miller added a comment -

          Afaik the Cloud-Stuff is the only part which gets his data from /solr/zookeeper – Logging loads from /solr/collection1/admin/logging, Java Properties from /solr/collection1/admin/properties and Threads from /solr/collection1/admin/threads
          so, w/o having a least one core initialized .. already the dashboard will have problems, because it actually uses /solr/collection1/admin/system :/

          I'm going to look at adding these to where they belong - off the core admin urls.

          Show
          Mark Miller added a comment - Afaik the Cloud-Stuff is the only part which gets his data from /solr/zookeeper – Logging loads from /solr/collection1/admin/logging, Java Properties from /solr/collection1/admin/properties and Threads from /solr/collection1/admin/threads so, w/o having a least one core initialized .. already the dashboard will have problems, because it actually uses /solr/collection1/admin/system :/ I'm going to look at adding these to where they belong - off the core admin urls.
          Hide
          Mark Miller added a comment -

          Yeah, most people use the rest api for that type of thing - the UI has started adding some stuff, but it's never been the polished path. That's been preconfiguration and rest api.

          It also shouldn't stop working - I see this use case work all the time. I add a core, and the UI starts working.

          Show
          Mark Miller added a comment - Yeah, most people use the rest api for that type of thing - the UI has started adding some stuff, but it's never been the polished path. That's been preconfiguration and rest api. It also shouldn't stop working - I see this use case work all the time. I add a core, and the UI starts working.
          Hide
          Aaron Greenspan added a comment -

          Mark,

          Perhaps it doesn't crash in that it doesn't throw a segmentation fault, but it does throw a Java exception and then stops working, which for a novice user like me means that there is no way to go back and add a core (since the only way I'd know how to do it is through the web UI)--the only way to fix it. And even if there was such a way to add a core, I'd run into issue 4461, and not be able to anyway.

          Aaron

          Show
          Aaron Greenspan added a comment - Mark, Perhaps it doesn't crash in that it doesn't throw a segmentation fault, but it does throw a Java exception and then stops working, which for a novice user like me means that there is no way to go back and add a core (since the only way I'd know how to do it is through the web UI)--the only way to fix it. And even if there was such a way to add a core, I'd run into issue 4461, and not be able to anyway. Aaron
          Hide
          Mark Miller added a comment -

          It doesn't crash - it works as soon as a core is added. We will address this JIRA eventually though.

          Show
          Mark Miller added a comment - It doesn't crash - it works as soon as a core is added. We will address this JIRA eventually though.
          Hide
          Aaron Greenspan added a comment - - edited

          As a new Solr user (4.3.0) I thought I'd remove the example core and create my own. Both of those things turned out to be bad ideas. First, removing the core caused the entire Web UI to irreversibly crash as described in this issue, which I solved just by re-expanding the tarball. (Not a very elegant solution but I had no idea which XML file to manually edit.)

          Then, trying to create a new core one I had the example one back led to this issue... https://issues.apache.org/jira/browse/SOLR-4461

          The web UI looks nice, but to a novice it's basically unusable I'm sad to say.

          Show
          Aaron Greenspan added a comment - - edited As a new Solr user (4.3.0) I thought I'd remove the example core and create my own. Both of those things turned out to be bad ideas. First, removing the core caused the entire Web UI to irreversibly crash as described in this issue, which I solved just by re-expanding the tarball. (Not a very elegant solution but I had no idea which XML file to manually edit.) Then, trying to create a new core one I had the example one back led to this issue... https://issues.apache.org/jira/browse/SOLR-4461 The web UI looks nice, but to a novice it's basically unusable I'm sad to say.
          Hide
          Mark Miller added a comment -

          I just see it as one of a few pieces, but I only updated the existing patch which is essentially just what hossman describes above - I can tweak the UI around, but I don't have any immediate plans to develop any features. Hopefully the guys that have been pushing the UI forward will lend a hand for further work in this area.

          Show
          Mark Miller added a comment - I just see it as one of a few pieces, but I only updated the existing patch which is essentially just what hossman describes above - I can tweak the UI around, but I don't have any immediate plans to develop any features. Hopefully the guys that have been pushing the UI forward will lend a hand for further work in this area.
          Hide
          Mark Bennett added a comment -

          Hi Mark, thanks for the patch.

          I see this:
          + // :TODO: "Add Core" Button

          Any thoughts on that? To me this seems like the most important part of the issue.

          Show
          Mark Bennett added a comment - Hi Mark, thanks for the patch. I see this: + // :TODO: "Add Core" Button Any thoughts on that? To me this seems like the most important part of the issue.
          Hide
          Mark Miller added a comment -

          Here is an updated patch that applies to trunk (just had to fix up app.js)

          Would be great to get more working without an existing core - but it won't be so easy unfortunately...

          Show
          Mark Miller added a comment - Here is an updated patch that applies to trunk (just had to fix up app.js) Would be great to get more working without an existing core - but it won't be so easy unfortunately...
          Hide
          Robert Muir added a comment -

          moving all 4.0 issues not touched in a month to 4.1

          Show
          Robert Muir added a comment - moving all 4.0 issues not touched in a month to 4.1
          Hide
          Robert Muir added a comment -

          rmuir20120906-bulk-40-change

          Show
          Robert Muir added a comment - rmuir20120906-bulk-40-change
          Hide
          Stefan Matheis (steffkes) added a comment -

          Hoss, i'm sorry, didn't had the time to commit the changes, feel free to take the pending issues (SOLR-3633, SOLR-3635 + SOLR-3677) and commit them .. they should be fine - otherwise i'll check them after my vacation

          Show
          Stefan Matheis (steffkes) added a comment - Hoss, i'm sorry, didn't had the time to commit the changes, feel free to take the pending issues ( SOLR-3633 , SOLR-3635 + SOLR-3677 ) and commit them .. they should be fine - otherwise i'll check them after my vacation
          Hide
          Stefan Matheis (steffkes) added a comment -

          [..] i don't think we should rush it or make plans assuming it can be done quickly, because you never know where that code might have a small, crucial, assumption about hte availability of a core. [..]

          oh yeah, don't get me wrong - that wasn't my intention for now .. just a steffkes-don't-know-much-about-internals question to get a feeling if that would be a way we can go .. or not

          in the meantime i've created an patch for SOLR-3635 – the patch (or more precise, the idea of the patch) works for every screen we have .. a normal/complete admin ui as well as the 'error-screens' we have in some cases. the code check's for an existing initFailures object in CoreAdmin-Response and loops over it to collect all given error messages and shows them in an simple list .. either on top of the provided error message or on top of the normal ui-screen (dashboard, logging, ..)

          so, for now, we have:

          Still missing an good idea how we can handle the no-cores case providing a complete ui-frame .. will think about that.

          Show
          Stefan Matheis (steffkes) added a comment - [..] i don't think we should rush it or make plans assuming it can be done quickly, because you never know where that code might have a small, crucial, assumption about hte availability of a core. [..] oh yeah, don't get me wrong - that wasn't my intention for now .. just a steffkes-don't-know-much-about-internals question to get a feeling if that would be a way we can go .. or not in the meantime i've created an patch for SOLR-3635 – the patch (or more precise, the idea of the patch) works for every screen we have .. a normal/complete admin ui as well as the 'error-screens' we have in some cases. the code check's for an existing initFailures object in CoreAdmin-Response and loops over it to collect all given error messages and shows them in an simple list .. either on top of the provided error message or on top of the normal ui-screen (dashboard, logging, ..) so, for now, we have: SOLR-3677 : No Cores at all SOLR-3634 + SOLR-3635 : Init Failures (either w/ or w/o cores) Still missing an good idea how we can handle the no-cores case providing a complete ui-frame .. will think about that.
          Hide
          Hoss Man added a comment -

          is difference between having something "global" (i.e. /solr/zookeeper) instead of relying on some specific core (i.e. /solr/collection1/logs) a difficult change?

          for some things (like /system and /logs) it's probably doable ... but it will definitely take some time and refactoring ... i don't think we should rush it or make plans assuming it can be done quickly, because you never know where that code might have a small, crucial, assumption about hte availability of a core.

          and honestly: the "zero core" situation probably isn't a place where it really makes a lot of sense to focus a lot of effort on having a robust UI. THe important thing is to recognize when the situation arises and give a clear feedback about the with access to the stuff that really matters in that situation (ie: why don't you have any cores? was there an error? how to i add a core?) ... even if that UI is incredibly simplified.

          In my patch, i was trying to maintain the nav links in the left, so new users would at least have a taste for what features the UI offers once cores are added (and so we could have a place to incorporate SOLR-3635) ... but that's certainly not necessary.

          I think the way to go for now is a new, simple, screen w/o any assumptions about anything else that says "You don't have any cores, here's the form to add a core, and BTW here are some known init failures from other cores that might explain why you don't have any cores."

          Show
          Hoss Man added a comment - is difference between having something "global" (i.e. /solr/zookeeper) instead of relying on some specific core (i.e. /solr/collection1/logs) a difficult change? for some things (like /system and /logs) it's probably doable ... but it will definitely take some time and refactoring ... i don't think we should rush it or make plans assuming it can be done quickly, because you never know where that code might have a small, crucial, assumption about hte availability of a core. and honestly: the "zero core" situation probably isn't a place where it really makes a lot of sense to focus a lot of effort on having a robust UI. THe important thing is to recognize when the situation arises and give a clear feedback about the with access to the stuff that really matters in that situation (ie: why don't you have any cores? was there an error? how to i add a core?) ... even if that UI is incredibly simplified. In my patch, i was trying to maintain the nav links in the left, so new users would at least have a taste for what features the UI offers once cores are added (and so we could have a place to incorporate SOLR-3635 ) ... but that's certainly not necessary. I think the way to go for now is a new, simple, screen w/o any assumptions about anything else that says "You don't have any cores, here's the form to add a core, and BTW here are some known init failures from other cores that might explain why you don't have any cores."
          Hide
          Stefan Matheis (steffkes) added a comment - - edited

          Doh, you're right - i missed SOLR-3677 :/ ignore my one, it does more or less exactly the same then yours.

          What i don't know .. is difference between having something "global" (i.e. /solr/zookeeper) instead of relying on some specific core (i.e. /solr/collection1/logs) a difficult change? or is it only kind of "mapping" / changing a listener or whatever?

          Because, if we have all the global ui-options really global (available if we have no cores available) it should be a small(er) chance to type of initial state for the ui – in that case we "only" have to avoid the step where the ui generates the list containing all loaded cores?

          Show
          Stefan Matheis (steffkes) added a comment - - edited Doh, you're right - i missed SOLR-3677 :/ ignore my one, it does more or less exactly the same then yours. What i don't know .. is difference between having something "global" (i.e. /solr/zookeeper ) instead of relying on some specific core (i.e. /solr/collection1/logs ) a difficult change? or is it only kind of "mapping" / changing a listener or whatever? Because, if we have all the global ui-options really global (available if we have no cores available) it should be a small(er) chance to type of initial state for the ui – in that case we "only" have to avoid the step where the ui generates the list containing all loaded cores?
          Hide
          Hoss Man added a comment -

          I'll attach an small and simple patch which also shows an warning screen but with a specific message, for no cores being loaded

          steffkes: I haven't had a chance to look at your patch yet, but it sounds like what i was going for in the SOLR-3677 subtask (i'm assuming your patch is probably better then mine since you actually understand the UI internals and i'm just beating on it with a stick until it kind of looks like what i was hoping for).

          Even if there's no good way to make the bulk of the UI work w/o a Core, i think we should...

          • commit something in SOLR-3677 ASAP to deal with the better "error" message so we're sure it's addressed in 4.0.0
          • wrap up SOLR-3591 in some way that core init errors are visibile in the UI even if there are no cores
          • leave SOLR-3633 open to think about ways to try and make the UI work better with no cores – at a minimum it would be nice to still offer an "Add Core" button, even if it ment having a special "you have no cores, so the ui looks totally diff and all you have is an Add core form" screen.
          Show
          Hoss Man added a comment - I'll attach an small and simple patch which also shows an warning screen but with a specific message, for no cores being loaded steffkes: I haven't had a chance to look at your patch yet, but it sounds like what i was going for in the SOLR-3677 subtask (i'm assuming your patch is probably better then mine since you actually understand the UI internals and i'm just beating on it with a stick until it kind of looks like what i was hoping for). Even if there's no good way to make the bulk of the UI work w/o a Core, i think we should... commit something in SOLR-3677 ASAP to deal with the better "error" message so we're sure it's addressed in 4.0.0 wrap up SOLR-3591 in some way that core init errors are visibile in the UI even if there are no cores leave SOLR-3633 open to think about ways to try and make the UI work better with no cores – at a minimum it would be nice to still offer an "Add Core" button, even if it ment having a special "you have no cores, so the ui looks totally diff and all you have is an Add core form" screen.
          Hide
          Stefan Matheis (steffkes) added a comment -

          Hoss, i'm sorry for the long delay

          I guess i get the idea you're following, but i'm not sure if we are ready for this yet. because almost all "global" actions are using core-specific urls to fetch their information. not because i like to do it like that, just because that's the only way to get this information.

          Afaik the Cloud-Stuff is the only part which gets his data from /solr/zookeeper – Logging loads from /solr/collection1/admin/logging, Java Properties from /solr/collection1/admin/properties and Threads from /solr/collection1/admin/threads

          so, w/o having a least one core initialized .. already the dashboard will have problems, because it actually uses /solr/collection1/admin/system :/

          If we can't make progress on this soon, then it would be best to commit a simpler error check for no cores that hides all the navigation (much like hte current "you need the /admin/ handler") with a clear message that there are no cores

          I would prefer this one (for now), even if i don't like to have it like this (in general). Better to clearly state what's possible and what not .. as in comparison have some "may or may not work - depending on .." state?

          I'll attach an small and simple patch which also shows an warning screen but with a specific message, for no cores being loaded

          Show
          Stefan Matheis (steffkes) added a comment - Hoss, i'm sorry for the long delay I guess i get the idea you're following, but i'm not sure if we are ready for this yet. because almost all "global" actions are using core-specific urls to fetch their information. not because i like to do it like that, just because that's the only way to get this information. Afaik the Cloud-Stuff is the only part which gets his data from /solr/zookeeper – Logging loads from /solr/collection1/admin/logging , Java Properties from /solr/collection1/admin/properties and Threads from /solr/collection1/admin/threads so, w/o having a least one core initialized .. already the dashboard will have problems, because it actually uses /solr/collection1/admin/system :/ If we can't make progress on this soon, then it would be best to commit a simpler error check for no cores that hides all the navigation (much like hte current "you need the /admin/ handler") with a clear message that there are no cores I would prefer this one (for now), even if i don't like to have it like this (in general). Better to clearly state what's possible and what not .. as in comparison have some "may or may not work - depending on .." state? I'll attach an small and simple patch which also shows an warning screen but with a specific message, for no cores being loaded
          Hide
          Hoss Man added a comment -

          I have just enough javascript knowledge to be dangerous....

          Here's my meger attempt at trying to deal with this.

          This patch now:

          • prefers the default core for loading /admin/system
          • includes the URL that failed to load in the error msg if /admin/system couldn't load
          • distinguishes between there not being any cores, and not being able to load /admin/system.

          Un fortunatley, the result is still that the admin UI is virtually useless – my hope was to at least have the "Add Core" button working, but the way/place the core admin buttons are generated is down deep in code for binding to loading the page for a specific core – which in this patch never gets called since there are no cores.

          I've reached the limit of how much i understand this stuff ... maybe someone will find this patch useful and be able to keep going along these lines so that the CoreAdmin stuff at least works, and then the other tabs will start to work once a core is added (allthough i'm not sure how to force all that other data to reload if/when a core is added)

          If we can't make progress on this soon, then it would be best to commit a simpler error check for no cores that hides all the navigation (much like hte current "you need the /admin/ handler") with a clear message that there are no cores

          Show
          Hoss Man added a comment - I have just enough javascript knowledge to be dangerous.... Here's my meger attempt at trying to deal with this. This patch now: prefers the default core for loading /admin/system includes the URL that failed to load in the error msg if /admin/system couldn't load distinguishes between there not being any cores, and not being able to load /admin/system. Un fortunatley, the result is still that the admin UI is virtually useless – my hope was to at least have the "Add Core" button working, but the way/place the core admin buttons are generated is down deep in code for binding to loading the page for a specific core – which in this patch never gets called since there are no cores. I've reached the limit of how much i understand this stuff ... maybe someone will find this patch useful and be able to keep going along these lines so that the CoreAdmin stuff at least works, and then the other tabs will start to work once a core is added (allthough i'm not sure how to force all that other data to reload if/when a core is added) — If we can't make progress on this soon, then it would be best to commit a simpler error check for no cores that hides all the navigation (much like hte current "you need the /admin/ handler") with a clear message that there are no cores
          Hide
          Hoss Man added a comment -

          My full comment about this in SOLR-3591...

          1) the web ui isn't cleaning dealing with the situation where there are "no cores" returned by the CoreAdminHandler.

          this is a legitimate situation, that doesn't neccessarily indicate an error.

          if there are no cores, then the ui shouldn't blindly try to load "/solr/null/admin/system?wt=json" and then complain that the admin handler can't be found – the logic should be something like:

          • can we talk to CoreAdminHandler at all? if not give a specific error
          • if CoreAdminHandler says there are no cores, give a message to that effect
            • offer the info/commands that are stil available (ie: "Core Admin" functionality)
            • perhaps suggesting that if they expected to cores to already exist, they should check logs 9allthough this may not be needed depending on how far we get with "#2" below)
          • if cores are available, then try to use /corename/admin to get the other info to populate the UI, and if we can't find it then mention that they need to add config
            • i would also suggest using the "defaultcore" if non-null instead of just whatever core happens to be listed first (but that's a good fallback if there is no default core)
          Show
          Hoss Man added a comment - My full comment about this in SOLR-3591 ... 1) the web ui isn't cleaning dealing with the situation where there are "no cores" returned by the CoreAdminHandler. this is a legitimate situation, that doesn't neccessarily indicate an error. if there are no cores, then the ui shouldn't blindly try to load "/solr/null/admin/system?wt=json" and then complain that the admin handler can't be found – the logic should be something like: can we talk to CoreAdminHandler at all? if not give a specific error if CoreAdminHandler says there are no cores, give a message to that effect offer the info/commands that are stil available (ie: "Core Admin" functionality) perhaps suggesting that if they expected to cores to already exist, they should check logs 9allthough this may not be needed depending on how far we get with "#2" below) if cores are available, then try to use /corename/admin to get the other info to populate the UI, and if we can't find it then mention that they need to add config i would also suggest using the "defaultcore" if non-null instead of just whatever core happens to be listed first (but that's a good fallback if there is no default core)

            People

            • Assignee:
              Stefan Matheis (steffkes)
              Reporter:
              Hoss Man
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development