The heading part of the solrconfig.xml file contains general settings that are not strictly related to the index phase.

The first is the Lucene match version:

<luceneMatchVersion>LUCENE_47</luceneMatchVersion>

This allows you to control which version of Lucene will be internally used by Solr. This is useful to manage migration phases towards the newer versions of Solr, thus allowing backward compatibility with indexes built with previous versions.

A second piece of information you can set here is the data directory, that is, the directory where Solr will create and manage the index. It defaults to a directory called data under $SOLR_HOME.

<dataDir>/var/data/defaultDataDir</dataDir>

The section within the <indexConfig> tag contains a lot of things that you can configure in order to fine-tune the Solr index phase.

A curious thing you can see in this section, in the solrconfig.xml file of the example core, is that most things are commented. This is very important, because it means that Solr provides good default values for those settings.

The following table summarizes the settings you will find within the <indexConfig> section:

The <UpdateHandlerSection> configures the component that is responsible for handling requests to update the index.

This is where it's possible to tell Solr to periodically run unsolicited commits so that clients won't need to do that explicitly while indexing. Declaring two different thresholds can trigger auto-commits:

They are not exclusive, so it's perfectly legal to have settings such as these:

<autoCommit>
  <maxDocs>5000</maxDocs>
  <maxTime>300000</maxTime>
</autoCommit>

Starting from Solr 4.0, there are two kinds of commit. A hard commit flushes the uncommitted documents to the index, therefore creating and changing segments and data files on the disk. The other type is called soft commit, which doesn't actually write uncommitted changes but just reopens the internal Solr searcher in order to make uncommitted data in the memory available for searches.

Hard commits are expensive, but after their execution, data is permanently part of the index. Soft commits are fast but transient, so in case of a system crash, changes are lost.

Hard and soft commits can coexist in a Solr configuration. The following is an example that shows this:

<autoCommit>
  <maxTime>900000</maxTime>
</autoCommit>
<autoSoftCommit>
  <maxTime>1000</maxTime>
</autoSoftCommit>

Here, a soft commit will be triggered every second (1000 milliseconds), and a hard commit will run every 15 minutes (900000 milliseconds).

A RequestHandler instance is a pluggable component that handles incoming requests. It is configured in solrconfig.xml as a specific endpoint by means of its name attribute.

Requests sent to Solr can belong to several categories: search, update, administration, and stats. In this context, we are interested in those handlers that are in charge of handling index update requests. Although not mandatory, those handlers are usually associated with a name starting with the /update prefix, for example, the default handler you will find in the configuration:

<requestHandler name="/update" class="solr.UpdateRequestHandler"/>

Prior to Solr 4, each kind of input format (for example, JSON, XML, and so on) required a dedicated handler to be configured. Now the general-purpose update handler, that is, the /update handler uses the content type of the incoming request in order to detect the format of the input data. The following table lists the built-in content types:

Each format has its own way of encoding the kind of update operation (for example, add, delete, and commit) and the input documents. This is a sample add command in XML:

<add>
  <doc>
    <field name="id">12020</field>
    <field name="title">Round around midnight</field>
  </doc>
  …
</add>

Later, we will index some data using different techniques and different formats.

The write path of the index process has been conceived by Solr developers with modularity and extensibility in mind. Specifically, the index process has been structured as a chain of responsibilities, where each set of components adds its own contribution to the whole index process.

The UpdateRequestProcessor chain is an important configurable aspect of the index process. If you want to declare your custom chain, you need to add a corresponding section within the configuration. This is an example of a custom chain:

<updateRequestProcessorChain name="my-index-chain">
  <processor class="…"/>
  <processor class="…">
    <str name="aParameterName">aParameterValue</str>
  </processor>
  <processor name="solr.RunUpdateProcessorFactory"/>
  <processor name="solr.LogUpdateProcessorFactory"/>
</updateRequestProcessorChain>

Defining a new chain requires a name and a set of UpdateRequestProcessorFactory components that are in charge of creating processor instances for that chain.

<requestHandler name="/myReqHandler"
  class="solr.UpdateRequestHandler">
  <lst name="defaults">
    <str name="update.chain">chain.name</str>
  </lst>
</requestHandler>

There are a lot of already implemented UpdateRequestProcessor components that you can use in your chain, but in general, it's absolutely easy to create your own processor and customize the index chain.