[Solr Wiki] Update of "Solr.xml 4.3 and beyond" by ErickErickson

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "Solr.xml 4.3 and beyond" page has been changed by ErickErickson:
http://wiki.apache.org/solr/Solr.xml%204.3%20and%20beyond

New page:
= Solr.xml 4.3 and beyond =

As of <!> [[Solr4.3]] there is an alternate structure for the solr.xml config file '''which will become mandatory for 5.0'''. This is very much a "live document" sort of page, I'm (Erick Erickson) finishing up the code and intend to expand this page as time permits. For the time being, the main points are:

 * Optionally as of <!> [[Solr4.3]] and mandatory for [[Solr5.0]], the structure of the solr.xml file has changed. In a nutshell, <cores> and <core> have been replaced by auto-discovering cores. Whether to use old or new-style core definitions is determined by whether the <cores> tag is present in solr.xml. In 5.0, presence of the <cores> tag will generate an error on startup.
 * An optional property ''coreRootDirectory'' can cause the discovery process to start at an arbitrary directory other than SOLR_HOME.
 * We'll distribute a new-style solr.xml as the default in the example directory with [[Solr4.3]]

== Structure of the new-style solr.xml ==
Basically, it's mostly a move from the older attributes to a flatter style, and removal of <cores> and <core> tags. Here's a sample file. Note that any of these values can have a system property defined by specifying -Dpropname=propvalue on JVM startup (should these have solr. in front?):

<!> Caution! These are just the test values from a unit test and are '''not''' reasonable values! I'm getting them up for comment, I'll put reasonable ones in Real Soon Now.
{{{
<solr>
  <str name="adminHandler">testAdminHandler</str>
  <int name="coreLoadThreads">11</int>
  <str name="coreRootDirectory">${coreRootDirectory:testCoreRootDirectory}</str>
  <int name="distribUpdateConnTimeout">22</int>
  <int name="distribUpdateSoTimeout">33</int>
  <str name="host">testHost</str>
  <str name="hostContext">testHostContext</str>
  <int name="hostPort">${hostPort:44}</int>
  <int name="leaderVoteWait">55</int>
  <str name="managementPath">testManagementPath</str>
  <str name="sharedLib">testSharedLib</str>
  <str name="shareSchema">${shareSchema:testShareSchema}</str>
  <int name="transientCacheSize">66</int>
  <int name="zkClientTimeout">77</int>
  <str name="zkHost">testZkHost</str>
  <logging>
    <str name="class">testLoggingClass</str>
    <str name="enabled">testLoggingEnabled</str>
    <watcher>
      <int name="size">88</int>
      <int name="threshold">99</int>

    </watcher>

  </logging>

  <shardHandlerFactory name="testShardHandlerFactory" class="testHttpShardHandlerFactory">
    <int name="socketTimeout">${socketTimeout:100}</int>
    <int name="connTimeout">${connTimeout:110}</int>
  </shardHandlerFactory>

</solr>
}}}


== Core discovery process ==
Exploration of the core tree terminates when a file named core.properties is encountered. Discovery of a file of that name is assumed to define the root of a core. There is no a-priori limit on the depth of the tree. That is, the directories under the core root are explored until a core.properties file is encountered, and that directory is assumed to be the instanceDir for that core. Nested cores are NOT supported. The core.properties file presently recognizes the following entries:
   * name - the name of the core required.
   * config - the configuration file. Defaults to solrconfig.xml
   * instanceDir - the directory for this core. Usually you should just leave this out, it defaults to the directory that core.properties is in. '''Does it make any sense to have this value? I don't think it really adds any value'''.
   * dataDir - the directory where the index, tlog, etc. are stored. Again, since this is discovery-based, omit this unless you have special needs.
   * ulogDir - where the transaction log resides. It may be advantageous to put the transaction lot on a different disk than the index.
   * schema - the schema file. Defaults to schema.xml
   * shard - the shard ID.
   * collection - the collection to which this core belongs
   * roles - SolrCloud role definition
   * properties - properties file to override core definitions. TBD: This is probably obsolete since we're reading a properties file in the first place. Is there a use case for supporting this now?
   * loadOnStartup - [true|false] this core should be loaded and a searcher opened when Solr starts.
   * transient - [true|false] this core may be unloaded if the core cache exceeds transientCacheSize (defined in solr.propreties)
   * coreNodeName - SolrCloud core node name