Solr
  1. Solr
  2. SOLR-1621

Allow current single core deployments to be specified by solr.xml

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5
    • Fix Version/s: 1.5, 3.1, 4.0-ALPHA
    • Component/s: None
    • Labels:
      None

      Description

      supporting two different modes of deployments is turning out to be hard. This leads to duplication of code. Moreover there is a lot of confusion on where do we put common configuration. See the mail thread http://markmail.org/message/3m3rqvp2ckausjnf

      1. SOLR-1621.patch
        9 kB
        Noble Paul
      2. SOLR-1621.patch
        13 kB
        Mark Miller
      3. SOLR-1621.patch
        14 kB
        Mark Miller
      4. SOLR-1621.patch
        14 kB
        Mark Miller
      5. SOLR-1621.patch
        14 kB
        Noble Paul
      6. SOLR-1621.patch
        14 kB
        Noble Paul
      7. SOLR-1621.patch
        19 kB
        Noble Paul
      8. SOLR-1621.patch
        17 kB
        Mark Miller
      9. SOLR-1621.patch
        18 kB
        Mark Miller
      10. SOLR-1621.patch
        19 kB
        Noble Paul

        Issue Links

        There are no Sub-Tasks for this issue.

          Activity

          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
          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
          Noble Paul added a comment -

          committed r890675

          Show
          Noble Paul added a comment - committed r890675
          Hide
          Noble Paul added a comment -

          Throw a message saying 'ALIAS is removed' when ALIAS is invoked

          Show
          Noble Paul added a comment - Throw a message saying 'ALIAS is removed' when ALIAS is invoked
          Hide
          Noble Paul added a comment -

          I shall soon give a final patch w/ the removal of ALIAS.

          Show
          Noble Paul added a comment - I shall soon give a final patch w/ the removal of ALIAS.
          Hide
          Mark Miller added a comment -

          The patch looks fine . I plan to commit it soon

          I still think we need to do something about handleAliasAction - possibly just remove it. It's not really a deprecation like it says - if someone overrode it, its no longer called. Better to get a hard error.

          Show
          Mark Miller added a comment - The patch looks fine . I plan to commit it soon I still think we need to do something about handleAliasAction - possibly just remove it. It's not really a deprecation like it says - if someone overrode it, its no longer called. Better to get a hard error.
          Hide
          Mark Miller added a comment -

          me too. But this looked like an exception. This is rarely used (if at all) and according to me is a bad feature because it needs editing web.xml .

          Thats fine - as long as we have good warnings, I'm fine with removing it - but we must have a replacement for the tests that count on this feature.

          Show
          Mark Miller added a comment - me too. But this looked like an exception. This is rarely used (if at all) and according to me is a bad feature because it needs editing web.xml . Thats fine - as long as we have good warnings, I'm fine with removing it - but we must have a replacement for the tests that count on this feature.
          Hide
          Noble Paul added a comment -

          The patch looks fine . I plan to commit it soon

          Show
          Noble Paul added a comment - The patch looks fine . I plan to commit it soon
          Hide
          Noble Paul added a comment -

          Personally, I'd prefer a form of deprecation first.

          me too. But this looked like an exception. This is rarely used (if at all) and according to me is a bad feature because it needs editing web.xml .

          At a minimum, it needs to be its own issue so that the warning to users that they need to change what they are doing is very clear.

          There is another issue now SOLR-1647 .I should change the language. they are really not deprecations.

          Ok . I can go both ways on this. we can keep the feature deprecated and remove it later or remove it right away. My preference would be to remove it.

          Show
          Noble Paul added a comment - Personally, I'd prefer a form of deprecation first. me too. But this looked like an exception. This is rarely used (if at all) and according to me is a bad feature because it needs editing web.xml . At a minimum, it needs to be its own issue so that the warning to users that they need to change what they are doing is very clear. There is another issue now SOLR-1647 .I should change the language. they are really not deprecations. Ok . I can go both ways on this. we can keep the feature deprecated and remove it later or remove it right away. My preference would be to remove it.
          Hide
          Mark Miller added a comment -

          The setSolrConfigFilename() did not work for multicore .

          But it did work for single core, and we are emulating that. I agree that it should be removed, but perhaps not in how. I think it should go away with warning - and I don't think we should mark something as deprecated when it just no longer works - deprecation means the method should still work. Also, I'm not sure if you have realized it yet, but tests currently rely on this functionality - it cannot be pulled without replacing the functionality for tests in some manner.

          So it does not make sense for us to bend over backwards to make it work in this and add too many overloaded methods.

          It doesn't require bending over backwards. It doesn't even require overloaded methods (see my latest patch) - that was just one method.

          Anyway, users won't need

          Its not about users needing this - they won't need it because they can now use solr.xml - its about functionality that someone is currently counting on simply disappearing. Personally, I'd prefer a form of deprecation first. At a minimum, it needs to be its own issue so that the warning to users that they need to change what they are doing is very clear.

          Show
          Mark Miller added a comment - The setSolrConfigFilename() did not work for multicore . But it did work for single core, and we are emulating that. I agree that it should be removed, but perhaps not in how. I think it should go away with warning - and I don't think we should mark something as deprecated when it just no longer works - deprecation means the method should still work. Also, I'm not sure if you have realized it yet, but tests currently rely on this functionality - it cannot be pulled without replacing the functionality for tests in some manner. So it does not make sense for us to bend over backwards to make it work in this and add too many overloaded methods. It doesn't require bending over backwards. It doesn't even require overloaded methods (see my latest patch) - that was just one method. Anyway, users won't need Its not about users needing this - they won't need it because they can now use solr.xml - its about functionality that someone is currently counting on simply disappearing. Personally, I'd prefer a form of deprecation first. At a minimum, it needs to be its own issue so that the warning to users that they need to change what they are doing is very clear.
          Hide
          Noble Paul added a comment -

          I guess deprecating ALIAS can be committed first so that the changes for this issue will be smaller and more manageable

          Show
          Noble Paul added a comment - I guess deprecating ALIAS can be committed first so that the changes for this issue will be smaller and more manageable
          Hide
          Noble Paul added a comment -

          You mark setSolrConfigFilename as deprecated, but it simply doesn't work anymore either - thats not really deprecation. I feel that deprecating solrconfig-filename should be its own issue so thats a more clear entry in CHANGES

          I shall open another issue for this. The setSolrConfigFilename() did not work for multicore . So it does not make sense for us to bend over backwards to make it work in this and add too many overloaded methods. Anyway, users won't need

          Show
          Noble Paul added a comment - You mark setSolrConfigFilename as deprecated, but it simply doesn't work anymore either - thats not really deprecation. I feel that deprecating solrconfig-filename should be its own issue so thats a more clear entry in CHANGES I shall open another issue for this. The setSolrConfigFilename() did not work for multicore . So it does not make sense for us to bend over backwards to make it work in this and add too many overloaded methods. Anyway, users won't need
          Hide
          Mark Miller added a comment - - edited

          This patch reinstates a fix for the SolrDispatcher config name override so that all tests pass again.
          It also changes DEFAULT_CORE to use a final static constant rather than be repeated.

          Personally, I also almost think that removing the alias feature should be its own issue.

          (EDIT okay, I see you made that a sub-issue - nice)

          Show
          Mark Miller added a comment - - edited This patch reinstates a fix for the SolrDispatcher config name override so that all tests pass again. It also changes DEFAULT_CORE to use a final static constant rather than be repeated. Personally, I also almost think that removing the alias feature should be its own issue. ( EDIT okay, I see you made that a sub-issue - nice)
          Hide
          Mark Miller added a comment -

          You mark setSolrConfigFilename as deprecated, but it simply doesn't work anymore either - thats not really deprecation. I feel that deprecating solrconfig-filename should be its own issue so thats a more clear entry in CHANGES. And it should prob be deprecated rather than turned off out of the blue. I don't suppose its a big deal either way though.

          You have also changed CoreContainer#getCores - but that change is unrelated to this patch. I really feal an issue should just stick to the issue - it makes commits more clear. That change (which isn't back compat anyway), should be its own commit.

          This latest update removes a bunch of the unrelated changes.

          The patch is still unfinished though - you removed my fix to use the solrconfig override without replacing it with an alternative fix. As a result, some tests don't use the right config now, and in particular, NoCacheHeaderTest is back to failing.

          Show
          Mark Miller added a comment - You mark setSolrConfigFilename as deprecated, but it simply doesn't work anymore either - thats not really deprecation. I feel that deprecating solrconfig-filename should be its own issue so thats a more clear entry in CHANGES. And it should prob be deprecated rather than turned off out of the blue. I don't suppose its a big deal either way though. You have also changed CoreContainer#getCores - but that change is unrelated to this patch. I really feal an issue should just stick to the issue - it makes commits more clear. That change (which isn't back compat anyway), should be its own commit. This latest update removes a bunch of the unrelated changes. The patch is still unfinished though - you removed my fix to use the solrconfig override without replacing it with an alternative fix. As a result, some tests don't use the right config now, and in particular, NoCacheHeaderTest is back to failing.
          Hide
          Mark Miller added a comment -

          Lastly : there are a couple little unrelated changes in this patch.

          1. The change to the import statement in CoreDescriptor, but no other changes to the file.
          2. The change in index.jsp from self closing tags to closing link tags - this has no apparent purpose, so I think it shouldn't be part of this commit.

          Show
          Mark Miller added a comment - Lastly : there are a couple little unrelated changes in this patch. 1. The change to the import statement in CoreDescriptor, but no other changes to the file. 2. The change in index.jsp from self closing tags to closing link tags - this has no apparent purpose, so I think it shouldn't be part of this commit.
          Hide
          Mark Miller added a comment -

          Also, its confusing the way the Alias test is commented out - shouldn't we just remove to be less confusing? It will still be in subversion if we decide we want to bring it back.

          Show
          Mark Miller added a comment - Also, its confusing the way the Alias test is commented out - shouldn't we just remove to be less confusing? It will still be in subversion if we decide we want to bring it back.
          Hide
          Mark Miller added a comment -

          You've deprecated handleAliasAction, but you have also made it so its not called with the default handleRequestBody.

          I think its safer to just remove handleAliasAction - someone that overrode handleAliasAction but kept the default handleRequestBody would be in a for a silent nasty surprise anyway. Better to get a compile time error.

          Show
          Mark Miller added a comment - You've deprecated handleAliasAction, but you have also made it so its not called with the default handleRequestBody. I think its safer to just remove handleAliasAction - someone that overrode handleAliasAction but kept the default handleRequestBody would be in a for a silent nasty surprise anyway. Better to get a compile time error.
          Hide
          Mark Miller added a comment -

          I'd like to take a quick look - will report back.

          Show
          Mark Miller added a comment - I'd like to take a quick look - will report back.
          Hide
          Noble Paul added a comment -

          hi . If everyone is OK I would just cleanup the patch and commit this shortly..

          Show
          Noble Paul added a comment - hi . If everyone is OK I would just cleanup the patch and commit this shortly..
          Hide
          Noble Paul added a comment -

          also deprecated specifying solrconfig from web.xml. We may not need it anymore because we should not support 2 ways of doing the same

          Show
          Noble Paul added a comment - also deprecated specifying solrconfig from web.xml. We may not need it anymore because we should not support 2 ways of doing the same
          Hide
          Noble Paul added a comment -

          with ALIAS deprecated

          Show
          Noble Paul added a comment - with ALIAS deprecated
          Hide
          Noble Paul added a comment -

          I'm good with yanking ALIAS for now.

          I am happy to remove a lot of complexity from CoreContainer which was introduced by ALIAS. When we implemented SOLR-1293 (internally) we disabled ALIAS so that the implementation is simple.
          Let us revisit ALIAS later and make it simpler.

          Show
          Noble Paul added a comment - I'm good with yanking ALIAS for now. I am happy to remove a lot of complexity from CoreContainer which was introduced by ALIAS. When we implemented SOLR-1293 (internally) we disabled ALIAS so that the implementation is simple. Let us revisit ALIAS later and make it simpler.
          Hide
          Yonik Seeley added a comment -

          I'm good with yanking ALIAS for now.

          But I think it would be nice to have a single hard-coded alias (perhaps just at the level of dispatch filter) that can treat an existing core as the default core (w/o having to name it something specific like DEFAULT_CORE. As long as we can have a normal core with a normal name like "music", with the ability to use it with legacy URLs.

          Show
          Yonik Seeley added a comment - I'm good with yanking ALIAS for now. But I think it would be nice to have a single hard-coded alias (perhaps just at the level of dispatch filter) that can treat an existing core as the default core (w/o having to name it something specific like DEFAULT_CORE. As long as we can have a normal core with a normal name like "music", with the ability to use it with legacy URLs.
          Hide
          Hoss Man added a comment -

          The nice thing about the idea of ALIAS is that you can have cores with very explicit names (ie: catalog_v1, catalog_v2, etc...) and then you can have aliases like "LIVE" and "EXPERIMENTAL" that you can move around as needed. Similar things can be accomplished with the SWAP command, but it's more limiting.

          That said: the last time i tired using ALIAS it was such a confusing pain in the ass because of the way the original name was still tracked separately from the list of aliases, even if that name had been taken over by another core) i couldn't bring myself to use it – using SWAP and keeping track of the logical names externally was less confusing.

          If we can make ALIAS work well, it will kick ass – but we can always yank it for now if it's in our way, and add it back again later if someone comes up with a good way to do it. (it was probably a mistake to try and treat names an aliases as equals in the first place ... looking up a core by a "string" is probably the only use cases where they should be treated equally, all of the other CoreAdmin commands should really differentiate.)

          Show
          Hoss Man added a comment - The nice thing about the idea of ALIAS is that you can have cores with very explicit names (ie: catalog_v1, catalog_v2, etc...) and then you can have aliases like "LIVE" and "EXPERIMENTAL" that you can move around as needed. Similar things can be accomplished with the SWAP command, but it's more limiting. That said: the last time i tired using ALIAS it was such a confusing pain in the ass because of the way the original name was still tracked separately from the list of aliases, even if that name had been taken over by another core) i couldn't bring myself to use it – using SWAP and keeping track of the logical names externally was less confusing. If we can make ALIAS work well, it will kick ass – but we can always yank it for now if it's in our way, and add it back again later if someone comes up with a good way to do it. (it was probably a mistake to try and treat names an aliases as equals in the first place ... looking up a core by a "string" is probably the only use cases where they should be treated equally, all of the other CoreAdmin commands should really differentiate.)
          Hide
          Noble Paul added a comment -

          it works now even after the alias command . I still think we should remove the 'alias' command. It is a fancy feature which adds too much of complexity into ref counting of cores

          Show
          Noble Paul added a comment - it works now even after the alias command . I still think we should remove the 'alias' command. It is a fancy feature which adds too much of complexity into ref counting of cores
          Hide
          Noble Paul added a comment - - edited

          if they cause too much grief, we always have the option to remove.

          Do we really have a usecase for ALIAS ? if there is no no compelling enough usecase we should consider removing it. there is a lot of code which is there just becaus eof this alias feature

          Show
          Noble Paul added a comment - - edited if they cause too much grief, we always have the option to remove. Do we really have a usecase for ALIAS ? if there is no no compelling enough usecase we should consider removing it. there is a lot of code which is there just becaus eof this alias feature
          Hide
          Yonik Seeley added a comment -

          Aliases were marked as experimental - if they cause too much grief, we always have the option to remove.

          Show
          Yonik Seeley added a comment - Aliases were marked as experimental - if they cause too much grief, we always have the option to remove.
          Hide
          Mark Miller added a comment -

          the index pages are fixed

          how are they fixed?

          I think one problem with how you are handling alias' is that it only works with alias' defined in solr.xml?

          If you use the request handler to create an alias (with the alias command), I still don't think that works properly.

          Show
          Mark Miller added a comment - the index pages are fixed how are they fixed? I think one problem with how you are handling alias' is that it only works with alias' defined in solr.xml? If you use the request handler to create an alias (with the alias command), I still don't think that works properly.
          Hide
          Noble Paul added a comment -

          the index pages are fixed

          Show
          Noble Paul added a comment - the index pages are fixed
          Hide
          Mark Miller added a comment -

          Its up to trunk - looks like its an issue with $id - I'm so sick of running into that. Here is a patch with the $id created by the patch replaced with the actual $id string - that should make it apply.

          Show
          Mark Miller added a comment - Its up to trunk - looks like its an issue with $id - I'm so sick of running into that. Here is a patch with the $id created by the patch replaced with the actual $id string - that should make it apply.
          Hide
          Noble Paul added a comment -

          hi Mark could you update the patch to trunk?

          Show
          Noble Paul added a comment - hi Mark could you update the patch to trunk?
          Hide
          Mark Miller added a comment - - edited

          Whoops - wrong solr.xml example in last patch - had core1 for the name.

          Show
          Mark Miller added a comment - - edited Whoops - wrong solr.xml example in last patch - had core1 for the name.
          Hide
          Mark Miller added a comment - - edited

          This solves the closing core too many times issue you can have by just simply checking if a core is closed before closing it in shutdown.

          By the way, why not allow removing the DEFAULT_CORE? Shouldn't it be treated like any other core, other than the special property of getting a "" alias?

          • edit *

          We still need to solve listing alias' as primary cores in index.jsp as well.

          Show
          Mark Miller added a comment - - edited This solves the closing core too many times issue you can have by just simply checking if a core is closed before closing it in shutdown. By the way, why not allow removing the DEFAULT_CORE? Shouldn't it be treated like any other core, other than the special property of getting a "" alias? edit * We still need to solve listing alias' as primary cores in index.jsp as well.
          Hide
          Mark Miller added a comment -

          We should try and hit SOLR-1626 with this too since we are doing alias work anyway.

          We either need to drop too many closes as a logging error in SolrCore, or set things up so that we only close primary core names and not aliases.

          Show
          Mark Miller added a comment - We should try and hit SOLR-1626 with this too since we are doing alias work anyway. We either need to drop too many closes as a logging error in SolrCore, or set things up so that we only close primary core names and not aliases.
          Hide
          Mark Miller added a comment -

          Looks like it has the same issue I ran into -

          The solrConfigFilename doesn't work right now (used by tests and web.xml override).

          What I did is add another load method that also takes the config filename (or not if its null). I don't like adding the extra methods for this, so I'm not sure this is the best solution, but its a solution to get started with.

          That will get the NoCacheHeaderTest to pass.

          I also dropped a solr.xml into example to get started there.

          Show
          Mark Miller added a comment - Looks like it has the same issue I ran into - The solrConfigFilename doesn't work right now (used by tests and web.xml override). What I did is add another load method that also takes the config filename (or not if its null). I don't like adding the extra methods for this, so I'm not sure this is the best solution, but its a solution to get started with. That will get the NoCacheHeaderTest to pass. I also dropped a solr.xml into example to get started there.
          Hide
          Mark Miller added a comment -

          Nice! Essentially the same as my little patch, but I hadn't done the alias stuff. Reviewing now.

          Show
          Mark Miller added a comment - Nice! Essentially the same as my little patch, but I hadn't done the alias stuff. Reviewing now.
          Hide
          Noble Paul added a comment - - edited

          The necessary code changes for corecontainer.

          Show
          Noble Paul added a comment - - edited The necessary code changes for corecontainer.
          Hide
          Mark Miller added a comment -

          I think this description is more in line with what the proposal is - while deprecation may occur, its not the primary work to be done - this is an improvement and issue whether we decided to deprecate or not - we are also not deprecating "single core deployments" - we would be deprecating a lack of solr.xml.

          Show
          Mark Miller added a comment - I think this description is more in line with what the proposal is - while deprecation may occur, its not the primary work to be done - this is an improvement and issue whether we decided to deprecate or not - we are also not deprecating "single core deployments" - we would be deprecating a lack of solr.xml.
          Hide
          Mark Miller added a comment -
          It should show something like
          
          Admin DEFAULT_CORE (alias :"" )
          Admin core1 (alias : "c2","c3")
          

          +1 - that would be nice.

          Show
          Mark Miller added a comment - It should show something like Admin DEFAULT_CORE (alias :"" ) Admin core1 (alias : "c2" , "c3" ) +1 - that would be nice.
          Hide
          Mark Miller added a comment -

          Just to clear this up:

          This issue is not a proposal to deprecate the current single core mode - its a proposal to allow specifying the current single core mode from solr.xml.

          Show
          Mark Miller added a comment - Just to clear this up: This issue is not a proposal to deprecate the current single core mode - its a proposal to allow specifying the current single core mode from solr.xml.
          Hide
          Mark Miller added a comment - - edited

          If you don't see solr.xml, you just assume the very simple default solr.xml - the same as solr will.

          you would have to change the directory structure somewhere

          Thats the point of this issue - you won't have to change the directory structure.

          introduce a new configuration file, and only then you would be able to add more databases

          You will only introduce a new config file if you decided to forgo it to start - thats fair. The example will come with it.

          Having two deferent configuration mechanisms for single and multi-core eventually adds to the complexity

          There won't be two configuration mechanisms - if you want to do core configuration you will need the file - in either case, for a release or two, solr will assume a solr.xml that works with no solr.xml in the dir - taking that away is more pain for those that don't have or want it than helpful in my opinion. There won't be two configuration mechanisms in either case.

          The purpose of this issue is to make the current single core specifiable from solr.xml - that doesn't mean you need an explicit solr.xml - any tool and solr can assume the most basic solr.xml that would be the default anyway : private final static String SINGLE_CORE_CONFIG = "<solr persistent=\"false\"><cores adminPath=\"/admin/cores\"><core name=\"DEFAULT_CORE\" instanceDir=\".\" /></cores></solr>";

          I'll let it go - others that don't wan't it required (from the zookeeper issue) can chime in, or I'll just let it go.

          Show
          Mark Miller added a comment - - edited If you don't see solr.xml, you just assume the very simple default solr.xml - the same as solr will. you would have to change the directory structure somewhere Thats the point of this issue - you won't have to change the directory structure. introduce a new configuration file, and only then you would be able to add more databases You will only introduce a new config file if you decided to forgo it to start - thats fair. The example will come with it. Having two deferent configuration mechanisms for single and multi-core eventually adds to the complexity There won't be two configuration mechanisms - if you want to do core configuration you will need the file - in either case, for a release or two, solr will assume a solr.xml that works with no solr.xml in the dir - taking that away is more pain for those that don't have or want it than helpful in my opinion. There won't be two configuration mechanisms in either case. The purpose of this issue is to make the current single core specifiable from solr.xml - that doesn't mean you need an explicit solr.xml - any tool and solr can assume the most basic solr.xml that would be the default anyway : private final static String SINGLE_CORE_CONFIG = "<solr persistent=\"false\"><cores adminPath=\"/admin/cores\"><core name=\"DEFAULT_CORE\" instanceDir=\".\" /></cores></solr>"; I'll let it go - others that don't wan't it required (from the zookeeper issue) can chime in, or I'll just let it go.
          Hide
          Uri Boness added a comment -

          In addition to the awareness I believe it's also consistent. Having two deferent configuration mechanisms for single and multi-core eventually adds to the complexity. A consistent directory layout and one single access point to the configuration (that is, solr.xml) simplifies things - user don't need to keep in their mind "oh... this is multi-core... so it uses this layout" or "oh... it's only one core, so there is not solr.xml just this directory". Instead they get a consistent view of the directory/configuration structure whether the use multi-core or not.

          Also note it also helps in developing tools for Solr as you don't need to deal with different configurations types and scenarios.

          Thinks of RDBMS's... MySQL for example. Imagine MySQL would come with a default configuration of a single database. But when you wanted to add more databases, you would have to change the directory structure somewhere, introduce a new configuration file, and only then you would be able to add more databases. In that respect, Solr can be seen RDBMS and Solr Core can be seen as a Database within this RDBMS.

          Show
          Uri Boness added a comment - In addition to the awareness I believe it's also consistent. Having two deferent configuration mechanisms for single and multi-core eventually adds to the complexity. A consistent directory layout and one single access point to the configuration (that is, solr.xml) simplifies things - user don't need to keep in their mind "oh... this is multi-core... so it uses this layout" or "oh... it's only one core, so there is not solr.xml just this directory". Instead they get a consistent view of the directory/configuration structure whether the use multi-core or not. Also note it also helps in developing tools for Solr as you don't need to deal with different configurations types and scenarios. Thinks of RDBMS's... MySQL for example. Imagine MySQL would come with a default configuration of a single database. But when you wanted to add more databases, you would have to change the directory structure somewhere, introduce a new configuration file, and only then you would be able to add more databases. In that respect, Solr can be seen RDBMS and Solr Core can be seen as a Database within this RDBMS.
          Hide
          Mark Miller added a comment -

          And the user will be conscious about the existence of solr.xml .

          They will be aware because we will include it with example.

          So technically they don't 'add' it.

          New users won't add it, but old users will have to it - generally with no benefit. If you are just running single core, being conscious of solr.xml is not very useful. Forcing older users to add the file, just to make them conscious off it, is not very persuasive in my opinion. Its more config for the user with no benefit.

          Anyway this is a minor technicality

          Its something that we will have to come to consensus on.

          Show
          Mark Miller added a comment - And the user will be conscious about the existence of solr.xml . They will be aware because we will include it with example. So technically they don't 'add' it. New users won't add it, but old users will have to it - generally with no benefit. If you are just running single core, being conscious of solr.xml is not very useful. Forcing older users to add the file, just to make them conscious off it, is not very persuasive in my opinion. Its more config for the user with no benefit. Anyway this is a minor technicality Its something that we will have to come to consensus on.
          Hide
          Noble Paul added a comment -

          what are the supporting reasons?

          It gives transparency. And the user will be conscious about the existence of solr.xml . like tomcat offers the default web.xml which users usually don't edit. But tells the users that it exists and certain behaviour is driven from that .
          Users usually take the example and make the necessary changes. So technically they don't 'add' it. Anyway this is a minor technicality.

          Show
          Noble Paul added a comment - what are the supporting reasons? It gives transparency. And the user will be conscious about the existence of solr.xml . like tomcat offers the default web.xml which users usually don't edit. But tells the users that it exists and certain behaviour is driven from that . Users usually take the example and make the necessary changes. So technically they don't 'add' it. Anyway this is a minor technicality.
          Hide
          Mark Miller added a comment -

          It is better to be consistent in the long run.

          Why - what are the supporting reasons? Making current users put in a boiler plate file in the future doesn't appear to have any benefits to me. If they want to use settings in the file, they can add the file, but just to add it for the sake of adding it is not very appealing.

          Show
          Mark Miller added a comment - It is better to be consistent in the long run. Why - what are the supporting reasons? Making current users put in a boiler plate file in the future doesn't appear to have any benefits to me. If they want to use settings in the file, they can add the file, but just to add it for the sake of adding it is not very appealing.
          Hide
          Noble Paul added a comment -

          continue supporting no solr.xml without deprecation. If a user is not going to customize anything,

          It is better to be consistent in the long run. There is no harm if the user drops in this default solr.xml whether he customizes it or not. So , I believe we should get rid of it 2 releases later.

          One of the minor issues is that the default page that shows all of the cores doesn't care about aliases -

          another thing I wish to change in this is we should store the aliases also in the CoreDescriptor . That makes it simpler to show details.

          It should show something like

          Admin DEFAULT_CORE (alias :"" )
          Admin core1 (alias : "c2","c3")

          Show
          Noble Paul added a comment - continue supporting no solr.xml without deprecation. If a user is not going to customize anything, It is better to be consistent in the long run. There is no harm if the user drops in this default solr.xml whether he customizes it or not. So , I believe we should get rid of it 2 releases later. One of the minor issues is that the default page that shows all of the cores doesn't care about aliases - another thing I wish to change in this is we should store the aliases also in the CoreDescriptor . That makes it simpler to show details. It should show something like Admin DEFAULT_CORE (alias :"" ) Admin core1 (alias : "c2","c3")
          Hide
          Mark Miller added a comment -

          I wrote a little patch trying this out -

          One of the minor issues is that the default page that shows all of the cores doesn't care about aliases - I think thats something we should address -

          add a getNonAliasCores (with a different name) or something. Otherwise you see the following on the index.jsp page:

          Welcome to Solr!

          Admin DEFAULT_CORE
          Admin DEFAULT_CORE

          Based on the feedback in the discussion that spawned this, we should also consider not deprecating solr.xml. I think we should
          put one in the default example, but continue supporting no solr.xml without deprecation. If a user is not going to customize anything,
          we don't gain much by forcing them to add the default solr.xml that we can assume anyway - and we still get all of the advantages of this issue.

          Show
          Mark Miller added a comment - I wrote a little patch trying this out - One of the minor issues is that the default page that shows all of the cores doesn't care about aliases - I think thats something we should address - add a getNonAliasCores (with a different name) or something. Otherwise you see the following on the index.jsp page: Welcome to Solr! Admin DEFAULT_CORE Admin DEFAULT_CORE Based on the feedback in the discussion that spawned this, we should also consider not deprecating solr.xml. I think we should put one in the default example, but continue supporting no solr.xml without deprecation. If a user is not going to customize anything, we don't gain much by forcing them to add the default solr.xml that we can assume anyway - and we still get all of the advantages of this issue.
          Hide
          Eric Pugh added a comment -

          Glad to see this bug. In the Solr book we mentioned that this was a very likely thing, and that even if you think you only need 1 core, starting out with a multicore setup is the way to go! Especially when you toss in all the great management features of multiple cores!

          Show
          Eric Pugh added a comment - Glad to see this bug. In the Solr book we mentioned that this was a very likely thing, and that even if you think you only need 1 core, starting out with a multicore setup is the way to go! Especially when you toss in all the great management features of multiple cores!
          Hide
          Karthik K added a comment -

          +1 . Thanks - This is long due, the moment we get into the multi-core world.

          Show
          Karthik K added a comment - +1 . Thanks - This is long due, the moment we get into the multi-core world.
          Hide
          Noble Paul added a comment - - edited

          The proposed design.

          Going forward for the single core example we will add a solr.xml to the $SOLR_HOME/solr directory whose content will look like

          <?xml version="1.0" encoding="UTF-8" ?>
          <solr persistent="false">
            <cores adminPath="/admin/cores">
              <!-- "DEFAULT_CORE" is a special name . Solr will automatically create an alias "" for this name-->
              <core name="DEFAULT_CORE" instanceDir="." />    
            </cores>
          </solr>
          

          the core will be accessible by both the names

          All coreadmin actions can be performed using the core name as DEFAULT_CORE. So all coreadmin features will work for single core as well

          For legacy users who have single core deployments no change needs to be done. if the solr.xml is missing we will use a default solr.xml whose content is same as above. So everything will be backward compatible. We can mark the deployments w/o solr.xml as deprecated and the we can remove it completely later.

          Show
          Noble Paul added a comment - - edited The proposed design. Going forward for the single core example we will add a solr.xml to the $SOLR_HOME/solr directory whose content will look like <?xml version= "1.0" encoding= "UTF-8" ?> <solr persistent= "false" > <cores adminPath= "/admin/cores" > <!-- "DEFAULT_CORE" is a special name . Solr will automatically create an alias "" for this name--> <core name= "DEFAULT_CORE" instanceDir= "." /> </cores> </solr> the core will be accessible by both the names http://host:port/solr/ ("" is an alias for DEFAULT_CORE ) http://host:port/solr/DEFAULT_CORE All coreadmin actions can be performed using the core name as DEFAULT_CORE. So all coreadmin features will work for single core as well For legacy users who have single core deployments no change needs to be done. if the solr.xml is missing we will use a default solr.xml whose content is same as above. So everything will be backward compatible. We can mark the deployments w/o solr.xml as deprecated and the we can remove it completely later.

            People

            • Assignee:
              Noble Paul
              Reporter:
              Noble Paul
            • Votes:
              5 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development