Resource and Plugin Loading
Solr components can be configured using resources: data stored in external files that may be referred to in a location-independent fashion. Examples include: files needed by schema components, e.g., a stopword list for Stop Filter; and machine-learned models for Learning to Rank.
Solr plugins, which can be configured in
solrconfig.xml, are Java classes that are normally packaged in
.jar files along with supporting classes and data. Solr ships with a number of built-in plugins, and can also be configured to use custom plugins. Example plugins are the Data Import Handler and custom search components.
Resources and plugins may be stored:
in ZooKeeper under a collection’s configset node (SolrCloud only);
on a filesystem accessible to Solr nodes; or
in Solr’s Blob Store (SolrCloud only).
|Schema components may not be stored as plugins in the Blob Store, and cannot access resources stored in the Blob Store.|
Resource and Plugin Loading Sequence
Under SolrCloud, resources and plugins to be loaded are first looked up in ZooKeeper under the collection’s configset znode. If the resource or plugin is not found there, Solr will fall back to loading from the filesystem.
Note that by default, Solr will not attempt to load resources and plugins from the Blob Store. To enable this, see the section Use a Blob in a Handler or Component. When loading from the Blob Store is enabled for a component, lookups occur only in the Blob Store, and never in ZooKeeper or on the filesystem.
Resources and Plugins in ConfigSets on ZooKeeper
To upload a plugin or resource to a configset already stored on ZooKeeper, you can use
bin/solr zk cp.
Resources and Plugins on the Filesystem
Under standalone Solr, when looking up a plugin or resource to be loaded, Solr’s resource loader will first look under the
<instanceDir>/conf/ directory. If the plugin or resource is not found, the configured plugin and resource file paths are searched - see the section Lib Directives in SolrConfig below.
When looking up a resource or plugin to be loaded, the paths on the list are searched in the order they were added.
|Under SolrCloud, each node hosting a collection replica will need its own copy of plugins and resources to be loaded.|
To get Solr’s resource loader to find resources either under subdirectories or in jar files that were created after Solr’s resource path list was constructed, reload the collection (SolrCloud) or the core (standalone Solr). Restarting all affected Solr nodes also works.
Resource files will not be loaded if they are located directly under either
Each Solr node can have a directory named
lib/ under the Solr home directory. In order to use this directory to host resources or plugins, it must first be manually created.
Lib Directives in SolrConfig
Plugin and resource file paths are configurable via
<lib/> directives in
Loading occurs in the order
<lib/> directives appear in
solrconfig.xml. If there are dependencies, list the lowest level dependency jar first.
A regular expression supplied in the
regex attribute value can be used to restrict which subdirectories and/or jar files are added to the Solr resource loader’s list of search locations. If no regular expression is given, all direct subdirectory and jar children are included in the resource path list. All directories are resolved as relative to the Solr core’s
From an example SolrConfig:
<lib dir="../../../contrib/extraction/lib" regex=".*\.jar" /> <lib dir="../../../dist/" regex="solr-cell-\d.*\.jar" /> <lib dir="../../../contrib/clustering/lib/" regex=".*\.jar" /> <lib dir="../../../dist/" regex="solr-clustering-\d.*\.jar" /> <lib dir="../../../contrib/langid/lib/" regex=".*\.jar" /> <lib dir="../../../dist/" regex="solr-langid-\d.*\.jar" /> <lib dir="../../../contrib/velocity/lib" regex=".*\.jar" /> <lib dir="../../../dist/" regex="solr-velocity-\d.*\.jar" />