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
