Solr
  1. Solr
  2. SOLR-1722

Allowing changing the "special" default core name, and as a default default core name, switch to using collection1 rather than DEFAULT_CORE

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5, 3.1, 4.0-ALPHA
    • Component/s: None
    • Labels:
      None
    1. SOLR-1722.patch
      2 kB
      Mark Miller
    2. SOLR-1722.patch
      3 kB
      Mark Miller

      Issue Links

        Activity

        Hide
        Mark Miller added a comment -

        Quick patch whipped off to show the idea.

        Show
        Mark Miller added a comment - Quick patch whipped off to show the idea.
        Hide
        Yonik Seeley added a comment -

        I never really looked at the previous implementation of DEFAULT_CORE... but now I see that the default core name (if passed in) is normalized to "".
        Does this have any implications for the default core to also act completely like a normal core? Do bad things happen in we normalized the other way (mapped "" to the defaultCoreName)?

        Show
        Yonik Seeley added a comment - I never really looked at the previous implementation of DEFAULT_CORE... but now I see that the default core name (if passed in) is normalized to "". Does this have any implications for the default core to also act completely like a normal core? Do bad things happen in we normalized the other way (mapped "" to the defaultCoreName)?
        Hide
        Mark Miller added a comment -

        I'll have to check it out a little more - Noble switched this method when we removed alias'.

        As far as I've seen so far, its not a problem. This is how we allow localhost:8983/solr (with no core name) to work currently. But everything I've looked at so far still works if you use localhost:8983/solr/DEFAULT_CORE

        If we mapped the other way we would have to come up with a different method (like alias) to allow localhost:8983/solr for the default core.

        Show
        Mark Miller added a comment - I'll have to check it out a little more - Noble switched this method when we removed alias'. As far as I've seen so far, its not a problem. This is how we allow localhost:8983/solr (with no core name) to work currently. But everything I've looked at so far still works if you use localhost:8983/solr/DEFAULT_CORE If we mapped the other way we would have to come up with a different method (like alias) to allow localhost:8983/solr for the default core.
        Hide
        Yonik Seeley added a comment -

        OK, so normalization to "" instead of the other way (to the non-zero length core name) did end up causing a problem in SolrCloud when we use the core of the request to look up the collection.

        Seems like we should try to normalize the other way, and perhaps do the normalization in the dispatch filter rather than all of the lookup methods in core container?

        Show
        Yonik Seeley added a comment - OK, so normalization to "" instead of the other way (to the non-zero length core name) did end up causing a problem in SolrCloud when we use the core of the request to look up the collection. Seems like we should try to normalize the other way, and perhaps do the normalization in the dispatch filter rather than all of the lookup methods in core container?
        Hide
        Mark Miller added a comment -

        Right - the issue with cloud was that if you ask for the core name, it's known as "" rather than its "other" name.

        So their are def advantages to doing this in the dispatch filter - you can use the non "" name and you can get rid of all the normalization going on in core container -

        the problem is back compat I think - if we just normalize in the DispatchFilter, anyone counting on getting the default core with getCore("") now will have their code broken.

        Show
        Mark Miller added a comment - Right - the issue with cloud was that if you ask for the core name, it's known as "" rather than its "other" name. So their are def advantages to doing this in the dispatch filter - you can use the non "" name and you can get rid of all the normalization going on in core container - the problem is back compat I think - if we just normalize in the DispatchFilter, anyone counting on getting the default core with getCore("") now will have their code broken.
        Hide
        Mark Miller added a comment -

        If no one objects, I'd like to commit this soon. I think its a clear improvement on what is there now, so I'd like to get it in. I think we can talk about how the normalization occurs in another issue.

        Doing things differently has its own back compat issues, and it would be nice if this configurability wasn't caught up in it. Another option we have is to leave the normalization as it is, but just change getName so that it returns the default name rather than "".

        Show
        Mark Miller added a comment - If no one objects, I'd like to commit this soon. I think its a clear improvement on what is there now, so I'd like to get it in. I think we can talk about how the normalization occurs in another issue. Doing things differently has its own back compat issues, and it would be nice if this configurability wasn't caught up in it. Another option we have is to leave the normalization as it is, but just change getName so that it returns the default name rather than "".
        Hide
        Mark Miller added a comment - - edited

        small bug - defaultCoreName is looked for at /solr, but should be /solr/cores - also, defaultCoreName should really not default to DEFAULT_DEFAULT_CORENAME

        Show
        Mark Miller added a comment - - edited small bug - defaultCoreName is looked for at /solr, but should be /solr/cores - also, defaultCoreName should really not default to DEFAULT_DEFAULT_CORENAME
        Hide
        Mark Miller added a comment -

        I'm going to commit this fix a little later today.

        Show
        Mark Miller added a comment - I'm going to commit this fix a little later today.
        Hide
        Hoss Man added a comment -

        Correcting Fix Version based on CHANGES.txt, see this thread for more details...

        http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

        Show
        Hoss Man added a comment - Correcting Fix Version based on CHANGES.txt, see this thread for more details... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E
        Hide
        Ephraim Ofir added a comment - - edited

        Tried using the defaultCoreName attribute on a 2 core setup. After performing a swap, my solr.xml no longer contains the defaultCoreName attribute, and the core which was dafult is now renamed to "", so after restart of the process can't access it by it's former name and can't perform other operations on it such as rename, reload or swap...

        Created new issue for this bug:
        https://issues.apache.org/jira/browse/SOLR-2127

        Show
        Ephraim Ofir added a comment - - edited Tried using the defaultCoreName attribute on a 2 core setup. After performing a swap, my solr.xml no longer contains the defaultCoreName attribute, and the core which was dafult is now renamed to "", so after restart of the process can't access it by it's former name and can't perform other operations on it such as rename, reload or swap... Created new issue for this bug: https://issues.apache.org/jira/browse/SOLR-2127
        Hide
        Mark Miller added a comment -

        Thanks for the report Ephraim, thanks for the report - could you make a new issue for this bug?

        Show
        Mark Miller added a comment - Thanks for the report Ephraim, thanks for the report - could you make a new issue for this bug?
        Hide
        Grant Ingersoll added a comment -

        Bulk close for 3.1.0 release

        Show
        Grant Ingersoll added a comment - Bulk close for 3.1.0 release

          People

          • Assignee:
            Mark Miller
            Reporter:
            Mark Miller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development