After the <query> section, request handlers and search components are configured.These are often referred to as "requestHandler" and "searchComponent", which is how they are defined in solrconfig.xml.
A request handler processes requests coming to Solr. These might be query requests or index update requests. You will likely need several of these defined, depending on how you want Solr to handle the various requests you will make.
A search component is a feature of search, such as highlighting or faceting. The search component is defined in solrconfig.xml separate from the request handlers, and then registered with a reqeust handler as needed.
Every request handler is defined with a name and a class. The name of the request handler is referenced with the request to Solr. For example, a request to http://localhost:8983/solr/collection1 is the default address for Solr, which will likely bring up the Solr Admin UI. However, add "/select" to the end, you can make a query:
This query will be processed by the request handler with the name "/select". We've only used the "q" parameter here, which includes our query term, a simple keyword of "solr". If the request handler has more parameters defined, those will be used with any query we send to this request handler unless they are over-ridden by the client (or user) in the query itself.
If you have another request handler defined, you would send your request with that name - for example, "/update" is a request handler that handles index updates like sending new documents to the index.
The primary request handler defined with Solr by default is the "SearchHandler", which handles search queries. The request handler is defined, and then a list of defaults for the handler are defined with a defaults list.
For example, in the default solrconfig.xml, the first request handler defined looks like this:
This example defines the rows parameter, which defines how many search results to return, to "10". The default field to search is the "text" field, set with the df parameter. The echoParams parameter defines that the parameters defined in the query should be returned when debug information is returned. Note also that the way the defaults are defined in the list varies if the parameter is a string, an integer, or another type.
All of the parameters described in the section on searching can be defined as defaults for any of the SearchHandlers.
Besides defaults, there are other options for the SearchHandler, which are:
- appends: This allows definition of parameters that are added to the user query. These might be filter queries, or other query rules that should be added to each query. There is no mechanism in Solr to allow a client to override these additions, so you should be absolutely sure you always want these parameters applied to queries.
In this example, the filter query "inStock:true" will always be added to every query.
- invariants: This allows definition of parameters that cannot be overridden by a client. The values defined in an invariants section will always be used regardless of the values specified by the user, by the client, in defaults or in appends.
In this example, facet fields have been defined which limits the facets that will be returned by Solr. If the client requests facets, the facets defined with a configuration like this are the only facets they will see.
The final section of a request handler definition is components, which defines a list of search components that can be used with a request handler. They are only registered with the request handler. How to define a search component is discussed further on in the section on Search Components. The components element can only be used with a request handler that is a SearchHandler.
The solrconfig.xml file includes many other examples of SearchHandlers that can be used or modified as needed.
The UpdateRequestHandlers are request handlers which process updates to the index.
In this guide, we've covered these handlers in detail in the section Uploading Data with Index Handlers.
It is possible to configure a request handler to search across shards of a cluster, used with distributed search. More information about distributed search and how to configure the shardHandler is in the section Distributed Search with Index Sharding.
There are other request handlers defined in solrconfig.xml, covered in other sections of this guide:
The search components define the logic that is used by the SearchHandler to perform queries for users.
There are several defaults search components that work with all SearchHandlers without any additional configuration. If no components are defined, these are used by default.
|Component Name||Class Name||More Information|
|query||solr.QueryComponent||Described in the section Query Syntax and Parsing.|
|facet||solr.FacetComponent||Described in the section Faceting.|
|mlt||solr.MoreLikeThisComponent||Described in the section MoreLikeThis.|
|highlight||solr.HighlightComponent||Described in the section Highlighting.|
|stats||solr.StatsComponent||Described in the section The Stats Component.|
|debug||solr.DebugComponent||Described in the section on Common Query Parameters.|
If you register a new search component with one of these default names, the newly defined component will be used instead of the default.
It's possible to define some components as being used before (with first-components) or after (with last-components) other named components. This would be useful if custom search components have been configured to process data before the regular components are used. This is used when registering the components with the request handler.
Many of the other useful components are described in sections of this Guide for the features they support. These are:
- SpellCheckComponent, described in the section Spell Checking.
- TermVectorComponent, described in the section The Term Vector Component.
- QueryElevationComponent, described in the section The Query Elevation Component.
- TermsComponent, described in the section The Terms Component.