lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Update of "Core Discovery (4.2 and beyond)" by ErickErickson
Date Sat, 02 Mar 2013 02:04:20 GMT
Dear Wiki user,

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

The "Core Discovery (4.2 and beyond)" page has been changed by ErickErickson:
http://wiki.apache.org/solr/Core%20Discovery%20%284.2%20and%20beyond%29

New page:
= Discovery-based core enumeration =
<!> Solr 4.2

TODO: Lots to flesh out here, this is just barely a start for the docs, consider it a placeholder
that will be expanded as time permits. Please ask any questions that come up on the user's
list or whatever, and we'll expand this page. Or edit it yourself, all help appreciated!

As of SOLR-4196, there's a new way of defining cores. Essentially, it is no longer necessary
to define cores in solr.xml. In fact, solr.xml is no longer necessary at all and will be obsoleted
in Solr 5.x. As of Solr 4.2 the process is as follows:
 * If a solr.xml file is found in <SOLR_HOME>, then it is expected to be the old-style
solr.xml that defines cores etc.
 * If there is no solr.xml but there ''is'' a solr.properties file, then exploration-based
core enumeration is assumed.
 * If neither a solr.xml nor an solr.properties file is found, a default solr.xml file is
assumed. NOTE: as of 5.0, this will not be true and an error will be thrown if no solr.properties
file is found.
 * If a solr.properties file is found,  all the information that used to be available in solr.xml
is defined available here ''except'' there should be no core information. It's a straightforward
mapping from the old schema.xml <solr> and <cores> nodes to the properties file
version. See [[Solr.xml (pre 5.x)]] for their meanings <!> TODO: put the rest of the
definitions here rather than reference an obsolete page!.
  * persistent [true|false] Whether to persist any changes to the files on disk, both solr.properties
and the individual core.properties files. Defaults to false.
  * sharedLib
  * zkHost
  * cores.hostPort
  * cores.adminPath
  * cores.defaultCoreName
  * cores.shareSchema - soon to be obsolete. Real Soon Now (see SOLR-4478), configSets will
be implemented. This will implicitly support sharing schemas, solrconfig, etc in alignment
with SolrCloud initiatives.
  * cores.hostContext
  * cores.zkClientTimeout
  * cores.transientCacheSize - The number of cores that can be loaded before closing older
ones on an LRU basis. Only cores defined with transient=true (see below) are placed in this
cache.
  * cores.adminHandler



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 <SOLR_HOME> 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.
 * 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

Mime
View raw message