Solr
  1. Solr
  2. SOLR-2605

CoreAdminHandler, different Output while 'defaultCoreName' is specified

    Details

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

      Description

      The attached XML-Files show the little difference between a defined defaultCoreName-Attribute and a non existing one.

      Actually the new admin ui checks for an core with empty name to set single- / multicore-settings .. it's a quick change to count the number of defined cores instead.

      But, will it be possible, to get the core-name (again)? One of both attributes would be enough, if that makes a difference

      1. SOLR-2399-admin-cores.xml
        2 kB
        Stefan Matheis (steffkes)
      2. SOLR-2399-admin-cores-default.xml
        2 kB
        Stefan Matheis (steffkes)
      3. SOLR-2605.patch
        6 kB
        Stefan Matheis (steffkes)
      4. SOLR-2605.patch
        7 kB
        Hoss Man

        Issue Links

          Activity

          Hide
          Otis Gospodnetic added a comment -

          Chris Hostetter we were able to reproduce this with Solr 3.6.1. It this something you could backport, so the next 3.6.* release doesn't have this issue?

          Show
          Otis Gospodnetic added a comment - Chris Hostetter we were able to reproduce this with Solr 3.6.1. It this something you could backport, so the next 3.6.* release doesn't have this issue?
          Hide
          Hoss Man added a comment -

          Otis Gospodnetic not sure what to make of annecdotal evidence like that – only took about 10 seconds for me to start up the 4.0-ALPHA example and confirm that /admin/cores returns "collection1" as the name of the only core (even if i point it at an old single-core style solr home dir so that the default hardcoded "SOLR_XML" logic kicks in) ... perhaps your colleague managed to create an actaul core with a name of "" ?

          If you can reproduce, it's a new bug – please file a new jira with the solr.xml, output of /admin/cores, and details on how you got solr into that state.

          Show
          Hoss Man added a comment - Otis Gospodnetic not sure what to make of annecdotal evidence like that – only took about 10 seconds for me to start up the 4.0-ALPHA example and confirm that /admin/cores returns "collection1" as the name of the only core (even if i point it at an old single-core style solr home dir so that the default hardcoded "SOLR_XML" logic kicks in) ... perhaps your colleague managed to create an actaul core with a name of "" ? If you can reproduce, it's a new bug – please file a new jira with the solr.xml, output of /admin/cores, and details on how you got solr into that state.
          Hide
          Otis Gospodnetic added a comment -

          Chris Hostetter & Stefan Matheis (steffkes) - 2 comments:

          1. was this really fixed in Solr 4.0 ALPHA? A colleague checked Solr 4.0 ALPHA for this and still saw a blank name=""
          2. is this back-portable to Solr 3.6.*? It seems 3.6.1 has the same bug.
          Show
          Otis Gospodnetic added a comment - Chris Hostetter & Stefan Matheis (steffkes) - 2 comments: was this really fixed in Solr 4.0 ALPHA? A colleague checked Solr 4.0 ALPHA for this and still saw a blank name="" is this back-portable to Solr 3.6.*? It seems 3.6.1 has the same bug.
          Hide
          Hoss Man added a comment -

          Committed revision 1330028.

          Show
          Hoss Man added a comment - Committed revision 1330028.
          Hide
          Stefan Matheis (steffkes) added a comment -

          Stefan: are you sure you had a clean build with my patch applied?

          You're right .. i had some old stuff in solr/zoo_data which results in duplicate content. Looks still fine, ignore my last comment.

          Show
          Stefan Matheis (steffkes) added a comment - Stefan: are you sure you had a clean build with my patch applied? You're right .. i had some old stuff in solr/zoo_data which results in duplicate content. Looks still fine, ignore my last comment.
          Hide
          Hoss Man added a comment -

          Stefan: are you sure you had a clean build with my patch applied?

          when i run...

          java -DzkRun -Dcollection.configName=myconf -Dbootstrap_confdir=./solr/conf -Dsolr.environment=dev -Duser.timezone=UTC -DhostPort=8983 -Djetty.port=8983 -jar start.jar
          

          I get...

          hossman@bester:~/lucene/dev/solr$ curl "http://localhost:8983/solr/zookeeper?detail=true&path=%2Fclusterstate.json"
          {"znode":{
              "path":"/clusterstate.json","prop":{
                "version":5,
                "aversion":0,
                "children_count":0,
                "ctime":"Fri Apr 13 20:27:46 UTC 2012 (1334348866331)",
                "cversion":0,
                "czxid":12,
                "dataLength":290,
                "ephemeralOwner":0,
                "mtime":"Fri Apr 13 20:45:41 UTC 2012 (1334349941866)",
                "mzxid":207,
                "pzxid":12},
              "data":"{\"collection1\":{\"shard1\":{\"bester:8983_solr_collection1\":{\n        \"shard\":\"shard1\",\n        \"leader\":\"true\",\n        \"state\":\"active\",\n        \"core\":\"collection1\",\n        \"collection\":\"collection1\",\n        \"node_name\":\"bester:8983_solr\",\n        \"base_url\":\"http://bester:8983/solr\"}}}}"},"tree":[{"data":{
                  "title":"/clusterstate.json","attr":{
                    "href":"zookeeper?detail=true&path=%2Fclusterstate.json"}}}]}
          
          Show
          Hoss Man added a comment - Stefan: are you sure you had a clean build with my patch applied? when i run... java -DzkRun -Dcollection.configName=myconf -Dbootstrap_confdir=./solr/conf -Dsolr.environment=dev -Duser.timezone=UTC -DhostPort=8983 -Djetty.port=8983 -jar start.jar I get... hossman@bester:~/lucene/dev/solr$ curl "http://localhost:8983/solr/zookeeper?detail=true&path=%2Fclusterstate.json" {"znode":{ "path":"/clusterstate.json","prop":{ "version":5, "aversion":0, "children_count":0, "ctime":"Fri Apr 13 20:27:46 UTC 2012 (1334348866331)", "cversion":0, "czxid":12, "dataLength":290, "ephemeralOwner":0, "mtime":"Fri Apr 13 20:45:41 UTC 2012 (1334349941866)", "mzxid":207, "pzxid":12}, "data":"{\"collection1\":{\"shard1\":{\"bester:8983_solr_collection1\":{\n \"shard\":\"shard1\",\n \"leader\":\"true\",\n \"state\":\"active\",\n \"core\":\"collection1\",\n \"collection\":\"collection1\",\n \"node_name\":\"bester:8983_solr\",\n \"base_url\":\"http://bester:8983/solr\"}}}}"},"tree":[{"data":{ "title":"/clusterstate.json","attr":{ "href":"zookeeper?detail=true&path=%2Fclusterstate.json"}}}]}
          Hide
          Stefan Matheis (steffkes) added a comment -

          Not sure, where it comes from .. the clusterstate.json file looks like this, using the patch:

          {"collection1":{"shard1":{
                "debian2:8983_solr_":{
                  "shard":"shard1",
                  "state":"active",
                  "core":"",
                  "collection":"collection1",
                  "node_name":"debian2:8983_solr",
                  "base_url":"http://debian2:8983/solr"},
                "debian2:8983_solr_collection1":{
                  "shard":"shard1",
                  "leader":"true",
                  "state":"active",
                  "core":"collection1",
                  "collection":"collection1",
                  "node_name":"debian2:8983_solr",
                  "base_url":"http://debian2:8983/solr"}}}}

          Started with -DzkRun -Dcollection.configName=myconf -Dbootstrap_confdir=./solr/conf -Dsolr.environment=dev -Duser.timezone=UTC -DhostPort=8983 -Djetty.port=8983

          Show
          Stefan Matheis (steffkes) added a comment - Not sure, where it comes from .. the clusterstate.json file looks like this, using the patch: { "collection1" :{ "shard1" :{ "debian2:8983_solr_" :{ "shard" : "shard1" , "state" : "active" , "core" :"", "collection" : "collection1" , "node_name" : "debian2:8983_solr" , "base_url" : "http: //debian2:8983/solr" }, "debian2:8983_solr_collection1" :{ "shard" : "shard1" , "leader" : " true " , "state" : "active" , "core" : "collection1" , "collection" : "collection1" , "node_name" : "debian2:8983_solr" , "base_url" : "http: //debian2:8983/solr" }}}} Started with -DzkRun -Dcollection.configName=myconf -Dbootstrap_confdir=./solr/conf -Dsolr.environment=dev -Duser.timezone=UTC -DhostPort=8983 -Djetty.port=8983
          Hide
          Stefan Matheis (steffkes) added a comment -

          obviously i had no idea where to change things correctly, was just trying to push this a bit forward :/ so i really appreciate your solution! Work's like a charm for me

          Show
          Stefan Matheis (steffkes) added a comment - obviously i had no idea where to change things correctly, was just trying to push this a bit forward :/ so i really appreciate your solution! Work's like a charm for me
          Hide
          Hoss Man added a comment -

          steffkes: your patch applies cleanly, but didn't compile – it looks like you modified some files that weren't included in the patch?

          based on the hoops it looked like you were having to jump through to track this, i looked at where/how/why were were throwing away the core name if it was the default core, and took a crack at just undo-ing that mess so that every core knows it's real and true name – and only the CoreContainer worries about what the name of the default core is – this only required two tweaks to tests (and one of those was to eliminate special hoops TestJmxIntegration was jumping through to get the right name if the core was the default!)

          Once that was done, CoreAdminHandler seemed to return consistent name info in the status for every core, regardless of how many there were, or if a default name was in use. So then since i figured it would be handy, i added the defaultCoreName to the output when you get status for all cores (either a string or null if there is no default core name) and for good measure i also put an "isDefault" boolean in the status for each core.

          try this out and see if does everything you need/want to make the UI go vroom ... like i said, all tests pass for me, but i don't want to commit w/o some review from miller – this fix seems so easy i don't understand why the logic was reversed before, so i'm scared i may be missing something

          Show
          Hoss Man added a comment - steffkes: your patch applies cleanly, but didn't compile – it looks like you modified some files that weren't included in the patch? based on the hoops it looked like you were having to jump through to track this, i looked at where/how/why were were throwing away the core name if it was the default core, and took a crack at just undo-ing that mess so that every core knows it's real and true name – and only the CoreContainer worries about what the name of the default core is – this only required two tweaks to tests (and one of those was to eliminate special hoops TestJmxIntegration was jumping through to get the right name if the core was the default!) Once that was done, CoreAdminHandler seemed to return consistent name info in the status for every core, regardless of how many there were, or if a default name was in use. So then since i figured it would be handy, i added the defaultCoreName to the output when you get status for all cores (either a string or null if there is no default core name) and for good measure i also put an "isDefault" boolean in the status for each core. try this out and see if does everything you need/want to make the UI go vroom ... like i said, all tests pass for me, but i don't want to commit w/o some review from miller – this fix seems so easy i don't understand why the logic was reversed before, so i'm scared i may be missing something
          Hide
          Stefan Matheis (steffkes) added a comment -

          I have to admit, it's my first time .. if it's not usable - for whatever reason - just drop it.

          For me, it was the only possibility to bring back the name - otherwise i will mess up the routing, i'm sure

          Show
          Stefan Matheis (steffkes) added a comment - I have to admit, it's my first time .. if it's not usable - for whatever reason - just drop it. For me, it was the only possibility to bring back the name - otherwise i will mess up the routing, i'm sure
          Hide
          Mark Miller added a comment -

          Indeed - this has always been a bit ugly. Was kind of ease over best approach at the time if I remember right.

          Show
          Mark Miller added a comment - Indeed - this has always been a bit ugly. Was kind of ease over best approach at the time if I remember right.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development