Configuring solr.xml

This attribute does not need to be set.

If used, this attribute should be set to the FQN (Fully qualified name) of a class that inherits from ConfigSetService, and you must provide a constructor with one parameter of type org.apache.solr.core.CoreContainer. For example, <str name="configSetService">com.myorg.CustomConfigSetService</str>.

If this attribute isn’t set, Solr uses the default configSetService, with zookeeper aware of org.apache.solr.cloud.ZkConfigSetService, without zookeeper aware of org.apache.solr.core.FileSystemConfigSetService.

This attribute does not need to be set.

If used, this attribute should be set to the FQN (Fully qualified name) of a class that inherits from CoreAdminHandler. For example, <str name="adminHandler">com.myorg.MyAdminHandler</str> 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.

This attribute does not need to be set.

If defined, it should contain a list of custom actions to be registered within the CoreAdminHandler. Each entry of the list should be of str type where name of the entry defines the name of the action and value is a FQN (Fully qualified name) of an action class that inherits from CoreAdminOp.

For example, actions can be defined like this:

After defining custom actions they can be called using their names:

As above, for custom CollectionsHandler implementations.

As above, for custom InfoHandler implementations.

Specifies the number of threads that will be assigned to load cores in parallel.

Specifies the number of threads that will be assigned to replay updates in parallel. This pool is shared for all cores of the node. The default value is equal to the number of processors.

Specifies the number of threads that will be assigned for search queries.

The root of the core discovery tree, defaults to $SOLR_HOME.

This attribute does not need to be set.

If used, this attribute should be set to the FQN (fully qualified name) of a class that implements CoresLocator, and you must provide a constructor with one parameter of type org.apache.solr.core.NodeConfig. For example, <str name="coresLocator">com.myorg.CustomCoresLocator</str> would configure a custom cores locator.

This attribute does not need to be set.

If used, this attribute should be set to the FQN (fully qualified name) of a class that implements CoreSorter, and you must provide a constructor with one parameter of type org.apache.solr.core.CoreContainer. This service is used when Solr is starting to prioritize which cores should be loaded first. For example, <str name="coresLocator">com.myorg.CustomCoresLocator</str> would configure a custom core sorter.

Currently non-operational.

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. If the specified path is not absolute, it will be relative to $SOLR_HOME. Custom handlers may be placed in this directory. Note that specifying sharedLib will not remove $SOLR_HOME/lib from Solr’s class path.

Takes a list of bundled Solr Modules to enable on startup. This way of adding modules will add them to the shared class loader, making them available to every collection in Solr, unlike <lib> tag in solrconfig.xml which is only for that one collection. Example value: extracting,ltr. See the Solr Modules chapter for more details.

Solr will normally only access folders relative to $SOLR_HOME, $SOLR_DATA_HOME or coreRootDir. If you need to e.g., create a core outside of these paths, you can explicitly allow the path with allowPaths. It is a comma separated string of file system paths to allow. The special value of * will allow any path on the system.

Comma-separated list of Solr hosts to allow.

The HTTP/HTTPS protocol may be omitted, and only the host and port are checked, i.e., 10.0.0.1:8983/solr,10.0.0.1:8984/solr.

When running Solr as a user-managed cluster and using the shards parameter, a list of hosts needs to be specifically configured as allowed or Solr will forbid the request.

In SolrCloud mode, the allow-list is automatically configured to include all live nodes in the cluster.

The allow-list can also be configured with the solr.allowUrls system property in solr.in.sh / solr.in.cmd. If you need to disable this feature for backwards compatibility, you can set the system property solr.disable.allowUrls=true.

When this attribute is set to true, Solr will not return any stack traces in the HTTP response in case of errors. By default (false), stack traces are hidden only for predictable Solr exceptions, but are returned in the response for unexpected exceptions (i.e.: HTTP 500)

This attribute, when set to true, ensures that the multiple cores pointing to the same Schema resource file 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 file.

Deprecated as of 9.2. Defines how many Solr cores with transient=true that can be loaded before unloading an unused core for one that is needed.

The directory under which configsets for Solr cores can be found.

Sets the maximum number of (nested) clauses allowed in any query.

