As far as name, I like solr.xml better than multicore.xml Option #2 is interesting... and might be even more so if files in the base conf directory could act as defaults (perhaps a future feature).
-Yonik On Thu, Aug 7, 2008 at 2:51 PM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > I know I probably should have brought this up a little farther in advance of > releasing 1.3 (I think i did bring it up back when multicore was first added > ,but then I kind of forgot about it) but I have some concerns about the name > of the "multicore.xml" file. If I'm alone, I'll let it go, but if other > people think I have a point, we should make the change it prior to the > release. > > Main Concern... > > From the standpoint of debugging, answering questions, and general > "Understanding" of a Solr installation the first thing you always have to > ask with 1.3 is "What is the Solr Home directory?" and the second thing is > "What does the ./conf/solrconfig.xml file look like?" > > As the trunk stands now, the new second question becomes "Is there a > ./multicore.xml?" ... because if there is, then it doesn't matter what > ./conf/solrconfig.xml looks like, it's totally ignored 9and you can be > certain that some confusion like that will pop up as people switch from > traditional single core to usage to multicore usage, there will be some > ./conf/solrconfig.xml files lying around). > > The question can't even be "Is this instance of Solr using multiple cores?" > because that's not what really matters, what matters is the multicore.xml > file. A person might only be using one core, but if multicore.xml exists it > determines where to look for all of the configs for that core, not > ./conf/solrconfig.xml. > > So far, I see two problems with this: > 1) The name of the file corresponds with one specific way it can be > used, but may not be applicable to all usages (namely: you can > have a multicore.xml file but only use one core) > 2) The "first" config file checked to determine the application's > behavior, and what paths will be checked for other config files > is named after one specific feature of the application. > > From a historical perspective, our current setup would be like if the Apache > HTTPD server had originally used ./conf/httpd.conf as the primary config, > but when VirtualHost features were added, started saying "If there is a > ./virtualhost.conf file it will be read first, and it will tell us which > httpd.conf files to read, even if there is only one VirtualHost." > > This seems odd to me, and likely to confuse new users. > Am I alone in this opinion? > > I have two suggested alternatives: > > Suggestion #1: Rename multicore.xml something new. > > The best suggestion I have is "solr.xml" -- It is a good name to represent > the "first" config file Solr looks for. If it exists in the Solr Home > Directory, it will tell us how many cores to run, and what directories to > use for them. (Someday we might even want to consider allowing a system > property / JNDI property specify it directly instead of specifying Solr > Home) and if it doesn't exist we assume a single core whose instanceDir is > the Solr Home Dir. > > This seems pretty straight forward. The only changes we'd *have* to make > would be some string literals and some documentation (and svn renaming the > example multicore.xml). But we should also consider changing adding a new > root XML tag in multicore.xml wrapping the existing <multicore> with a > <solr> ... that would give us a little more flexibility in the future. > > > Suggestion #2: Change solrconfig.xml parsing to understand <multicore> > > This one is a little weird, part of me thinks it's really the best way to > go, but part of me thinks i's really awkward compared to having a solr.xml. > The nushell would be that we always look for ./conf/solrconfig.xml first > and if the root tag is <multicore> we go into MultiCore mode, and if not we > go into SingleCore mode. > > The big advantage here would be that debuging a Solr instance or answering > questions becomes really straight forward. Instead of asking "Is there a > multicore.xml/solr.xml?" and then depending on the answer asking "What does > ./conf/xolrconfig.xml look like?" the only thing you have to know is "What > does ./conf/xolrconfig.xml look like?" > > The possible downsides: More changes to code now before the release; A > somewhat awkward Solr Home directory structure when you are using multiple > cores (Even if you have different instanceDirs for each core, your main Solr > Home directory still needs to contain ./conf/ which needs to contain a > solrconfig.xml); And having one file support two radically different types > of content. > > Most installs probably keep all of their instance dirs in Solr Home, so the > directory layout of Suggestion#2 doesn't seem too awkward compared to > Suggestion#1... > > solr-home/ (Suggestion#1) > solr-home/solr.xml (current multicore.xml) > solr-home/instanceDir1/ > solr-home/instanceDir1/... > solr-home/instanceDir2/ > solr-home/instanceDir2/... > solr-home/... > ...vs... > solr-home/ (Suggestion#2) > solr-home/conf/ > solr-home/conf/solrconfig.xml (current multicore.xml) > solr-home/instanceDir1/ > solr-home/instanceDir1/... > solr-home/instanceDir2/ > solr-home/instanceDir2/... > solr-home/... > > ...But i'm sure opinions vary. > > What do people think? > Is this going to confuse new users who come along, and make troubleshooting > as confusing as I suspect, or am I just being paranoid? > > Even if I am being paranoid: is there any downside to Suggestion #1 > > > > -Hoss > >
