lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Confluence)" <conflue...@apache.org>
Subject [CONF] Apache Solr Reference Guide > Format of solr.xml
Date Mon, 23 Sep 2013 22:19:00 GMT
Space: Apache Solr Reference Guide (https://cwiki.apache.org/confluence/display/solr)
Page: Format of solr.xml (https://cwiki.apache.org/confluence/display/solr/Format+of+solr.xml)

Change Comment:
---------------------------------------------------------------------
remove mention of solrconfig.xml implicit properties -- these are now on the solrconfig.xml
page - add explanation of what sys props can be used in solr.xml

Edited by Hoss Man:
---------------------------------------------------------------------
You can find {{solr.xml}} in your Solr Home directory. The default _discovery_ {{solr.xml}}
file looks like this:

{code:language=html/xml|borderStyle=solid|borderColor=#666666}
<solr>

  <solrcloud>
    <str name="host">${host:}</str>
    <int name="hostPort">${jetty.port:8983}</int>
    <str name="hostContext">${hostContext:solr}</str>
    <int name="zkClientTimeout">${zkClientTimeout:15000}</int>
    <bool name="genericCoreNodeNames">${genericCoreNodeNames:true}</bool>
  </solrcloud>

  <shardHandlerFactory name="shardHandlerFactory"
    class="HttpShardHandlerFactory">
    <int name="socketTimeout">${socketTimeout:0}</int>
    <int name="connTimeout">${connTimeout:0}</int>
  </shardHandlerFactory>

</solr>
{code}

As you can see, the discovery solr configuration is "SolrCloud friendly". However, the presence
of the {{<solrcloud>}} element does _not_ mean that the Solr instance is running in
SolrCloud mode. Unless the {{\-DzkHost}} or {{\-DzkRun}} are specified at startup time, this
section is ignored.

h2. Using Multiple SolrCores

It is possible to segment Solr into multiple cores, each with its own configuration and indices.
Cores may be dedicated to a single application or to very different ones, but all are administered
through a common administration interface. You can create new Solr cores on the fly, shutdown
cores, even replace one running core with another, all without ever stopping or restarting
your servlet container.

Solr cores are configured by placing a file named {{core.properties}} in a sub-directory under
{{solr.home}}. There are no a-priori limits to the depth of the tree, nor are there limits
to the number of cores that can be defined. Cores may be anywhere in the tree with the exception
that cores may _not_ be defined under an existing core. That is, the following is not allowed:

{code:language=none|borderStyle=solid|borderColor=#666666}
./cores/core1/core.properties
./cores/core1/coremore/core5/core.properties
{code}

In this example, the enumeration will stop at "core1".

The following is legal:

{code:language=none|borderStyle=solid|borderColor=#666666}
./cores/somecores/core1/core.properties
./cores/somecores/core2/core.properties
./cores/othercores/core3/core.properties
./cores/extracores/deepertree/core4/core.properties
{code}

A minimal {{core.properties}} file looks like this:

{code:language=none|borderStyle=solid|borderColor=#666666}
name=collection1
{code}

This is very different than the legacy {{solr.xml}} {{<core>}} tag. In fact, your {{core.properties}}
file _can be empty_. Say the {{core.properties}} file is located in (relative to {{solr_home}})
{{./cores/core1}}. In that case, the file core name is assumed to be "core1". The instanceDir
will be the folder containing {{core.properties}} (i.e., {{./cores/core1}}). The dataDir will
be {{../cores/core1/data}}, etc.

{info}
You can run Solr without configuring any cores.
{info}

h2. Solr.xml Parameters

h3. The {{<solr>}} Element

There are no attributes that you can specify in the {{<solr>}} tag, which is the root
element of {{solr.xml}}. The tables below list the child nodes of each XML element in {{solr.xml}}.

{note}
The {{persistent}} attribute is no longer supported in {{solr.xml}}. The properties in {{solr.xml}}
are immutable, and any changes to individual cores are persisted in the individual {{core.properties}}
files.
{note}

|| Node || Description ||
| {{adminHandler}} | If used, this attribute should be set to the FQN (Fully qualified name)
of a class that inherits from CoreAdminHandler. For example, adminHandler="com.myorg.MyAdminHandler"
would configure the custom admin handler (MyAdminHandler) to handle admin requests. If this
attribute isn't set, Solr uses the default admin handler, org.apache.solr.handler.admin.CoreAdminHandler.
For more information on this parameter, see the Solr Wiki at [http://wiki.apache.org/solr/CoreAdmin#cores].
|
| {{coreLoadThreads}} | Specifies the number of threads that will be assigned to load cores
in parallel |
| {{coreRootDirectory}} | The root of the core discovery tree, defaults to SOLR_HOME |
| {{managementPath}} | no-op at present. |
| {{sharedLib}} | Specifies the path to a common library directory that will be shared across
all cores. Any JAR files in this directory will be added to the search path for Solr plugins.
This path is relative to the top-level container's Solr Home. |
| {{shareSchema}} | This attribute, when set to true, ensures that the multiple cores pointing
to the same schema.xml will be referring to the same IndexSchema Object. Sharing the IndexSchema
Object makes loading the core faster. If you use this feature, make sure that no core-specific
property is used in your schema.xml. |
| {{transientCacheSize}} | Defines how many cores with transient=true that can be loaded before
swapping the least recently used core for a new core. |

h3. The {{<solrcloud>}} element

This element defines several parameters that relate so SolrCloud. This section is ignored
unless the solr instance is started with either {{\-DzkRun}} or {{\-DzkHost}}

|| Node || Description ||
| {{distribUpdateConnTimeout}} | Used to set the underlying "connTimeout" for intra-cluster
updates. |
| {{distribUpdateSoTimeout}} | Used to set the underlying "socketTimeout" for intra-cluster
updates. |
| {{host}} | The hostname Solr uses to access cores. |
| {{hostContext}} | The servlet context path. |
| {{hostPort}} | The port Solr uses to access cores. In the default {{solr.xml}} file, this
is set to {{$\{jetty.port:\}}}, which will use the Solr port defined in Jetty. |
| {{leaderVoteWait}} | When SolrCloud is starting up, how long each Solr node will wait for
all known replicas for that share to be found before assuming that any nodes that haven't
reported are down. |
| {{zkClientTimeout}} | A timeout for connection to a ZooKeeper server. It is used with SolrCloud.
|
| {{zkHost}} | In SolrCloud mode, the URL of the ZooKeeper host that Solr should use for cluster
state information. |
| {{genericCoreNodeNames}} | If {{TRUE}}, node names are not based on the address of the node,
but on a generic name that identifies the core. When a different machine takes over serving
that core things will be much easier to understand. |

h3. The {{<logging>}} element.

|| Node || Description ||
| {{class}} | The class to use for logging. The corresponding JAR file must be available to
solr, perhaps through a {{<lib>}} directive in solrconfig.xml. |
| {{enabled}} | true/false - whether to enable logging or not. |

h4. The {{<logging><watcher>}} element.

|| Node || Description ||
| {{size}} | The number of log events that are buffered. |
| {{threshold}} | The logging level above which your particular logging implementation will
record. For example when using log4j one might specify DEBUG | WARN | INFO etc. |

h3. The {{<shardHandlerFactory>}} element.

Custom share handlers can be defined in {{solr.xml}} if you wish to create a custom shard
handler.

{code:language=html/xml|borderStyle=solid|borderColor=#666666}
  <shardHandlerFactory name="ShardHandlerFactory" class="qualified.class.name">
{code}

However, since this is a custom shard handler, sub-elements are specific to the implementation.

h3. Substituting JVM System Properties in {{solr.xml}}

Solr supports variable substitution of JVM system property values in {{solr.xml}}, which allows
runtime specification of various configuration options.  The syntax is {{$\{propertyname\[:option
default value\]\}}}. This allows defining a default that can be overridden when Solr is launched.
If a default value is not specified, then the property must be specified at runtime or the
solr.xml file will generate an error when parsed.

Any JVM System properties, usually specified using the -D flag when starting the JVM, can
be used as variables in the {{solr.xml}} file.

For example:  In the {{solr.xml}} file shown below, starting solr using {{java -DsocketTimeout=1000
-jar start.jar}} will cause the {{socketTimeout}} option of the {{HttpShardHandlerFactory}}
to be overridden using a value of 1000ms, instead of the default property value of "0" --
however the {{connTimeout}} option will continue to use the default property value of "0".

{code:language=html/xml|borderStyle=solid|borderColor=#666666}
<solr>
  <shardHandlerFactory name="shardHandlerFactory" 
                       class="HttpShardHandlerFactory">
    <int name="socketTimeout">${socketTimeout:0}</int>
    <int name="connTimeout">${connTimeout:0}</int>
  </shardHandlerFactory>
</solr>
{code}


h2. Individual {{core.properties}} Files

Core discovery replaces the individual {{<core>}} tags in {{solr.xml}} with a {{core.properties}}
file located on disk. The presence of the {{core.properties}} file _defines_ the {{instanceDir}}
for that core. The {{core.properties}} file is a simple Java Properties file where each line
is just a key=value pair, e.g., {{name=core1}}. Notice that no quotes are required.

Java properties files allow the hash ("#") or bang ("!") characters to specify comment-to-end-of-line.
This table defines the recognized properties:

|| key || Description ||
| {{name}} | The name of the SolrCore.  You'll use this name to reference the SolrCore when
running commands with the CoreAdminHandler. |
| {{config}} | The configuration file name for a given core. The default is {{solrconfig.xml}}.
|
| {{schema}} | The schema file name for a given core. The default is {{schema.xml}} |
| {{dataDir}} | Core's data directory as a path relative to the instanceDir, {{data}} by default.
|
| {{properties}} | The name of the properties file for this core. The value can be an absolute
pathname or a path relative to the value of {{instanceDir}}. |
| {{transient}} | If *true*, the core can be unloaded if Solr reaches the {{transientCacheSize}}.
The default if not specified is *false*. Cores are unloaded in order of least recently used
first. |
| {{loadOnStartup}} | If *true*, the default if it is not specified, the core will loaded
when Solr starts. |
| {{coreNodeName}} | Added in Solr 4.2, this attributes allows naming a core. The name can
then be used later if you need to replace a machine with a new one. By assigning the new machine
the same coreNodeName as the old core, it will take over for the old SolrCore. |
| {{ulogDir}} | The absolute or relative directory for the update log for this core (SolrCloud)
|
| {{shard}} | The shard to assign this core to (SolrCloud) |
| {{collection}} | The name of the collection this core is part of (SolrCloud) |
| {{roles}} | Future param for SolrCloud or a way for users to mark nodes for their own use.
|

The minimal {{core.properties}} file is an empty file, in which case all of the properties
are defaulted appropriately.

{scrollbar}


Stop watching space: https://cwiki.apache.org/confluence/users/removespacenotification.action?spaceKey=solr
Change email notification preferences: https://cwiki.apache.org/confluence/users/editmyemailsettings.action


    

Mime
View raw message