This global limit provides a safety constraint on the total number of clauses allowed in any query against any collection — regardless of whether those clauses were explicitly specified in a query string, or were the result of query expansion/re-writing from a more complex type of query based on the terms in the index. This limit is enforced at multiple points in Lucene, both to prevent primitive query objects (mainly BooleanQuery) from being constructed with an excessive number of clauses in a way that may exhaust the JVM heap, but also to ensure that no composite query (made up of multiple primitive queries) can be executed with an excessive total number of nested clauses in a way that may cause a search thread to use excessive CPU.

In default configurations this property uses the value of the solr.max.booleanClauses system property if specified. This is the same system property used in the _default configset for the <maxBooleanClauses> element of solrconfig.xml making it easy for Solr administrators to increase both values (in all collections) without needing to search through and update all of their configs.

Comma-separated list of regex patterns to match sysProps that should be redacted to hide sensitive information.

The allow-list can also be configured with the solr.hiddenSysProps system property, or via the SOLR_HIDDEN_SYS_PROPS environment variable.

By default, Solr will hide all basicAuth, AWS, ZK or SSL secret sysProps. It will also hide any sysProp that contains "password" or "secret" in it.

Used to set the underlying connTimeout for intra-cluster updates.

Used to set the underlying socketTimeout for intra-cluster updates.

The hostname Solr uses to access cores.

The url context path.

The port Solr uses to access cores, and advertise Solr node locations through liveNodes. This option is only necessary if a Solr instance is listening on a different port than it wants other nodes to contact it at. For example, if the Solr node is running behind a proxy or in a cloud environment that allows for port mapping, such as Kubernetes. hostPort is the port that the Solr instance wants other nodes to contact it at.

In the default solr.xml file, this is set to ${solr.port.advertise:0}. If no port is passed via the solr.xml (i.e., 0), then Solr will default to the port that jetty is listening on, defined by ${jetty.port}.

When SolrCloud is starting up, how long each Solr node will wait for all known replicas for that shard to be found before assuming that any nodes that haven’t reported are down.

When trying to elect a leader for a shard, this property sets the maximum time a replica will wait to see conflicting state information to be resolved; temporary conflicts in state information can occur when doing rolling restarts, especially when the node hosting the Overseer is restarted.

Typically, the default value of 180000 (ms) is sufficient for conflicts to be resolved; you may need to increase this value if you have hundreds or thousands of small collections in SolrCloud.

A timeout for connection to a ZooKeeper server. It is used with SolrCloud.

In SolrCloud mode, the URL of the ZooKeeper host that Solr should use for cluster state information.

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.

Optional parameters that can be specified if you are using ZooKeeper Access Control.

If true, the internal behavior of SolrCloud is changed to not use the Overseer for collections' state.json updates but do this directly against ZooKeeper.

Optional parameter to enable compression of the state.json over the wire and stored in Zookeeper. The value provided is the minimum length of bytes to compress state.json, i.e. any state.json above that size in bytes will be compressed. The default is -1, meaning state.json is always uncompressed.

Optional parameter to provide a compression implementation for state.json over the wire and stored in Zookeeper. The value provided is the class to use for state compression. This is only used if minStateByteLenForCompression is set to a value above -1.

The class to use for logging. The corresponding JAR file must be available to Solr, perhaps through a <lib> directive in solrconfig.xml.

Whether to enable logging or not.

The read timeout for intra-cluster query and administrative requests. The default is the same as the distribUpdateSoTimeout specified in the <solrcloud> section.

The connection timeout for intra-cluster query and administrative requests. Defaults to the distribUpdateConnTimeout specified in the <solrcloud> section.

The URL scheme to be used in distributed search.

Maximum connections allowed per host.

The initial core size of the threadpool servicing requests.

The maximum size of the threadpool servicing requests. Default is unlimited.

The amount of time in seconds that idle threads persist for in the queue, before being killed.

If the threadpool uses a backing queue, what is its maximum size to use direct handoff. Default is to use a SynchronousQueue.

A boolean to configure if the threadpool favors fairness over throughput.

A NamedList specifying replica routing preference configuration. This may be used to select and configure replica routing preferences. default=true may be used to set the default base replica routing preference. Only positive default status assertions are respected; i.e., default=false has no effect. If no explicit default base replica routing preference is configured, the implicit default will be random.