What about solr.xml and it is always there? A single core is just
multicore with one core. I know that one's been tossed around
before. Of course, back compat. gets in the way a bit.
Also, maybe we should also mark multicore as experimental (starting to
sound like a lot of Solr is "experimental", these days, what w/ a good
number of output formats marked w/ that warning).
To be honest, I really think we need to start thinking a lot harder
about Solr on Spring. All this config stuff just makes my head hurt.
It can all be so much simpler, IMO. In fact, part of me thinks 1.3
should be our last 1.x release, but most of me knows that is not
realistic. I think w/ Spring, we can keep the same core search
functionality, and input/output APIs, and make the config a lot
simpler, or at least more well known and obvious. I know, I should
submit a patch... There's also a part of me that thinks the config
and schema should be able to be initialized completely
programmatically w/o any XML whatsoever. Using Spring should allow
that.
At any rate, that is a side decision. If we really are going to take
on the multicore issue, then we need to postpone the release, IMO.
Otherwise, I think we should just label it as it is expected to change
in the next release.
-Grant
On Aug 7, 2008, at 3:26 PM, Yonik Seeley wrote:
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
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
