Details

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

      Description

      Catch-All Issue for all upcoming Bugs/Reports/Suggestions on the Admin UI

      1. solradminbug.png
        68 kB
        Chun Chen
      2. SOLR-3238.patch
        408 kB
        Stefan Matheis (steffkes)
      3. SOLR-3238.patch
        409 kB
        Stefan Matheis (steffkes)
      4. SOLR-3238.patch
        16 kB
        Stefan Matheis (steffkes)

        Issue Links

          Activity

          Hide
          Uwe Schindler added a comment -

          Closed after release.

          Show
          Uwe Schindler added a comment - Closed after release.
          Hide
          Hoss Man added a comment -

          Doesn't look like there's anything else to do in this issue, any additional work should really be tracked in individual issues.

          steffkes did a bunch of work tracked here that doesn't seem to have ever been recorded in CHANGES.txt, so i went ahead and added a line item about it...

          Committed revision 1379237. trunk
          Committed revision 1379239. 4x

          Show
          Hoss Man added a comment - Doesn't look like there's anything else to do in this issue, any additional work should really be tracked in individual issues. steffkes did a bunch of work tracked here that doesn't seem to have ever been recorded in CHANGES.txt, so i went ahead and added a line item about it... Committed revision 1379237. trunk Committed revision 1379239. 4x
          Hide
          Robert Muir added a comment -

          rmuir20120906-bulk-40-change

          Show
          Robert Muir added a comment - rmuir20120906-bulk-40-change
          Hide
          Hoss Man added a comment -

          bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment

          Show
          Hoss Man added a comment - bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment
          Hide
          Ryan McKinley added a comment -

          My scripts currently use the stats.jsp

          A big goal was to drop the totally untested jsp files and make sure all the logic is in standard request handlers.

          do you know of any documentation that covers everything that's available?

          not really – i suggest looking at the requests with firebug. There are docs on the wiki, but it far from everything

          SolrJ might need a new way to specify the base URL path.

          you should be able to get to anything with existing solrj API, just use solr.setQueryType( "/admin/mbeans" )

          Show
          Ryan McKinley added a comment - My scripts currently use the stats.jsp A big goal was to drop the totally untested jsp files and make sure all the logic is in standard request handlers. do you know of any documentation that covers everything that's available? not really – i suggest looking at the requests with firebug. There are docs on the wiki, but it far from everything SolrJ might need a new way to specify the base URL path. you should be able to get to anything with existing solrj API, just use solr.setQueryType( "/admin/mbeans" )
          Hide
          Shawn Heisey added a comment -

          Yes, use normal solr requests. If you turn on firebug (or equivalent) you can see what the UI is actually calling to get out the machine readable values. For cache stats, that will be something like: http://localhost:8983/solr/admin/mbeans?stats=true&wt=json

          Awesome! I can even use wt=xml and modify my Perl script for any differences between 3.x and 4.x. I have just tried the same URL on 3.x and found that it works there, too. My scripts currently use the stats.jsp and a couple of other URLs, not mbeans. I will have to experiment, but do you know of any documentation that covers everything that's available?

          With SolrJ, currently I can use ModifiableSolrParams and set qt to /admin/mbeans to make this work. In the wake of issues like SOLR-3161, SolrJ might need a new way to specify the base URL path.

          Show
          Shawn Heisey added a comment - Yes, use normal solr requests. If you turn on firebug (or equivalent) you can see what the UI is actually calling to get out the machine readable values. For cache stats, that will be something like: http://localhost:8983/solr/admin/mbeans?stats=true&wt=json Awesome! I can even use wt=xml and modify my Perl script for any differences between 3.x and 4.x. I have just tried the same URL on 3.x and found that it works there, too. My scripts currently use the stats.jsp and a couple of other URLs, not mbeans. I will have to experiment, but do you know of any documentation that covers everything that's available? With SolrJ, currently I can use ModifiableSolrParams and set qt to /admin/mbeans to make this work. In the wake of issues like SOLR-3161 , SolrJ might need a new way to specify the base URL path.
          Hide
          Ryan McKinley added a comment -

          What I needed to check was whether the pages were machine-readable

          The new javascript gets all its data from normal request handlers

          but I need to be able to pull the displayed information out in a machine-readable form as well. Is there any way to do that?

          Yes, use normal solr requests. If you turn on firebug (or equivalent) you can see what the UI is actually calling to get out the machine readable values. For cache stats, that will be something like:
          http://localhost:8983/solr/admin/mbeans?stats=true&wt=json

          Show
          Ryan McKinley added a comment - What I needed to check was whether the pages were machine-readable The new javascript gets all its data from normal request handlers but I need to be able to pull the displayed information out in a machine-readable form as well. Is there any way to do that? Yes, use normal solr requests. If you turn on firebug (or equivalent) you can see what the UI is actually calling to get out the machine readable values. For cache stats, that will be something like: http://localhost:8983/solr/admin/mbeans?stats=true&wt=json
          Hide
          Shawn Heisey added a comment -

          I fired up the example from branch_4x today so I could check something in the new admin GUI, and found a couple of things I thought were worth mentioning.

          What I needed to check was whether the pages were machine-readable. I've currently got an index status page written in Perl that parses the XML output from the current admin GUI on four Solr servers. The new GUI is absolutely beautiful from a human perspective, but I need to be able to pull the displayed information out in a machine-readable form as well. Is there any way to do that?

          The next version of my status page will be written in Java. What kind of options will I have available for retrieving statistical information from a remote Solr instance?

          When I fired up the multicore example, I found that the cache statistics pages for both cores only had fieldCache and fieldValueCache. The documentCache, filterCache, and queryResultCache were not present. If there were other things missing, I didn't notice.

          Show
          Shawn Heisey added a comment - I fired up the example from branch_4x today so I could check something in the new admin GUI, and found a couple of things I thought were worth mentioning. What I needed to check was whether the pages were machine-readable. I've currently got an index status page written in Perl that parses the XML output from the current admin GUI on four Solr servers. The new GUI is absolutely beautiful from a human perspective, but I need to be able to pull the displayed information out in a machine-readable form as well. Is there any way to do that? The next version of my status page will be written in Java. What kind of options will I have available for retrieving statistical information from a remote Solr instance? When I fired up the multicore example, I found that the cache statistics pages for both cores only had fieldCache and fieldValueCache. The documentCache, filterCache, and queryResultCache were not present. If there were other things missing, I didn't notice.
          Hide
          Markus Jelsma added a comment -

          I think it would also be useful to display the shard information in the core overview page such as its ID and whether it is a leader.

          Show
          Markus Jelsma added a comment - I think it would also be useful to display the shard information in the core overview page such as its ID and whether it is a leader.
          Hide
          Stefan Matheis (steffkes) added a comment -

          Being used to the 3x gui, I was initially looking for statistics but didn't find it. I was a little bit surprised to find it under Plugins. I would have expected that section to be called Statistics. If having "plugin" in the name is something you find to be important, perhaps it should be called "Plugin Stats" or "Plugins/Statistics" or something else that makes it clear?

          I don't remember why i started with naming it "Plugins" ;o But i don't mind if we change names, so committed in r1339120 new Name "Plugins / Stats", Statistics is a bit too long and would result in a Two-Liner

          Show
          Stefan Matheis (steffkes) added a comment - Being used to the 3x gui, I was initially looking for statistics but didn't find it. I was a little bit surprised to find it under Plugins. I would have expected that section to be called Statistics. If having "plugin" in the name is something you find to be important, perhaps it should be called "Plugin Stats" or "Plugins/Statistics" or something else that makes it clear? I don't remember why i started with naming it "Plugins" ;o But i don't mind if we change names, so committed in r1339120 new Name "Plugins / Stats", Statistics is a bit too long and would result in a Two-Liner
          Hide
          Stefan Matheis (steffkes) added a comment -

          There's a small issue on the analysis page. After submitting the form with whitespace in the fields they are printed again still being url encoded with + for whitespace.

          Thanks Markus, should be fixed in r1339114

          Show
          Stefan Matheis (steffkes) added a comment - There's a small issue on the analysis page. After submitting the form with whitespace in the fields they are printed again still being url encoded with + for whitespace. Thanks Markus, should be fixed in r1339114
          Hide
          Markus Jelsma added a comment -

          There's a small issue on the analysis page. After submitting the form with whitespace in the fields they are printed again still being url encoded with + for whitespace.

          Show
          Markus Jelsma added a comment - There's a small issue on the analysis page. After submitting the form with whitespace in the fields they are printed again still being url encoded with + for whitespace.
          Hide
          Shawn Heisey added a comment -

          Being used to the 3x gui, I was initially looking for statistics but didn't find it. I was a little bit surprised to find it under Plugins. I would have expected that section to be called Statistics. If having "plugin" in the name is something you find to be important, perhaps it should be called "Plugin Stats" or "Plugins/Statistics" or something else that makes it clear?

          Show
          Shawn Heisey added a comment - Being used to the 3x gui, I was initially looking for statistics but didn't find it. I was a little bit surprised to find it under Plugins. I would have expected that section to be called Statistics. If having "plugin" in the name is something you find to be important, perhaps it should be called "Plugin Stats" or "Plugins/Statistics" or something else that makes it clear?
          Hide
          Shawn Heisey added a comment -

          I have just fired up the example from a trunk checkout that's a day or two old and taken a quick look.

          On the analysis page: Is it possible to have the information fields always appear in the same order? That order is up to you, I just want it to be consistent. I just ran an analysis on the title field in the trunk example and the first step in the output was in this order: text, start, end, type, position. The other two steps were ordered like this: text, position, start, end, type. At first I thought that the position had disappeared after the first step, then I noticed it was still there, just in a different place.

          On the logging page: Many of the settings show null, italicized. This would be fine, except that when you click on one, null is not one of the choices. You have to choose UNSET to keep the setting the same. One of them needs to change to match the other. My thought is that in both places it should be "unset" or "not set" – lowercase and italicized.

          On the Plugins page under the core: You can't open more than one of the dropdown items at once, and you can't close a dropdown once it's open. It's very helpful for me to be able to see more than one set of cache statistics at the same time. If you can open more than one of them, you need to be able to close them as well.

          Show
          Shawn Heisey added a comment - I have just fired up the example from a trunk checkout that's a day or two old and taken a quick look. On the analysis page: Is it possible to have the information fields always appear in the same order? That order is up to you, I just want it to be consistent. I just ran an analysis on the title field in the trunk example and the first step in the output was in this order: text, start, end, type, position. The other two steps were ordered like this: text, position, start, end, type. At first I thought that the position had disappeared after the first step, then I noticed it was still there, just in a different place. On the logging page: Many of the settings show null, italicized. This would be fine, except that when you click on one, null is not one of the choices. You have to choose UNSET to keep the setting the same. One of them needs to change to match the other. My thought is that in both places it should be "unset" or "not set" – lowercase and italicized. On the Plugins page under the core: You can't open more than one of the dropdown items at once, and you can't close a dropdown once it's open. It's very helpful for me to be able to see more than one set of cache statistics at the same time. If you can open more than one of them, you need to be able to close them as well.
          Hide
          Stefan Matheis (steffkes) added a comment -

          cloud/zookeeper-data cannot show the node tree as the previous version.It says 'Fetch zookeeper data'without showing anything of the solr node.

          Sorry Emma, i overlooked your comment - is it still not working for you?

          Show
          Stefan Matheis (steffkes) added a comment - cloud/zookeeper-data cannot show the node tree as the previous version.It says 'Fetch zookeeper data'without showing anything of the solr node. Sorry Emma, i overlooked your comment - is it still not working for you?
          Hide
          Stefan Matheis (steffkes) added a comment -

          I'm not sure what issue to attach this to, so it may make sense to make a new issue. Here is general wishlist of things I think would help...

          • From the analysis page, can there be a link to the relevant field/fieldType in schema-browser?
          • From the schema-browser, can there be a link to the analysis page (with the right field selected?) Perhaps the text "Index Analyzer" and "Query Analyzer" could be links
          • In the schema-browser, when you click on a term, it loads in the query window, it should also execute the query!
          • Why does Autoload™ have a tm?
          • I assume Autoload is writing a cookie... can it also keep the number of terms? Perhaps also the checked state on analysis verbose output?
          • On the schema-browser page, the text "Index Analyzer" shows up on one line, but "Query Analyzer" gets broken into two lines.
          • When showing the number of matching Docs for a field, can the number be a link to a query? For example with the field "id", the link can be to: q=id:[* TO *]
          • The plural names in schema-browser are inappropriate at times – not a big deal, but if we replaced "Fields/Types" with "Field:/Type:" I think it works OK in both singular and plural cases
          • In the plugin page, there are lots of URLs that would be great if they were actually URLS. When we show a link to "http://wiki.apache.org/solr/StandardRequestHandler" that should be a real URL

          All of them changed.

          • I assume Autoload is writing a cookie... can it also keep the number of terms? Perhaps also the checked state on analysis verbose output?
          • When showing the number of matching Docs for a field, can the number be a link to a query? For example with the field "id", the link can be to: q=id:[* TO *]

          Schema-Browser/Autoload was already using a cookie, Analysis/Verbose now too. Schema-Browser got a separate "Query"-Link in the TopTerms-Section. In the first row "[NN]/NN Top-Terms" the second Number is already a link to load all Top-Terms, therefore i couldn't change this one into a link to the Query.

          If we'd like to have a possibility to load every time all available Top-Terms, we could add another checkbox (right below the "[_] Autoload" one?

          Show
          Stefan Matheis (steffkes) added a comment - I'm not sure what issue to attach this to, so it may make sense to make a new issue. Here is general wishlist of things I think would help... From the analysis page, can there be a link to the relevant field/fieldType in schema-browser? From the schema-browser, can there be a link to the analysis page (with the right field selected?) Perhaps the text "Index Analyzer" and "Query Analyzer" could be links In the schema-browser, when you click on a term, it loads in the query window, it should also execute the query! Why does Autoload™ have a tm? I assume Autoload is writing a cookie... can it also keep the number of terms? Perhaps also the checked state on analysis verbose output? On the schema-browser page, the text "Index Analyzer" shows up on one line, but "Query Analyzer" gets broken into two lines. When showing the number of matching Docs for a field, can the number be a link to a query? For example with the field "id", the link can be to: q=id: [* TO *] The plural names in schema-browser are inappropriate at times – not a big deal, but if we replaced "Fields/Types" with "Field:/Type:" I think it works OK in both singular and plural cases In the plugin page, there are lots of URLs that would be great if they were actually URLS. When we show a link to "http://wiki.apache.org/solr/StandardRequestHandler" that should be a real URL All of them changed. I assume Autoload is writing a cookie... can it also keep the number of terms? Perhaps also the checked state on analysis verbose output? When showing the number of matching Docs for a field, can the number be a link to a query? For example with the field "id", the link can be to: q=id: [* TO *] Schema-Browser/Autoload was already using a cookie, Analysis/Verbose now too. Schema-Browser got a separate "Query"-Link in the TopTerms-Section. In the first row " [NN] /NN Top-Terms" the second Number is already a link to load all Top-Terms, therefore i couldn't change this one into a link to the Query. If we'd like to have a possibility to load every time all available Top-Terms, we could add another checkbox (right below the " [_] Autoload" one?
          Hide
          Ryan McKinley added a comment -

          I like the idea of adding version to the param string – that could be initalized in index.html too

          Show
          Ryan McKinley added a comment - I like the idea of adding version to the param string – that could be initalized in index.html too
          Hide
          David Smiley added a comment -

          I didn't know Firebug could do that, although this doesn't completely address the issue. I didn't set out to do Solr development today, I merely wanted to see the latest UI so I could do a screen capture. Looking at Firebug when I was diagnosing this, showed that it decided to cache the stuff for a few days on me – I forget how long exactly.

          Another option to solve this well-known problem (this is hardly specific to Solr) is to attach a nonce query parameter to the static resources. This nonce could be the Solr build release string seen on the front string. Essentially when a template is requested, it would request /solr/tpl/query.html?nonce=4.0.0.2012.04.25.16.10.30

          Show
          David Smiley added a comment - I didn't know Firebug could do that, although this doesn't completely address the issue. I didn't set out to do Solr development today, I merely wanted to see the latest UI so I could do a screen capture. Looking at Firebug when I was diagnosing this, showed that it decided to cache the stuff for a few days on me – I forget how long exactly. Another option to solve this well-known problem (this is hardly specific to Solr) is to attach a nonce query parameter to the static resources. This nonce could be the Solr build release string seen on the front string. Essentially when a template is requested, it would request /solr/tpl/query.html?nonce=4.0.0.2012.04.25.16.10.30
          Hide
          Ryan McKinley added a comment -

          For the real release we want a long cache. (though it is an admin UI, so its not all that important)

          for JS dev, can't you just disable HTTP cache in FF/firebug?

          Show
          Ryan McKinley added a comment - For the real release we want a long cache. (though it is an admin UI, so its not all that important) for JS dev, can't you just disable HTTP cache in FF/firebug?
          Hide
          David Smiley added a comment -

          Jetty's "DefaultServlet" serves static content, such as the CSS, Solr logo, and all the page templates. Any dynamically generated data, such as what comes from Solr itself via its request handlers, don't apply to what I propose.

          You should know that the "load term info" information is not cached by the browser; it re-requests it every time it is asked for, just like any other request to Solr itself, given Solr's default HTTP cache settings (which is not to cache). There might be caching on the Solr side but I doubt it.

          Show
          David Smiley added a comment - Jetty's "DefaultServlet" serves static content , such as the CSS, Solr logo, and all the page templates. Any dynamically generated data, such as what comes from Solr itself via its request handlers, don't apply to what I propose. You should know that the "load term info" information is not cached by the browser; it re-requests it every time it is asked for, just like any other request to Solr itself, given Solr's default HTTP cache settings (which is not to cache). There might be caching on the Solr side but I doubt it.
          Hide
          Erick Erickson added a comment -

          My only concern is that the schema browser page. The calls to calculate some of the stats, particularly the "load term info" button can be quite expensive on large systems; to get the top terms you have to spin through all the terms in the field. But otherwise, I'd call a fast age-out a feature,

          Now, I know very little about jetty configuration so this may be all wet, but aging out that information quickly would make the schema-browser part of the UI quite hard to use.

          Show
          Erick Erickson added a comment - My only concern is that the schema browser page. The calls to calculate some of the stats, particularly the "load term info" button can be quite expensive on large systems; to get the top terms you have to spin through all the terms in the field. But otherwise, I'd call a fast age-out a feature, Now, I know very little about jetty configuration so this may be all wet, but aging out that information quickly would make the schema-browser part of the UI quite hard to use.
          Hide
          David Smiley added a comment -

          Given how easy it is to stop Solr and potentially bring up a different Solr version at the same URL in very little time, perhaps max-age should be 10 seconds.

          Show
          David Smiley added a comment - Given how easy it is to stop Solr and potentially bring up a different Solr version at the same URL in very little time, perhaps max-age should be 10 seconds.
          Hide
          David Smiley added a comment -

          Since more of the UI is now actually loaded asynchronously, it is subject to the jetty's DefaultServlet cacheing headers, which are non-existent by default. I found it highly annoying today when I updated Solr to find that the UI wasn't updated, even when I told my browser to force-reload. I had to clear my browser cache. I looked into this a bit and I propose that example/etc/webdefault.xml has the "cacheControl" piece of it be un-commented, and set the max-age to 60 (in seconds). It is unlikely the timespan between a browser requesting it and Solr being shut down, updated, redeployed, and the browser fetches it again. Possible but unlikely. When this time span is exceeded, a browser would re-request the resources but it would get back a small 304 status to indicate the file hasn't changed, assuming it hasn't. To be clear, this applies to the admin UI in the out-of-the-box jetty configuration, and doesn't apply to searches. Sound good? I can commit it trivially.

          Show
          David Smiley added a comment - Since more of the UI is now actually loaded asynchronously, it is subject to the jetty's DefaultServlet cacheing headers, which are non-existent by default. I found it highly annoying today when I updated Solr to find that the UI wasn't updated, even when I told my browser to force-reload. I had to clear my browser cache. I looked into this a bit and I propose that example/etc/webdefault.xml has the "cacheControl" piece of it be un-commented, and set the max-age to 60 (in seconds). It is unlikely the timespan between a browser requesting it and Solr being shut down, updated, redeployed, and the browser fetches it again. Possible but unlikely. When this time span is exceeded, a browser would re-request the resources but it would get back a small 304 status to indicate the file hasn't changed, assuming it hasn't. To be clear, this applies to the admin UI in the out-of-the-box jetty configuration, and doesn't apply to searches. Sound good? I can commit it trivially.
          Hide
          Erick Erickson added a comment -

          dylan:

          How are you looking at your log? Because when I try cut/paste of your string in the admin analysis page, the return display in the admin UI has the characters correctly displayed, identified as IDEOGRAPHIC with raw byte sequences like: 'e4 b8 ad' and 'e6 96 87' (which I admit I haven't a clue whether they're correct or not). But the log shows gibberish (Jetty).

          So my assumption here would be that the admin UI is fine, but the characters are being munged somewhere else, perhaps logging? Perhaps settings for your display in your editor or terminal session?

          Of course I could be all wet here.

          Show
          Erick Erickson added a comment - dylan: How are you looking at your log? Because when I try cut/paste of your string in the admin analysis page, the return display in the admin UI has the characters correctly displayed, identified as IDEOGRAPHIC with raw byte sequences like: 'e4 b8 ad' and 'e6 96 87' (which I admit I haven't a clue whether they're correct or not). But the log shows gibberish (Jetty). So my assumption here would be that the admin UI is fine, but the characters are being munged somewhere else, perhaps logging? Perhaps settings for your display in your editor or terminal session? Of course I could be all wet here.
          Hide
          dylan added a comment -

          Chinese words collected by admin ui are not correctly recognized by /analysis/field or /select.
          1. open admin ui. Singlre Core > Query.
          add q: name:中文
          and I get the following information in tomcat's log:
          path=/select params=

          {wt=xml&rows=10&start=0&q=name:?????¥}

          hits=0 status=0 QTime=2

          2. open admin ui. Singlre Core > Analysis.
          FieldValue: 中文
          and I get the following information in tomcat's log:
          path=/analysis/field params=

          {analysis.showmatch=true&analysis.query=&analysis.fieldname=ageseg&analysis.fieldvalue=?????¥&wt=json}

          status=0 QTime=2

          Show
          dylan added a comment - Chinese words collected by admin ui are not correctly recognized by /analysis/field or /select. 1. open admin ui. Singlre Core > Query. add q: name:中文 and I get the following information in tomcat's log: path=/select params= {wt=xml&rows=10&start=0&q=name:?????¥} hits=0 status=0 QTime=2 2. open admin ui. Singlre Core > Analysis. FieldValue: 中文 and I get the following information in tomcat's log: path=/analysis/field params= {analysis.showmatch=true&analysis.query=&analysis.fieldname=ageseg&analysis.fieldvalue=?????¥&wt=json} status=0 QTime=2
          Hide
          Benson Margulies added a comment -

          It would be nice to see a total document count across the shards.

          Show
          Benson Margulies added a comment - It would be nice to see a total document count across the shards.
          Hide
          Ryan McKinley added a comment -

          Here are some smaller issues to track

          Show
          Ryan McKinley added a comment - Here are some smaller issues to track
          Hide
          Chris Male added a comment -

          Perhaps its useful to have a few sub-tasks for each of these? Then we don't have a single issue with lots of disconnected patches and comments.

          Show
          Chris Male added a comment - Perhaps its useful to have a few sub-tasks for each of these? Then we don't have a single issue with lots of disconnected patches and comments.
          Hide
          Ryan McKinley added a comment -

          I'm not sure what issue to attach this to, so it may make sense to make a new issue. Here is general wishlist of things I think would help...

          • From the analysis page, can there be a link to the relevant field/fieldType in schema-browser?
          • From the schema-browser, can there be a link to the analysis page (with the right field selected?) Perhaps the text "Index Analyzer" and "Query Analyzer" could be links
          • In the schema-browser, when you click on a term, it loads in the query window, it should also execute the query!
          • Why does Autoload™ have a tm?
          • I assume Autoload is writing a cookie... can it also keep the number of terms? Perhaps also the checked state on analysis verbose output?
          • On the schema-browser page, the text "Index Analyzer" shows up on one line, but "Query Analyzer" gets broken into two lines.
          • When showing the number of matching Docs for a field, can the number be a link to a query? For example with the field "id", the link can be to: q=id:[* TO *]
          • The plural names in schema-browser are inappropriate at times – not a big deal, but if we replaced "Fields/Types" with "Field:/Type:" I think it works OK in both singular and plural cases
          • In the plugin page, there are lots of URLs that would be great if they were actually URLS. When we show a link to "http://wiki.apache.org/solr/StandardRequestHandler" that should be a real URL

          Things are really looking great!

          Show
          Ryan McKinley added a comment - I'm not sure what issue to attach this to, so it may make sense to make a new issue. Here is general wishlist of things I think would help... From the analysis page, can there be a link to the relevant field/fieldType in schema-browser? From the schema-browser, can there be a link to the analysis page (with the right field selected?) Perhaps the text "Index Analyzer" and "Query Analyzer" could be links In the schema-browser, when you click on a term, it loads in the query window, it should also execute the query! Why does Autoload™ have a tm? I assume Autoload is writing a cookie... can it also keep the number of terms? Perhaps also the checked state on analysis verbose output? On the schema-browser page, the text "Index Analyzer" shows up on one line, but "Query Analyzer" gets broken into two lines. When showing the number of matching Docs for a field, can the number be a link to a query? For example with the field "id", the link can be to: q=id: [* TO *] The plural names in schema-browser are inappropriate at times – not a big deal, but if we replaced "Fields/Types" with "Field:/Type:" I think it works OK in both singular and plural cases In the plugin page, there are lots of URLs that would be great if they were actually URLS. When we show a link to "http://wiki.apache.org/solr/StandardRequestHandler" that should be a real URL Things are really looking great!
          Hide
          Emma Bo Liu added a comment -

          when accessing the solr new admin UI http://localhost:8983/solr/#/cloud, the error message window pop up saying ' 500 error get#/cloud cannot call method 'attr' of undefined

          Show
          Emma Bo Liu added a comment - when accessing the solr new admin UI http://localhost:8983/solr/#/cloud , the error message window pop up saying ' 500 error get#/cloud cannot call method 'attr' of undefined
          Hide
          Emma Bo Liu added a comment -

          cloud/zookeeper-data cannot show the node tree as the previous version.It says 'Fetch zookeeper data'without showing anything of the solr node.

          Show
          Emma Bo Liu added a comment - cloud/zookeeper-data cannot show the node tree as the previous version.It says 'Fetch zookeeper data'without showing anything of the solr node.
          Hide
          Stefan Matheis (steffkes) added a comment -

          New Issue?

          Vadim, i think that would make sense yes

          The Code which shows the error message you've mentioned on the first comment, is this one: https://github.com/steffkes/solr-admin/blob/master/js/scripts/app.js#L212 - it's requesting /admin/system

          Show
          Stefan Matheis (steffkes) added a comment - New Issue? Vadim, i think that would make sense yes The Code which shows the error message you've mentioned on the first comment, is this one: https://github.com/steffkes/solr-admin/blob/master/js/scripts/app.js#L212 - it's requesting /admin/system
          Hide
          Stefan Matheis (steffkes) added a comment -

          Committed in revision 1303326

          Show
          Stefan Matheis (steffkes) added a comment - Committed in revision 1303326
          Hide
          Stefan Matheis (steffkes) added a comment -

          Updated Patch, will commit soon

          Show
          Stefan Matheis (steffkes) added a comment - Updated Patch, will commit soon
          Hide
          Ryan McKinley added a comment -

          +1

          Stefan – go ahead and commit!

          Show
          Ryan McKinley added a comment - +1 Stefan – go ahead and commit!
          Hide
          Stefan Matheis (steffkes) added a comment -

          Chen, that's correct .. i've fixed that already a few days ago while improving the handling of dataimports. Actually preparing the patch which includes this change.

          Show
          Stefan Matheis (steffkes) added a comment - Chen, that's correct .. i've fixed that already a few days ago while improving the handling of dataimports. Actually preparing the patch which includes this change.
          Hide
          Chun Chen added a comment -

          Have a look at "solradminbug.png".
          I have no idea what's wrong with it. Are the "start" or "rows" parameters essential?
          but if i use "curl http://dog:8983/solr/dataimport?command=full-import", that is ok.

          Show
          Chun Chen added a comment - Have a look at "solradminbug.png". I have no idea what's wrong with it. Are the "start" or "rows" parameters essential? but if i use "curl http://dog:8983/solr/dataimport?command=full-import ", that is ok.
          Hide
          Aliaksandr Zhuhrou added a comment - - edited

          As a suggestion can we allow specify default Query Response Writer. I am using a custom writer which is default response writer and I can't select it using an admin interface. Can we add a option "default" to the WT select on query tab which forces Solr to use the default one? Also I think we can build a select list directly from the current solr configuration.

          Show
          Aliaksandr Zhuhrou added a comment - - edited As a suggestion can we allow specify default Query Response Writer. I am using a custom writer which is default response writer and I can't select it using an admin interface. Can we add a option "default" to the WT select on query tab which forces Solr to use the default one? Also I think we can build a select list directly from the current solr configuration.
          Hide
          Vadim Kisselmann added a comment - - edited

          Now i have error messages:

          SCHWERWIEGEND: The web application [/solr2] appears to have started a thread named [main-SendThread(zookeeper:2181)] but has failed to stop it. This is very likely to create a memory leak.
          Exception in thread "Thread-2" java.lang.NullPointerException
          at org.apache.solr.cloud.Overseer$CloudStateUpdater.amILeader(Overseer.java:179)
          at org.apache.solr.cloud.Overseer$CloudStateUpdater.run(Overseer.java:104)
          at java.lang.Thread.run(Thread.java:662)
          15.03.2012 13:25:17 org.apache.catalina.loader.WebappClassLoader loadClass
          INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.zookeeper.server.ZooTrace. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
          java.lang.IllegalStateException
          at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1531)
          at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1491)
          at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1196)
          15.03.2012 13:25:17 org.apache.coyote.http11.Http11Protocol destroy

          SLF4J: The requested version 1.5.8 by your slf4j binding is not compatible with [1.6]
          SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details.
          log4j:WARN No appenders could be found for logger (org.apache.solr.core.SolrResourceLoader).
          log4j:WARN Please initialize the log4j system properly.

          Steps:
          I deleted the one default core in solr.xml, because i would create new cores with CoreAdminHandler.
          I started tomcat.
          Now it's completely broken. Rebuild and restart, whether jetty or tomcat, change nothing.

          EDIT:
          i get the same problem on another server(tomcat, sharded, without ZK). With an old revision from Feb. it works,
          with new checkout from trunk not.

          EDIT2:
          It works when i remove the example-folder, checkout new version from trunk and rebuild it. i think it's a problem
          with solr.xml. On server-restart it breaks. With older revisions like r1292064 from Feb. it works.
          I think you're right, this has nothing to do with the admin UI. Sorry for spam here.
          New Issue?

          Show
          Vadim Kisselmann added a comment - - edited Now i have error messages: SCHWERWIEGEND: The web application [/solr2] appears to have started a thread named [main-SendThread(zookeeper:2181)] but has failed to stop it. This is very likely to create a memory leak. Exception in thread "Thread-2" java.lang.NullPointerException at org.apache.solr.cloud.Overseer$CloudStateUpdater.amILeader(Overseer.java:179) at org.apache.solr.cloud.Overseer$CloudStateUpdater.run(Overseer.java:104) at java.lang.Thread.run(Thread.java:662) 15.03.2012 13:25:17 org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.zookeeper.server.ZooTrace. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. java.lang.IllegalStateException at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1531) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1491) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1196) 15.03.2012 13:25:17 org.apache.coyote.http11.Http11Protocol destroy SLF4J: The requested version 1.5.8 by your slf4j binding is not compatible with [1.6] SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details. log4j:WARN No appenders could be found for logger (org.apache.solr.core.SolrResourceLoader). log4j:WARN Please initialize the log4j system properly. Steps: I deleted the one default core in solr.xml, because i would create new cores with CoreAdminHandler. I started tomcat. Now it's completely broken. Rebuild and restart, whether jetty or tomcat, change nothing. EDIT: i get the same problem on another server(tomcat, sharded, without ZK). With an old revision from Feb. it works, with new checkout from trunk not. EDIT2: It works when i remove the example-folder, checkout new version from trunk and rebuild it. i think it's a problem with solr.xml. On server-restart it breaks. With older revisions like r1292064 from Feb. it works. I think you're right, this has nothing to do with the admin UI. Sorry for spam here. New Issue?
          Hide
          Vadim Kisselmann added a comment - - edited

          It's weird

          "ant run-example" starts server with jetty, and it works.
          As next step i build it one more time with "ant example" and start my tomcat, and it works, too.

          When i update to new Solr version from trunk, and build it with "ant example", i get this error again.

          EDIT: no errors at this time in my log files.

          Show
          Vadim Kisselmann added a comment - - edited It's weird "ant run-example" starts server with jetty, and it works. As next step i build it one more time with "ant example" and start my tomcat, and it works, too. When i update to new Solr version from trunk, and build it with "ant example", i get this error again. EDIT: no errors at this time in my log files.
          Hide
          Uwe Schindler added a comment - - edited

          I got this error with trunk checkout using "ant run-example", too. But only on the first run, later runs work.

          EDIT: I think this has nothing to do with the admin UI. When this happened, I got some Exceptions in the startup of Solr. Can you check for them in the logs? Unfortunately I cannot reproduce at the moment.

          Show
          Uwe Schindler added a comment - - edited I got this error with trunk checkout using "ant run-example", too. But only on the first run, later runs work. EDIT: I think this has nothing to do with the admin UI. When this happened, I got some Exceptions in the startup of Solr. Can you check for them in the logs? Unfortunately I cannot reproduce at the moment.
          Hide
          Vadim Kisselmann added a comment -

          I use Solr 4.0 from trunk(latest) with tomcat6.

          I get an error in New Admin UI (since one week, i update every day from trunk):

          This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:
          <!-- Admin Handlers - This will register all the standard admin RequestHandlers. -->
          <requestHandler name="/admin/" class="solr.admin.AdminHandlers" />

          Admin request Handlers are definitely activated in my solrconfig.

          Show
          Vadim Kisselmann added a comment - I use Solr 4.0 from trunk(latest) with tomcat6. I get an error in New Admin UI (since one week, i update every day from trunk): This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml: <!-- Admin Handlers - This will register all the standard admin RequestHandlers. --> <requestHandler name="/admin/" class="solr.admin.AdminHandlers" /> Admin request Handlers are definitely activated in my solrconfig.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development