lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <>
Subject Re: Rename multicore.xml ?
Date Thu, 07 Aug 2008 19:26:13 GMT
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).


On Thu, Aug 7, 2008 at 2:51 PM, Chris Hostetter
<> 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

View raw message