On 12/26/2013 02:29 PM, Shawn Heisey wrote:
On 12/24/2013 8:35 AM, David Santamauro wrote:
You may have one or more of the SolrCloud 'bootstrap' options on the
startup commandline. The bootstrap options are intended to be used
once, in order to bootstrap from a non-SolrCloud setup to a SolrCloud
setup.
No, no unnecessary options. I manually bootstrapped a common config.
I have no idea what might be wrong here.
Between the Collections API and the CoreAdmin API, you should never need
to edit solr.xml (if using the pre-4.4 format) or core.properties files
(if using core discovery, available 4.4 and later) directly.
Now this I don't understand. If I have created cores through the
CoreAdmin API, how is solr.xml affected? If I don't edit it, how does
SOLR know what cores it has to expose to a distributed collection?
If you are using the old-style solr.xml (which will be supported through
all future 4.x versions, but not 5.0), then core definitions are stored
in solr.xml and the contents of the file are changed by many of the
CoreAdmin API actions. The Collections API calls the CoreAdmin API on
servers throughout the cloud.
I have never experienced tomcat or the SOLR webapp create, modify or
otherwise touch in anyway the solr.xml file. I have always had to add
the necessary core definition manually.
http://wiki.apache.org/solr/Solr.xml%20%28supported%20through%204.x%29
If you are using the core discovery format, which was made available in
working form in version 4.4, then solr.xml does NOT contain core
definitions. The main example in 4.4 and later uses the new format.
Cores are discovered at Solr startup by crawling the filesystem from a
root starting point looking for core.properties files. In this mode,
solr.xml is fairly static.
http://wiki.apache.org/solr/Solr.xml%204.4%20and%20beyond
http://wiki.apache.org/solr/Core%20Discovery%20%284.4%20and%20beyond%29
I'll begin exploring this new format, thanks for the help and links.
David
