You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by ct...@apache.org on 2017/05/12 14:35:42 UTC
[32/37] lucene-solr:branch_6_6: squash merge jira/solr-10290 into
master
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/common-query-parameters.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/common-query-parameters.adoc b/solr/solr-ref-guide/src/common-query-parameters.adoc
new file mode 100644
index 0000000..248d540
--- /dev/null
+++ b/solr/solr-ref-guide/src/common-query-parameters.adoc
@@ -0,0 +1,365 @@
+= Common Query Parameters
+:page-shortname: common-query-parameters
+:page-permalink: common-query-parameters.html
+
+Several query parsers share supported query parameters.
+
+The table below summarizes Solr's common query parameters, which are supported by the <<requesthandlers-and-searchcomponents-in-solrconfig#RequestHandlersandSearchComponentsinSolrConfig-SearchHandlers,Search RequestHandlers>>
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Parameter |Description
+|<<CommonQueryParameters-ThedefTypeParameter,defType>> |Selects the query parser to be used to process the query.
+|<<CommonQueryParameters-ThesortParameter,sort>> |Sorts the response to a query in either ascending or descending order based on the response's score or another specified characteristic.
+|<<CommonQueryParameters-ThestartParameter,start>> |Specifies an offset (by default, 0) into the responses at which Solr should begin displaying content.
+|<<CommonQueryParameters-TherowsParameter,rows>> |Controls how many rows of responses are displayed at a time (default value: 10)
+|<<CommonQueryParameters-Thefq_FilterQuery_Parameter,fq>> |Applies a filter query to the search results.
+|<<CommonQueryParameters-Thefl_FieldList_Parameter,fl>> |Limits the information included in a query response to a specified list of fields. The fields need to either be `stored="true"` or `docValues="true"`
+|<<CommonQueryParameters-ThedebugParameter,debug>> |Request additional debugging information in the response. Specifying the `debug=timing` parameter returns just the timing information; specifying the `debug=results` parameter returns "explain" information for each of the documents returned; specifying the `debug=query parameter` returns all of the debug information.
+|<<CommonQueryParameters-TheexplainOtherParameter,explainOther>> |Allows clients to specify a Lucene query to identify a set of documents. If non-blank, the explain info of each document which matches this query, relative to the main query (specified by the q parameter) will be returned along with the rest of the debugging information.
+|<<CommonQueryParameters-ThetimeAllowedParameter,timeAllowed>> |Defines the time allowed for the query to be processed. If the time elapses before the query response is complete, partial information may be returned.
+|<<CommonQueryParameters-ThesegmentTerminateEarlyParameter,segmentTerminateEarly>> |Indicates that, if possible, Solr should stop collecting documents from each individual (sorted) segment once it can determine that any subsequent documents in that segment will not be candidates for the `rows` being returned. The default is false.
+|<<CommonQueryParameters-TheomitHeaderParameter,omitHeader>> |Excludes the header from the returned results, if set to true. The header contains information about the request, such as the time the request took to complete. The default is false.
+|<<CommonQueryParameters-ThewtParameter,wt>> |Specifies the Response Writer to be used to format the query response.
+|<<CommonQueryParameters-ThelogParamsListParameter,logParamsList>> |By default, Solr logs all parameters. Set this parameter to restrict which parameters are logged. Valid entries are the parameters to be logged, separated by commas (i.e., `logParamsList=param1,param2`). An empty list will log no parameters, so if logging all parameters is desired, do not define this additional parameter at all.
+|<<CommonQueryParameters-TheechoParamsParameter,echoParams>> |The response header can include parameters sent with the query request. This parameter controls what is contained in that section of the response header. Valid values are `none`, `all`, and `explicit`. The default value is `explicit.`
+|===
+
+The following sections describe these parameters in detail.
+
+[[CommonQueryParameters-ThedefTypeParameter]]
+== The `defType` Parameter
+
+The defType parameter selects the query parser that Solr should use to process the main query parameter (`q`) in the request. For example:
+
+`defType=dismax`
+
+If no defType param is specified, then by default, the <<the-standard-query-parser.adoc#the-standard-query-parser,The Standard Query Parser>> is used. (eg: `defType=lucene`)
+
+[[CommonQueryParameters-ThesortParameter]]
+== The `sort` Parameter
+
+The `sort` parameter arranges search results in either ascending (`asc`) or descending (`desc`) order. The parameter can be used with either numerical or alphabetical content. The directions can be entered in either all lowercase or all uppercase letters (i.e., both `asc` or `ASC`).
+
+Solr can sort query responses according to document scores or the value of any field with a single value that is either indexed or uses <<docvalues.adoc#docvalues,DocValues>> (that is, any field whose attributes in the Schema include `multiValued="false"` and either `docValues="true"` or `indexed="true"` – if the field does not have DocValues enabled, the indexed terms are used to build them on the fly at runtime), provided that:
+
+* the field is non-tokenized (that is, the field has no analyzer and its contents have been parsed into tokens, which would make the sorting inconsistent), or
+
+* the field uses an analyzer (such as the KeywordTokenizer) that produces only a single term.
+
+If you want to be able to sort on a field whose contents you want to tokenize to facilitate searching, <<copying-fields.adoc#copying-fields,use a `copyField` directive>> in the the Schema to clone the field. Then search on the field and sort on its clone.
+
+The table explains how Solr responds to various settings of the `sort` parameter.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Example |Result
+| |If the sort parameter is omitted, sorting is performed as though the parameter were set to score `desc`.
+|score desc |Sorts in descending order from the highest score to the lowest score.
+|price asc |Sorts in ascending order of the price field
+|inStock desc, price asc |Sorts by the contents of the `inStock` field in descending order, then within those results sorts in ascending order by the contents of the price field.
+|===
+
+Regarding the sort parameter's arguments:
+
+* A sort ordering must include a field name (or `score` as a pseudo field), followed by whitespace (escaped as + or `%20` in URL strings), followed by a sort direction (`asc` or `desc`).
+
+* Multiple sort orderings can be separated by a comma, using this syntax: `sort=<field name>+<direction>,<field name>+<direction>],...`
+** When more than one sort criteria is provided, the second entry will only be used if the first entry results in a tie. If there is a third entry, it will only be used if the first AND second entries are tied. This pattern continues with further entries.
+
+[[CommonQueryParameters-ThestartParameter]]
+== The `start` Parameter
+
+When specified, the `start` parameter specifies an offset into a query's result set and instructs Solr to begin displaying results from this offset.
+
+The default value is "0". In other words, by default, Solr returns results without an offset, beginning where the results themselves begin.
+
+Setting the `start` parameter to some other number, such as 3, causes Solr to skip over the preceding records and start at the document identified by the offset.
+
+You can use the `start` parameter this way for paging. For example, if the `rows` parameter is set to 10, you could display three successive pages of results by setting start to 0, then re-issuing the same query and setting start to 10, then issuing the query again and setting start to 20.
+
+[[CommonQueryParameters-TherowsParameter]]
+== The `rows` Parameter
+
+You can use the rows parameter to paginate results from a query. The parameter specifies the maximum number of documents from the complete result set that Solr should return to the client at one time.
+
+The default value is 10. That is, by default, Solr returns 10 documents at a time in response to a query.
+
+[[CommonQueryParameters-Thefq_FilterQuery_Parameter]]
+== The `fq` (Filter Query) Parameter
+
+The `fq` parameter defines a query that can be used to restrict the superset of documents that can be returned, without influencing score. It can be very useful for speeding up complex queries, since the queries specified with `fq` are cached independently of the main query. When a later query uses the same filter, there's a cache hit, and filter results are returned quickly from the cache.
+
+When using the `fq` parameter, keep in mind the following:
+
+* The `fq` parameter can be specified multiple times in a query. Documents will only be included in the result if they are in the intersection of the document sets resulting from each instance of the parameter. In the example below, only documents which have a popularity greater then 10 and have a section of 0 will match.
++
+[source,text]
+----
+fq=popularity:[10 TO *]&fq=section:0
+----
+
+* Filter queries can involve complicated Boolean queries. The above example could also be written as a single `fq` with two mandatory clauses like so:
++
+[source,text]
+----
+fq=+popularity:[10 TO *] +section:0
+----
+
+* The document sets from each filter query are cached independently. Thus, concerning the previous examples: use a single `fq` containing two mandatory clauses if those clauses appear together often, and use two separate `fq` parameters if they are relatively independent. (To learn about tuning cache sizes and making sure a filter cache actually exists, see <<the-well-configured-solr-instance.adoc#the-well-configured-solr-instance,The Well-Configured Solr Instance>>.)
+* It is also possible to use <<the-standard-query-parser.adoc#TheStandardQueryParser-DifferencesbetweenLuceneQueryParserandtheSolrStandardQueryParser,filter(condition) syntax>> inside the `fq` to cache clauses individually and - among other things - to achieve union of cached filter queries.
+
+* As with all parameters: special characters in an URL need to be properly escaped and encoded as hex values. Online tools are available to help you with URL-encoding. For example: http://meyerweb.com/eric/tools/dencoder/.
+
+[[CommonQueryParameters-Thefl_FieldList_Parameter]]
+== The `fl` (Field List) Parameter
+
+The `fl` parameter limits the information included in a query response to a specified list of fields. The fields need to either be `stored="true"` or `docValues="true"``.`
+
+The field list can be specified as a space-separated or comma-separated list of field names. The string "score" can be used to indicate that the score of each document for the particular query should be returned as a field. The wildcard character `*` selects all the fields in the document which are either `stored="true"` or `docValues="true"` and `useDocValuesAsStored="true"` (which is the default when docValues are enabled). You can also add pseudo-fields, functions and transformers to the field list request.
+
+This table shows some basic examples of how to use `fl`:
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Field List |Result
+|id name price |Return only the id, name, and price fields.
+|id,name,price |Return only the id, name, and price fields.
+|id name, price |Return only the id, name, and price fields.
+|id score |Return the id field and the score.
+|* |Return all the `stored` fields in each document, as well as any `docValues` fields that have `useDocValuesAsStored="true"`. This is the default value of the fl parameter.
+|* score |Return all the fields in each document, along with each field's score.
+|*,dv_field_name |Return all the `stored` fields in each document, and any `docValues` fields that have `useDocValuesAsStored="true`" and the docValues from dv_field_name even if it has `useDocValuesAsStored="false`"
+|===
+
+[[CommonQueryParameters-FunctionValues]]
+=== Function Values
+
+<<function-queries.adoc#function-queries,Functions>> can be computed for each document in the result and returned as a pseudo-field:
+
+[source,text]
+----
+fl=id,title,product(price,popularity)
+----
+
+[[CommonQueryParameters-DocumentTransformers]]
+=== Document Transformers
+
+<<transforming-result-documents.adoc#transforming-result-documents,Document Transformers>> can be used to modify the information returned about each documents in the results of a query:
+
+[source,text]
+----
+fl=id,title,[explain]
+----
+
+[[CommonQueryParameters-FieldNameAliases]]
+=== Field Name Aliases
+
+You can change the key used to in the response for a field, function, or transformer by prefixing it with a `_"displayName_:`". For example:
+
+[source,text]
+----
+fl=id,sales_price:price,secret_sauce:prod(price,popularity),why_score:[explain style=nl]
+----
+
+[source,json]
+----
+{
+"response": {
+ "numFound": 2,
+ "start": 0,
+ "docs": [{
+ "id": "6H500F0",
+ "secret_sauce": 2100.0,
+ "sales_price": 350.0,
+ "why_score": {
+ "match": true,
+ "value": 1.052226,
+ "description": "weight(features:cache in 2) [DefaultSimilarity], result of:",
+ "details": [{
+ "..."
+}]}}]}}
+----
+
+[[CommonQueryParameters-ThedebugParameter]]
+== The `debug` Parameter
+
+The `debug` parameter can be specified multiple times and supports the following arguments:
+
+* `debug=query`: return debug information about the query only.
+* `debug=timing`: return debug information about how long the query took to process.
+* `debug=results`: return debug information about the score results (also known as "explain").
+** By default, score explanations are returned as large string values, using newlines and tab indenting for structure & readability, but an additional `debug.explain.structured=true` parameter may be specified to return this information as nested data structures native to the response format requested by `wt`.
+* `debug=all`: return all available debug information about the request request. (alternatively usage: `debug=true`)
+
+For backwards compatibility with older versions of Solr, `debugQuery=true` may instead be specified as an alternative way to indicate `debug=all`
+
+The default behavior is not to include debugging information.
+
+[[CommonQueryParameters-TheexplainOtherParameter]]
+== The `explainOther` Parameter
+
+The `explainOther` parameter specifies a Lucene query in order to identify a set of documents. If this parameter is included and is set to a non-blank value, the query will return debugging information, along with the "explain info" of each document that matches the Lucene query, relative to the main query (which is specified by the q parameter). For example:
+
+[source,text]
+----
+q=supervillians&debugQuery=on&explainOther=id:juggernaut
+----
+
+The query above allows you to examine the scoring explain info of the top matching documents, compare it to the explain info for documents matching `id:juggernaut`, and determine why the rankings are not as you expect.
+
+The default value of this parameter is blank, which causes no extra "explain info" to be returned.
+
+[[CommonQueryParameters-ThetimeAllowedParameter]]
+== The `timeAllowed` Parameter
+
+This parameter specifies the amount of time, in milliseconds, allowed for a search to complete. If this time expires before the search is complete, any partial results will be returned, but values such as `numFound`, <<faceting.adoc#faceting,facet>> counts, and result <<the-stats-component.adoc#the-stats-component,stats>> may not be accurate for the entire result set.
+
+This value is only checked at the time of:
+
+1. Query Expansion, and
+2. Document collection
+
+As this check is periodically performed, the actual time for which a request can be processed before it is aborted would be marginally greater than or equal to the value of `timeAllowed`. If the request consumes more time in other stages, e.g., custom components, etc., this parameter is not expected to abort the request.
+
+[[CommonQueryParameters-ThesegmentTerminateEarlyParameter]]
+== The `segmentTerminateEarly` Parameter
+
+This parameter may be set to either true or false.
+
+If set to true, and if <<indexconfig-in-solrconfig.adoc#IndexConfiginSolrConfig-mergePolicyFactory,the mergePolicyFactory>> for this collection is a {solr-javadocs}/solr-core/org/apache/solr/index/SortingMergePolicyFactory.html[`SortingMergePolicyFactory`] which uses a `sort` option which is compatible with <<CommonQueryParameters-ThesortParameter,the sort parameter>> specified for this query, then Solr will attempt to use an {lucene-javadocs}/core/org/apache/lucene/search/EarlyTerminatingSortingCollector.html[`EarlyTerminatingSortingCollector`].
+
+If early termination is used, a `segmentTerminatedEarly` header will be included in the `responseHeader`.
+
+Similar to using <<CommonQueryParameters-ThetimeAllowedParameter,the `timeAllowed `Parameter>>, when early segment termination happens values such as `numFound`, <<faceting.adoc#faceting,Facet>> counts, and result <<the-stats-component.adoc#the-stats-component,Stats>> may not be accurate for the entire result set.
+
+The default value of this parameter is false.
+
+[[CommonQueryParameters-TheomitHeaderParameter]]
+== The `omitHeader` Parameter
+
+This parameter may be set to either true or false.
+
+If set to true, this parameter excludes the header from the returned results. The header contains information about the request, such as the time it took to complete. The default value for this parameter is false.
+
+[[CommonQueryParameters-ThewtParameter]]
+== The `wt` Parameter
+
+The `wt` parameter selects the Response Writer that Solr should use to format the query's response. For detailed descriptions of Response Writers, see <<response-writers.adoc#response-writers,Response Writers>>.
+
+[[CommonQueryParameters-Thecache_falseParameter]]
+== The `cache=false` Parameter
+
+Solr caches the results of all queries and filter queries by default. To disable result caching, set the `cache=false` parameter.
+
+You can also use the `cost` option to control the order in which non-cached filter queries are evaluated. This allows you to order less expensive non-cached filters before expensive non-cached filters.
+
+For very high cost filters, if `cache=false` and `cost>=100` and the query implements the `PostFilter` interface, a Collector will be requested from that query and used to filter documents after they have matched the main query and all other filter queries. There can be multiple post filters; they are also ordered by cost.
+
+For example:
+// TODO: fix this, it looks horrible (CT)
+[source,text]
+----
+// normal function range query used as a filter, all matching documents
+// generated up front and cached
+fq={!frange l=10 u=100}mul(popularity,price)
+
+// function range query run in parallel with the main query like a traditional
+// lucene filter
+fq={!frange l=10 u=100 cache=false}mul(popularity,price)
+
+// function range query checked after each document that already matches the query
+// and all other filters. Good for really expensive function queries.
+fq={!frange l=10 u=100 cache=false cost=100}mul(popularity,price)
+----
+
+[[CommonQueryParameters-ThelogParamsListParameter]]
+== The `logParamsList` Parameter
+
+By default, Solr logs all parameters of requests. Set this parameter to restrict which parameters of a request are logged. This may help control logging to only those parameters considered important to your organization.
+
+For example, you could define this like:
+
+`logParamsList=q,fq`
+
+And only the 'q' and 'fq' parameters will be logged.
+
+If no parameters should be logged, you can send `logParamsList` as empty (i.e., `logParamsList=`).
+
+[TIP]
+====
+This parameter does not only apply to query requests, but to any kind of request to Solr.
+====
+
+[[CommonQueryParameters-TheechoParamsParameter]]
+== The `echoParams` Parameter
+
+The `echoParams` parameter controls what information about request parameters is included in the response header.
+
+The table explains how Solr responds to various settings of the `echoParams` parameter:
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Value |Meaning
+|explicit |This is the default value. Only parameters included in the actual request, plus the `_` parameter (which is a 64-bit numeric timestamp) will be added to the params section of the response header.
+|all |Include all request parameters that contributed to the query. This will include everything defined in the request handler definition found in `solrconfig.xml` as well as parameters included with the request, plus the `_` parameter. If a parameter is included in the request handler definition AND the request, it will appear multiple times in the response header.
+|none |Entirely removes the "params" section of the response header. No information about the request parameters will be available in the response.
+|===
+
+Here is an example of a JSON response where the echoParams parameter was not included, so the default of `explicit` is active. The request URL that created this response included three parameters - `q`, `wt`, and `indent`:
+
+[source,json]
+----
+{
+ "responseHeader": {
+ "status": 0,
+ "QTime": 0,
+ "params": {
+ "q": "solr",
+ "indent": "true",
+ "wt": "json",
+ "_": "1458227751857"
+ }
+ },
+ "response": {
+ "numFound": 0,
+ "start": 0,
+ "docs": []
+ }
+}
+----
+
+This is what happens if a similar request is sent that adds `echoParams=all` to the three parameters used in the previous example:
+
+[source,json]
+----
+{
+ "responseHeader": {
+ "status": 0,
+ "QTime": 0,
+ "params": {
+ "q": "solr",
+ "df": "text",
+ "preferLocalShards": "false",
+ "indent": "true",
+ "echoParams": "all",
+ "rows": "10",
+ "wt": "json",
+ "_": "1458228887287"
+ }
+ },
+ "response": {
+ "numFound": 0,
+ "start": 0,
+ "docs": []
+ }
+}
+----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/config-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/config-api.adoc b/solr/solr-ref-guide/src/config-api.adoc
new file mode 100644
index 0000000..146d55c
--- /dev/null
+++ b/solr/solr-ref-guide/src/config-api.adoc
@@ -0,0 +1,521 @@
+= Config API
+:page-shortname: config-api
+:page-permalink: config-api.html
+
+The Config API enables manipulating various aspects of your `solrconfig.xml` using REST-like API calls.
+
+This feature is enabled by default and works similarly in both SolrCloud and standalone mode. Many commonly edited properties (such as cache sizes and commit settings) and request handler definitions can be changed with this API.
+
+When using this API, `solrconfig.xml` is not changed. Instead, all edited configuration is stored in a file called `configoverlay.json`. The values in `configoverlay.json` override the values in `solrconfig.xml`.
+
+[[ConfigAPI-APIEntryPoints]]
+== API Entry Points
+
+* `/config`: retrieve or modify the config. GET to retrieve and POST for executing commands
+* `/config/overlay`: retrieve the details in the `configoverlay.json` alone
+* `/config/params` : allows creating parameter sets that can override or take the place of parameters defined in `solrconfig.xml`. See the <<request-parameters-api.adoc#request-parameters-api,Request Parameters API>> section for more details.
+
+[[ConfigAPI-Retrievingtheconfig]]
+== Retrieving the config
+
+All configuration items, can be retrieved by sending a GET request to the `/config` endpoint - the results will be the effective configuration resulting from merging settings in `configoverlay.json` with those in `solrconfig.xml`:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config
+----
+
+To restrict the returned results to a top level section, e.g. `query`, `requestHandler` or `updateHandler`, append the name of the section to the `/config` endpoint following a slash. E.g. to retrieve configuration for all request handlers:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config/requestHandler
+----
+
+To further restrict returned results to a single component within a top level section, use the `componentName` request param, e.g. to return configuration for the `/select` request handler:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config/requestHandler?componentName=/select
+----
+
+[[ConfigAPI-Commandstomodifytheconfig]]
+== Commands to modify the config
+
+This API uses specific commands to tell Solr what property or type of property to add to `configoverlay.json`. The commands are passed as part of the data sent with the request.
+
+The config commands are categorized into 3 different sections which manipulate various data structures in `solrconfig.xml`. Each of these is described below.
+
+* <<ConfigAPI-CommandsforCommonProperties,Common Properties>>
+* <<ConfigAPI-CommandsforCustomHandlersandLocalComponents,Components>>
+* <<ConfigAPI-CommandsforUser-DefinedProperties,User-defined properties>>
+
+[[ConfigAPI-CommandsforCommonProperties]]
+=== Commands for Common Properties
+
+The common properties are those that are frequently need to be customized in a Solr instance. They are manipulated with two commands:
+
+* `set-property`: Set a well known property. The names of the properties are predefined and fixed. If the property has already been set, this command will overwrite the previous setting.
+* `unset-property`: Remove a property set using the `set-property` command.
+
+The properties that are configured with these commands are predefined and listed below. The names of these properties are derived from their XML paths as found in `solrconfig.xml`.
+
+* `updateHandler.autoCommit.maxDocs`
+* `updateHandler.autoCommit.maxTime`
+* `updateHandler.autoCommit.openSearcher`
+* `updateHandler.autoSoftCommit.maxDocs`
+* `updateHandler.autoSoftCommit.maxTime`
+* `updateHandler.commitWithin.softCommit`
+* `updateHandler.indexWriter.closeWaitsForMerges`
+* `query.filterCache.class`
+* `query.filterCache.size`
+* `query.filterCache.initialSize`
+* `query.filterCache.autowarmCount`
+* `query.filterCache.regenerator`
+* `query.queryResultCache.class`
+* `query.queryResultCache.size`
+* `query.queryResultCache.initialSize`
+* `query.queryResultCache.autowarmCount`
+* `query.queryResultCache.regenerator`
+* `query.documentCache.class`
+* `query.documentCache.size`
+* `query.documentCache.initialSize`
+* `query.documentCache.autowarmCount`
+
+* `query.documentCache.regenerator`
+* `query.fieldValueCache.class`
+* `query.fieldValueCache.size`
+* `query.fieldValueCache.initialSize`
+* `query.fieldValueCache.autowarmCount`
+* `query.fieldValueCache.regenerator`
+* `query.useFilterForSortedQuery`
+* `query.queryResultWindowSize`
+* `query.queryResultMaxDocCached`
+* `query.enableLazyFieldLoading`
+* `query.boolToFilterOptimizer`
+* `query.maxBooleanClauses`
+* `jmx.agentId`
+* `jmx.serviceUrl`
+* `jmx.rootName`
+* `requestDispatcher.handleSelect`
+* `requestDispatcher.requestParsers.multipartUploadLimitInKB`
+* `requestDispatcher.requestParsers.formdataUploadLimitInKB`
+* `requestDispatcher.requestParsers.enableRemoteStreaming`
+* `requestDispatcher.requestParsers.addHttpRequestToContext`
+
+[[ConfigAPI-CommandsforCustomHandlersandLocalComponents]]
+=== Commands for Custom Handlers and Local Components
+
+Custom request handlers, search components, and other types of localized Solr components (such as custom query parsers, update processors, etc.) can be added, updated and deleted with specific commands for the component being modified.
+
+The syntax is similar in each case: `add-<component-name>`, `update-<component-name>`, and `delete-<component-name>`. The command name is not case sensitive, so `Add-RequestHandler`, `ADD-REQUESTHANDLER` and `add-requesthandler` are all equivalent.
+
+In each case, `add-` commands add the new configuration to `configoverlay.json`, which will override any other settings for the component in `solrconfig.xml`; `update-` commands overwrite an existing setting in `configoverlay.json`; and `delete-` commands remove the setting from `configoverlay.json`.
+
+Settings removed from `configoverlay.json` are not removed from `solrconfig.xml`.
+
+The full list of available commands follows below:
+
+[[ConfigAPI-GeneralPurposeCommands]]
+==== General Purpose Commands
+
+These commands are the most commonly used:
+
+* `add-requesthandler`
+* `update-requesthandler`
+* `delete-requesthandler`
+* `add-searchcomponent`
+* `update-searchcomponent`
+* `delete-searchcomponent`
+* `add-initparams`
+* `update-initparams`
+* `delete-initparams`
+* `add-queryresponsewriter`
+* `update-queryresponsewriter`
+* `delete-queryresponsewriter`
+
+[[ConfigAPI-AdvancedCommands]]
+==== Advanced Commands
+
+These commands allow registering more advanced customizations to Solr:
+
+* `add-queryparser`
+* `update-queryparser`
+* `delete-queryparser`
+* `add-valuesourceparser`
+* `update-valuesourceparser`
+* `delete-valuesourceparser`
+* `add-transformer`
+* `update-transformer`
+* `delete-transformer`
+* `add-updateprocessor`
+* `update-updateprocessor`
+* `delete-updateprocessor`
+
+* `add-queryconverter`
+* `update-queryconverter`
+* `delete-queryconverter`
+* `add-listener`
+* `update-listener`
+* `delete-listener`
+* `add-runtimelib`
+* `update-runtimelib`
+* `delete-runtimelib`
+
+See the section <<ConfigAPI-CreatingandUpdatingRequestHandlers,Creating and Updating Request Handlers>> below for examples of using these commands.
+
+[[ConfigAPI-Whatabout_updateRequestProcessorChain_]]
+==== What about updateRequestProcessorChain?
+
+The Config API does not let you create or edit `updateRequestProcessorChain` elements. However, it is possible to create `updateProcessor` entries and can use them by name to create a chain.
+
+example:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d '{
+"add-updateprocessor" : { "name" : "firstFld",
+ "class": "solr.FirstFieldValueUpdateProcessorFactory",
+ "fieldName":"test_s"}}'
+----
+
+You can use this directly in your request by adding a parameter in the `updateRequestProcessorChain` for the specific update processor called `processor=firstFld`.
+
+[[ConfigAPI-CommandsforUser-DefinedProperties]]
+=== Commands for User-Defined Properties
+
+Solr lets users templatize the `solrconfig.xml` using the place holder format `${variable_name:default_val}`. You could set the values using system properties, for example, `-Dvariable_name= my_customvalue`. The same can be achieved during runtime using these commands:
+
+* `set-user-property`: Set a user-defined property. If the property has already been set, this command will overwrite the previous setting.
+* `unset-user-property`: Remove a user-defined property.
+
+The structure of the request is similar to the structure of requests using other commands, in the format of `"command":{"variable_name":"property_value"}`. You can add more than one variable at a time if necessary.
+
+For more information about user-defined properties, see the section <<configuring-solrconfig-xml.adoc#Configuringsolrconfig.xml-Userdefinedpropertiesfromcore.properties,User defined properties from core.properties>>.
+
+See also the section <<ConfigAPI-CreatingandUpdatingUser-DefinedProperties,Creating and Updating User-Defined Properties>> below for examples of how to use this type of command.
+
+[[ConfigAPI-HowtoMapsolrconfig.xmlPropertiestoJSON]]
+== How to Map `solrconfig.xml` Properties to JSON
+
+By using this API, you will be generating JSON representations of properties defined in `solrconfig.xml`. To understand how properties should be represented with the API, let's take a look at a few examples.
+
+Here is what a request handler looks like in `solrconfig.xml`:
+
+[source,xml]
+----
+<requestHandler name="/query" class="solr.SearchHandler">
+ <lst name="defaults">
+ <str name="echoParams">explicit</str>
+ <str name="wt">json</str>
+ <str name="indent">true</str>
+ </lst>
+</requestHandler>
+----
+
+The same request handler defined with the Config API would look like this:
+
+[source,json]
+----
+{
+ "add-requesthandler":{
+ "name":"/query",
+ "class":"solr.SearchHandler",
+ "defaults":{
+ "echoParams":"explicit",
+ "wt":"json",
+ "indent":true
+ }
+ }
+}
+----
+
+The QueryElevationComponent searchComponent in `solrconfig.xml` looks like this:
+
+[source,xml]
+----
+<searchComponent name="elevator" class="solr.QueryElevationComponent" >
+ <str name="queryFieldType">string</str>
+ <str name="config-file">elevate.xml</str>
+</searchComponent>
+----
+
+And the same searchComponent with the Config API:
+
+[source,json]
+----
+{
+ "add-searchcomponent":{
+ "name":"elevator",
+ "class":"QueryElevationComponent",
+ "queryFieldType":"string",
+ "config-file":"elevate.xml"
+ }
+}
+----
+
+Removing the searchComponent with the Config API:
+
+[source,json]
+----
+{
+ "delete-searchcomponent":"elevator"
+}
+----
+
+A simple highlighter looks like this in `solrconfig.xml` (example has been truncated for space):
+
+[source,xml]
+----
+<searchComponent class="solr.HighlightComponent" name="highlight">
+ <highlighting>
+ <fragmenter name="gap"
+ default="true"
+ class="solr.highlight.GapFragmenter">
+ <lst name="defaults">
+ <int name="hl.fragsize">100</int>
+ </lst>
+ </fragmenter>
+
+ <formatter name="html"
+ default="true"
+ class="solr.highlight.HtmlFormatter">
+ <lst name="defaults">
+ <str name="hl.simple.pre"><![CDATA[<em>]]></str>
+ <str name="hl.simple.post"><![CDATA[</em>]]></str>
+ </lst>
+ </formatter>
+
+ <encoder name="html" class="solr.highlight.HtmlEncoder" />
+...
+ </highlighting>
+----
+
+The same highlighter with the Config API:
+
+[source,json]
+----
+{
+ "add-searchcomponent": {
+ "name": "highlight",
+ "class": "solr.HighlightComponent",
+ "": {
+ "gap": {
+ "default": "true",
+ "name": "gap",
+ "class": "solr.highlight.GapFragmenter",
+ "defaults": {
+ "hl.fragsize": 100
+ }
+ }
+ },
+ "html": [{
+ "default": "true",
+ "name": "html",
+ "class": "solr.highlight.HtmlFormatter",
+ "defaults": {
+ "hl.simple.pre": "before-",
+ "hl.simple.post": "-after"
+ }
+ }, {
+ "name": "html",
+ "class": "solr.highlight.HtmlEncoder"
+ }]
+ }
+}
+----
+
+Set autoCommit properties in `solrconfig.xml`:
+
+[source,xml]
+----
+<autoCommit>
+ <maxTime>15000</maxTime>
+ <openSearcher>false</openSearcher>
+</autoCommit>
+----
+
+Define the same properties with the Config API:
+
+[source,json]
+----
+{
+ "set-property": {
+ "updateHandler.autoCommit.maxTime":15000,
+ "updateHandler.autoCommit.openSearcher":false
+ }
+}
+----
+
+[[ConfigAPI-NameComponentsfortheConfigAPI]]
+=== Name Components for the Config API
+
+The Config API always allows changing the configuration of any component by name. However, some configurations such as `listener` or `initParams` do not require a name in `solrconfig.xml`. In order to be able to `update` and `delete` of the same item in `configoverlay.json`, the name attribute becomes mandatory.
+
+[[ConfigAPI-Examples]]
+== Examples
+
+[[ConfigAPI-CreatingandUpdatingCommonProperties]]
+=== Creating and Updating Common Properties
+
+This change sets the `query.filterCache.autowarmCount` to 1000 items and unsets the `query.filterCache.size`.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d'{
+ "set-property" : {"query.filterCache.autowarmCount":1000},
+ "unset-property" :"query.filterCache.size"}'
+----
+
+Using the `/config/overlay` endpoint, you can verify the changes with a request like this:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/config/overlay?omitHeader=true
+----
+
+And you should get a response like this:
+
+[source,json]
+----
+{
+ "overlay":{
+ "znodeVersion":1,
+ "props":{"query":{"filterCache":{
+ "autowarmCount":1000,
+ "size":25}}}}}
+----
+
+[[ConfigAPI-CreatingandUpdatingRequestHandlers]]
+=== Creating and Updating Request Handlers
+
+To create a request handler, we can use the `add-requesthandler` command:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d '{
+ "add-requesthandler" : {
+ "name": "/mypath",
+ "class":"solr.DumpRequestHandler",
+ "defaults":{ "x":"y" ,"a":"b", "wt":"json", "indent":true },
+ "useParams":"x"
+ }
+}'
+----
+
+Make a call to the new request handler to check if it is registered:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/mypath?omitHeader=true
+----
+
+And you should see the following as output:
+
+[source,json]
+----
+{
+ "params":{
+ "indent":"true",
+ "a":"b",
+ "x":"y",
+ "wt":"json"},
+ "context":{
+ "webapp":"/solr",
+ "path":"/mypath",
+ "httpMethod":"GET"}}
+----
+
+To update a request handler, you should use the `update-requesthandler` command :
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d '{
+ "update-requesthandler": {
+ "name": "/mypath",
+ "class":"solr.DumpRequestHandler",
+ "defaults": {"x":"new value for X", "wt":"json", "indent":true},
+ "useParams":"x"
+ }
+}'
+----
+
+As another example, we'll create another request handler, this time adding the 'terms' component as part of the definition:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H 'Content-type:application/json' -d '{
+ "add-requesthandler": {
+ "name": "/myterms",
+ "class":"solr.SearchHandler",
+ "defaults": {"terms":true, "distrib":false},
+ "components": [ "terms" ]
+ }
+}'
+----
+
+[[ConfigAPI-CreatingandUpdatingUser-DefinedProperties]]
+=== Creating and Updating User-Defined Properties
+
+This command sets a user property.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H'Content-type:application/json' -d '{
+ "set-user-property" : {"variable_name":"some_value"}}'
+----
+
+Again, we can use the `/config/overlay` endpoint to verify the changes have been made:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config/overlay?omitHeader=true
+----
+
+And we would expect to see output like this:
+
+[source,json]
+----
+{"overlay":{
+ "znodeVersion":5,
+ "userProps":{
+ "variable_name":"some_value"}}
+}
+----
+
+To unset the variable, issue a command like this:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H'Content-type:application/json' -d '{"unset-user-property" : "variable_name"}'
+----
+
+[[ConfigAPI-HowItWorks]]
+== How It Works
+
+Every core watches the ZooKeeper directory for the configset being used with that core. In standalone mode, however, there is no watch (because ZooKeeper is not running). If there are multiple cores in the same node using the same configset, only one ZooKeeper watch is used. For instance, if the configset 'myconf' is used by a core, the node would watch `/configs/myconf`. Every write operation performed through the API would 'touch' the directory (sets an empty byte[] to trigger watches) and all watchers are notified. Every core would check if the Schema file, `solrconfig.xml` or `configoverlay.json` is modified by comparing the `znode` versions and if modified, the core is reloaded.
+
+If `params.json` is modified, the params object is just updated without a core reload (see the section <<request-parameters-api.adoc#request-parameters-api,Request Parameters API>> for more information about `params.json`).
+
+[[ConfigAPI-EmptyCommand]]
+=== Empty Command
+
+If an empty command is sent to the `/config` endpoint, the watch is triggered on all cores using this configset. For example:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/techproducts/config -H'Content-type:application/json' -d '{}'
+----
+
+Directly editing any files without 'touching' the directory *will not* make it visible to all nodes.
+
+It is possible for components to watch for the configset 'touch' events by registering a listener using `SolrCore#registerConfListener()` .
+
+[[ConfigAPI-ListeningtoconfigChanges]]
+=== Listening to config Changes
+
+Any component can register a listener using:
+
+`SolrCore#addConfListener(Runnable listener)`
+
+to get notified for config changes. This is not very useful if the files modified result in core reloads (i.e., `configoverlay.xml` or Schema). Components can use this to reload the files they are interested in.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/config-sets.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/config-sets.adoc b/solr/solr-ref-guide/src/config-sets.adoc
new file mode 100644
index 0000000..3c67e7e
--- /dev/null
+++ b/solr/solr-ref-guide/src/config-sets.adoc
@@ -0,0 +1,26 @@
+= Config Sets
+:page-shortname: config-sets
+:page-permalink: config-sets.html
+
+On a multicore Solr instance, you may find that you want to share configuration between a number of different cores. You can achieve this using named configsets, which are essentially shared configuration directories stored under a configurable configset base directory.
+
+To create a configset, simply add a new directory under the configset base directory. The configset will be identified by the name of this directory. Then into this copy the config directory you want to share. The structure should look something like this:
+
+[source,bash]
+----
+/<configSetBaseDir>
+ /configset1
+ /conf
+ /managed-schema
+ /solrconfig.xml
+ /configset2
+ /conf
+ /managed-schema
+ /solrconfig.xml
+----
+
+The default base directory is `$SOLR_HOME/configsets`, and it can be configured in `solr.xml`.
+
+To create a new core using a configset, pass `configSet` as one of the core properties. For example, if you do this via the core admin API:
+
+`\http://localhost:8983/admin/cores?action=CREATE&name=mycore&instanceDir=path/to/instance&configSet=configset2`
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/configsets-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/configsets-api.adoc b/solr/solr-ref-guide/src/configsets-api.adoc
new file mode 100644
index 0000000..505fcbe
--- /dev/null
+++ b/solr/solr-ref-guide/src/configsets-api.adoc
@@ -0,0 +1,155 @@
+= ConfigSets API
+:page-shortname: configsets-api
+:page-permalink: configsets-api.html
+
+The ConfigSets API enables you to create, delete, and otherwise manage ConfigSets.
+
+To use a ConfigSet created with this API as the configuration for a collection, use the <<collections-api.adoc#collections-api,Collections API>>.
+
+This API can only be used with Solr running in SolrCloud mode. If you are not running Solr in SolrCloud mode but would still like to use shared configurations, please see the section <<config-sets.adoc#config-sets,Config Sets>>.
+
+[[ConfigSetsAPI-APIEntryPoints]]
+== API Entry Points
+
+The base URL for all API calls is `\http://<hostname>:<port>/solr`.
+
+* `/admin/configs?action=CREATE`: <<ConfigSetsAPI-create,create>> a ConfigSet, based on an existing ConfigSet
+* `/admin/configs?action=DELETE`: <<ConfigSetsAPI-delete,delete>> a ConfigSet
+* `/admin/configs?action=LIST`: <<ConfigSetsAPI-list,list>> all ConfigSets
+
+[[ConfigSetsAPI-createCreateaConfigSet]]
+
+[[ConfigSetsAPI-create]]
+== Create a ConfigSet
+
+`/admin/configs?action=CREATE&name=_name_&baseConfigSet=_baseConfigSet_`
+
+Create a ConfigSet, based on an existing ConfigSet.
+
+[[ConfigSetsAPI-Input]]
+=== Input
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="20,15,10,15,40",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|name |String |Yes | |ConfigSet to be created
+|baseConfigSet |String |Yes | |ConfigSet to copy as a base
+|configSetProp._name=value_ |String |No | |ConfigSet property from base to override
+|===
+
+[[ConfigSetsAPI-Output]]
+=== Output
+
+*Output Content*
+
+The output will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.
+
+[[ConfigSetsAPI-Examples]]
+=== Examples
+
+*Input*
+
+Create a ConfigSet named 'myConfigSet' based on a 'predefinedTemplate' ConfigSet, overriding the immutable property to false.
+
+[source,text]
+----
+http://localhost:8983/solr/admin/configs?action=CREATE&name=myConfigSet&baseConfigSet=predefinedTemplate&configSetProp.immutable=false
+----
+
+*Output*
+
+[source,xml]
+----
+<response>
+ <lst name="responseHeader">
+ <int name="status">0</int>
+ <int name="QTime">323</int>
+ </lst>
+</response>
+----
+
+[[ConfigSetsAPI-deleteDeleteaConfigSet]]
+
+[[ConfigSetsAPI-delete]]
+== Delete a ConfigSet
+
+`/admin/configs?action=DELETE&name=_name_`
+
+Delete a ConfigSet
+
+[[ConfigSetsAPI-Input.1]]
+=== Input
+
+*Query Parameters*
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="20,15,10,15,40",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|name |String |Yes | |ConfigSet to be deleted
+|===
+
+[[ConfigSetsAPI-Output.1]]
+=== Output
+
+*Output Content*
+
+The output will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.
+
+[[ConfigSetsAPI-Examples.1]]
+=== Examples
+
+*Input*
+
+Delete ConfigSet 'myConfigSet'
+
+[source,text]
+----
+http://localhost:8983/solr/admin/configs?action=DELETE&name=myConfigSet
+----
+
+*Output*
+
+[source,xml]
+----
+<response>
+ <lst name="responseHeader">
+ <int name="status">0</int>
+ <int name="QTime">170</int>
+ </lst>
+</response>
+----
+
+[[ConfigSetsAPI-listListConfigSets]]
+
+[[ConfigSetsAPI-list]]
+== List ConfigSets
+
+`/admin/configs?action=LIST`
+
+Fetch the names of the ConfigSets in the cluster.
+
+[[ConfigSetsAPI-Examples.2]]
+=== Examples
+
+*Input*
+
+[source,text]
+----
+http://localhost:8983/solr/admin/configs?action=LIST&wt=json
+----
+
+*Output*
+
+[source,json]
+----
+{
+ "responseHeader":{
+ "status":0,
+ "QTime":203},
+ "configSets":["myConfigSet1",
+ "myConfig2"]}
+----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/configuration-apis.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/configuration-apis.adoc b/solr/solr-ref-guide/src/configuration-apis.adoc
new file mode 100644
index 0000000..dcbcbe1
--- /dev/null
+++ b/solr/solr-ref-guide/src/configuration-apis.adoc
@@ -0,0 +1,11 @@
+= Configuration APIs
+:page-shortname: configuration-apis
+:page-permalink: configuration-apis.html
+:page-children: blob-store-api, config-api, request-parameters-api, managed-resources
+
+Solr includes several APIs that can be used to modify settings in `solrconfig.xml`.
+
+* <<blob-store-api.adoc#blob-store-api,Blob Store API>>
+* <<config-api.adoc#config-api,Config API>>
+* <<request-parameters-api.adoc#request-parameters-api,Request Parameters API>>
+* <<managed-resources.adoc#managed-resources,Managed Resources>>
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/configuring-logging.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/configuring-logging.adoc b/solr/solr-ref-guide/src/configuring-logging.adoc
new file mode 100644
index 0000000..47fe649
--- /dev/null
+++ b/solr/solr-ref-guide/src/configuring-logging.adoc
@@ -0,0 +1,110 @@
+= Configuring Logging
+:page-shortname: configuring-logging
+:page-permalink: configuring-logging.html
+
+Solr logs are a key way to know what's happening in the system. There are several ways to adjust the default logging configuration.
+
+[IMPORTANT]
+====
+In addition to the logging options described below, there is a way to configure which request parameters (such as parameters sent as part of queries) are logged with an additional request parameter called `logParamsList`. See the section on <<common-query-parameters.adoc#CommonQueryParameters-ThelogParamsListParameter,Common Query Parameters>> for more information.
+====
+
+[[ConfiguringLogging-TemporaryLoggingSettings]]
+== Temporary Logging Settings
+
+You can control the amount of logging output in Solr by using the Admin Web interface. Select the *LOGGING* link. Note that this page only lets you change settings in the running system and is not saved for the next run. (For more information about the Admin Web interface, see <<using-the-solr-administration-user-interface.adoc#using-the-solr-administration-user-interface,Using the Solr Administration User Interface>>.)
+
+.The Logging Screen
+image::images/logging/logging.png[image]
+
+This part of the Admin Web interface allows you to set the logging level for many different log categories. Fortunately, any categories that are *unset* will have the logging level of its parent. This makes it possible to change many categories at once by adjusting the logging level of their parent.
+
+When you select **Level**, you see the following menu:
+
+.The Log Level Menu
+image::images/logging/level_menu.png[image,width=1159,height=577]
+
+Directories are shown with their current logging levels. The Log Level Menu floats over these. To set a log level for a particular directory, select it and click the appropriate log level button.
+
+Log levels settings are as follows:
+
+[width="100%",options="header",]
+|===
+|Level |Result
+|FINEST |Reports everything.
+|FINE |Reports everything but the least important messages.
+|CONFIG |Reports configuration errors.
+|INFO |Reports everything but normal status.
+|WARN |Reports all warnings.
+|SEVERE |Reports only the most severe warnings.
+|OFF |Turns off logging.
+|UNSET |Removes the previous log setting.
+|===
+
+Multiple settings at one time are allowed.
+
+[[ConfiguringLogging-LoglevelAPI]]
+=== Log level API
+
+There is also a way of sending REST commands to the logging endpoint to do the same. Example:
+
+[source,bash]
+----
+# Set the root logger to level WARN
+curl -s http://localhost:8983/solr/admin/info/logging --data-binary "set=root:WARN&wt=json"
+----
+
+[[ConfiguringLogging-ChoosingLogLevelatStartup]]
+== Choosing Log Level at Startup
+
+You can temporarily choose a different logging level as you start Solr. There are two ways:
+
+The first way is to set the `SOLR_LOG_LEVEL` environment variable before you start Solr, or place the same variable in `bin/solr.in.sh` or `bin/solr.in.cmd`. The variable must contain an uppercase string with a supported log level (see above).
+
+The second way is to start Solr with the -v or -q options, see <<solr-control-script-reference.adoc#solr-control-script-reference,Solr Control Script Reference>> for details. Examples:
+
+[source,bash]
+----
+# Start with verbose (DEBUG) looging
+bin/solr start -f -v
+# Start with quiet (WARN) logging
+bin/solr start -f -q
+----
+
+[[ConfiguringLogging-PermanentLoggingSettings]]
+== Permanent Logging Settings
+
+Solr uses http://logging.apache.org/log4j/1.2/[Log4J version 1.2] for logging which is configured using `server/resources/log4j.properties`. Take a moment to inspect the contents of the `log4j.properties` file so that you are familiar with its structure. By default, Solr log messages will be written to `SOLR_LOGS_DIR/solr.log`.
+
+When you're ready to deploy Solr in production, set the variable `SOLR_LOGS_DIR` to the location where you want Solr to write log files, such as `/var/solr/logs`. You may also want to tweak `log4j.properties`. Note that if you installed Solr as a service using the instructions provided in <<taking-solr-to-production.adoc#taking-solr-to-production,Taking Solr to Production>>, then see `/var/solr/log4j.properties` instead of the default `server/resources` version.
+
+When starting Solr in the foreground (`-f` option), all logs will be sent to the console, in addition to `solr.log`. When starting Solr in the background, it will write all `stdout` and `stderr` output to a log file in `solr-<port>-console.log`, and automatically disable the CONSOLE logger configured in `log4j.properties`, having the same effect as if you removed the CONSOLE appender from the rootLogger manually.
+
+Also, in `log4j.properties` the default log rotation size threshold of 4MB is most likely too small for production servers and should be increased to a larger value (such as 100MB or more).
+
+[source,text]
+----
+log4j.appender.file.MaxFileSize=100MB
+----
+
+Java Garbage Collection logs are rotated by the JVM when size hits 20M, for a max of 9 generations. Old GC logs are moved to `SOLR_LOGS_DIR/archived`. These settings can only be changed by editing the start scripts.
+
+On every startup of Solr, the start script will clean up old logs and rotate the main `solr.log` file. If you changed the `log4j.appender.file.MaxBackupIndex` setting in `log4j.properties`, you also need to change the corresponding setting `-rotate_solr_logs 9` in the start script.
+
+You can disable the automatic log rotation at startup by changing the setting `SOLR_LOG_PRESTART_ROTATION` found in `bin/solr.in.sh` or `bin/solr.in.cmd` to false.
+
+[[ConfiguringLogging-LoggingSlowQueries]]
+== Logging Slow Queries
+
+For high-volume search applications, logging every query can generate a large amount of logs and, depending on the volume, potentially impact performance. If you mine these logs for additional insights into your application, then logging every query request may be useful.
+
+On the other hand, if you're only concerned about warnings and error messages related to requests, then you can set the log verbosity to WARN. However, this poses a potential problem in that you won't know if any queries are slow, as slow queries are still logged at the INFO level.
+
+Solr provides a way to set your log verbosity threshold to WARN and be able to set a latency threshold above which a request is considered "slow" and log that request at the WARN level to help you identify slow queries in your application. To enable this behavior, configure the `<slowQueryThresholdMillis>` element in the *query* section of solrconfig.xml:
+
+[source,xml]
+----
+<slowQueryThresholdMillis>1000</slowQueryThresholdMillis>
+----
+
+Any queries that take longer than the specified threshold will be logged as "slow" queries at the WARN level.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc b/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
new file mode 100644
index 0000000..4c2b88c
--- /dev/null
+++ b/solr/solr-ref-guide/src/configuring-solrconfig-xml.adoc
@@ -0,0 +1,155 @@
+= Configuring solrconfig.xml
+:page-shortname: configuring-solrconfig-xml
+:page-permalink: configuring-solrconfig-xml.html
+:page-children: datadir-and-directoryfactory-in-solrconfig, lib-directives-in-solrconfig, schema-factory-definition-in-solrconfig, indexconfig-in-solrconfig, requesthandlers-and-searchcomponents-in-solrconfig, initparams-in-solrconfig, updatehandlers-in-solrconfig, query-settings-in-solrconfig, requestdispatcher-in-solrconfig, update-request-processors, codec-factory
+
+The `solrconfig.xml` file is the configuration file with the most parameters affecting Solr itself.
+
+While configuring Solr, you'll work with `solrconfig.xml` often, either directly or via the <<config-api.adoc#config-api,Config API>> to create "configuration overlays" (`configoverlay.json`) to override the values in `solrconfig.xml`.
+
+In `solrconfig.xml`, you configure important features such as:
+
+* request handlers, which process the requests to Solr, such as requests to add documents to the index or requests to return results for a query
+
+* listeners, processes that "listen" for particular query-related events; listeners can be used to trigger the execution of special code, such as invoking some common queries to warm-up caches
+
+* the Request Dispatcher for managing HTTP communications
+
+* the Admin Web interface
+
+* parameters related to replication and duplication (these parameters are covered in detail in <<legacy-scaling-and-distribution.adoc#legacy-scaling-and-distribution,Legacy Scaling and Distribution>>)
+
+The `solrconfig.xml` file is located in the `conf/` directory for each collection. Several well-commented example files can be found in the `server/solr/configsets/` directories demonstrating best practices for many different types of installations.
+
+We've covered the options in the following sections:
+
+* <<datadir-and-directoryfactory-in-solrconfig.adoc#datadir-and-directoryfactory-in-solrconfig,DataDir and DirectoryFactory in SolrConfig>>
+* <<lib-directives-in-solrconfig.adoc#lib-directives-in-solrconfig,Lib Directives in SolrConfig>>
+* <<schema-factory-definition-in-solrconfig.adoc#schema-factory-definition-in-solrconfig,Schema Factory Definition in SolrConfig>>
+* <<indexconfig-in-solrconfig.adoc#indexconfig-in-solrconfig,IndexConfig in SolrConfig>>
+* <<requesthandlers-and-searchcomponents-in-solrconfig.adoc#requesthandlers-and-searchcomponents-in-solrconfig,RequestHandlers and SearchComponents in SolrConfig>>
+* <<initparams-in-solrconfig.adoc#initparams-in-solrconfig,InitParams in SolrConfig>>
+* <<updatehandlers-in-solrconfig.adoc#updatehandlers-in-solrconfig,UpdateHandlers in SolrConfig>>
+* <<query-settings-in-solrconfig.adoc#query-settings-in-solrconfig,Query Settings in SolrConfig>>
+* <<requestdispatcher-in-solrconfig.adoc#requestdispatcher-in-solrconfig,RequestDispatcher in SolrConfig>>
+* <<update-request-processors.adoc#update-request-processors,Update Request Processors>>
+* <<codec-factory.adoc#codec-factory,Codec Factory>>
+
+[[Configuringsolrconfig.xml-SubstitutingPropertiesinSolrConfigFiles]]
+== Substituting Properties in Solr Config Files
+
+Solr supports variable substitution of property values in config files, which allows runtime specification of various configuration options in `solrconfig.xml`. 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 configuration file will generate an error when parsed.
+
+There are multiple methods for specifying properties that can be used in configuration files. Of those below, strongly consider "config overlay" as the preferred approach, as it stays local to the config set and because it's easy to modify.
+
+[[Configuringsolrconfig.xml-JVMSystemProperties]]
+=== JVM System Properties
+
+Any JVM System properties, usually specified using the `-D` flag when starting the JVM, can be used as variables in any XML configuration file in Solr.
+
+For example, in the sample `solrconfig.xml` files, you will see this value which defines the locking type to use:
+
+[source,xml]
+----
+<lockType>${solr.lock.type:native}</lockType>
+----
+
+Which means the lock type defaults to "native" but when starting Solr, you could override this using a JVM system property by launching the Solr it with:
+
+[source,bash]
+----
+bin/solr start -Dsolr.lock.type=none
+----
+
+In general, any Java system property that you want to set can be passed through the `bin/solr` script using the standard `-Dproperty=value` syntax. Alternatively, you can add common system properties to the `SOLR_OPTS` environment variable defined in the Solr include file (`bin/solr.in.sh` or `bin/solr.in.cmd`). For more information about how the Solr include file works, refer to: <<taking-solr-to-production.adoc#taking-solr-to-production,Taking Solr to Production>>.
+
+[[Configuringsolrconfig.xml-ConfigAPI]]
+=== Config API
+
+The <<config-api.adoc#config-api,Config API>> allows you to use an API to modify Solr's configuration, specifically user defined properties. Changes made with this API are stored in a file named `configoverlay.json`. This file should only be edited with the API, but will look like this example:
+
+[source,json]
+----
+{"userProps":{
+ "dih.db.url":"jdbc:oracle:thin:@localhost:1521",
+ "dih.db.user":"username",
+ "dih.db.pass":"password"}}
+----
+
+For more details, see the section <<config-api.adoc#config-api,Config API>>.
+
+[[Configuringsolrconfig.xml-solrcore.properties]]
+=== solrcore.properties
+
+If the configuration directory for a Solr core contains a file named `solrcore.properties` that file can contain any arbitrary user defined property names and values using the Java standard https://en.wikipedia.org/wiki/.properties[properties file format], and those properties can be used as variables in the XML configuration files for that Solr core.
+
+For example, the following `solrcore.properties` file could be created in the `conf/` directory of a collection using one of the example configurations, to override the lockType used.
+
+[source,bash]
+----
+#conf/solrcore.properties
+solr.lock.type=none
+----
+
+.Deprecation
+[WARNING]
+====
+`solrcore.properties` won't work in SolrCloud mode (it is not read from ZooKeeper). This feature is likely to be removed in the future. Instead, use another mechanism like a config overlay.
+====
+
+[IMPORTANT]
+====
+
+The path and name of the `solrcore.properties` file can be overridden using the `properties` property in <<defining-core-properties.adoc#defining-core-properties,`core.properties`>>.
+
+====
+
+[[Configuringsolrconfig.xml-Userdefinedpropertiesfromcore.properties]]
+=== User-Defined Properties in `core.properties`
+
+Every Solr core has a `core.properties` file, automatically created when using the APIs. When you create a SolrCloud collection, you can pass through custom parameters to go into each core.properties that will be created, by prefixing the parameter name with "property." as a URL parameter. Example:
+
+http://localhost:8983/solr/admin/collections?action=CREATE&name=gettingstarted&numShards=1&property.my.custom.prop=edismax
+
+That would create a `core.properties` file that has at least the following properties (others omitted for brevity):
+
+[source,bash]
+----
+#core.properties
+name=gettingstarted
+my.custom.prop=edismax
+----
+
+The `my.custom.prop` property can then be used as a variable, such as in `solrconfig.xml`:
+
+[source,xml]
+----
+<requestHandler name="/select">
+ <lst name="defaults">
+ <str name="defType">${my.custom.prop}</str>
+ </lst>
+</requestHandler>
+----
+
+[[Configuringsolrconfig.xml-ImplicitCoreProperties]]
+=== Implicit Core Properties
+
+Several attributes of a Solr core are available as "implicit" properties that can be used in variable substitution, independent of where or how they underlying value is initialized. For example: regardless of whether the name for a particular Solr core is explicitly configured in `core.properties` or inferred from the name of the instance directory, the implicit property `solr.core.name` is available for use as a variable in that core's configuration file...
+
+[source,xml]
+----
+<requestHandler name="/select">
+ <lst name="defaults">
+ <str name="collection_name">${solr.core.name}</str>
+ </lst>
+</requestHandler>
+----
+
+All implicit properties use the `solr.core.` name prefix, and reflect the runtime value of the equivalent <<defining-core-properties.adoc#defining-core-properties,`core.properties` property>>:
+
+* `solr.core.name`
+* `solr.core.config`
+* `solr.core.schema`
+* `solr.core.dataDir`
+* `solr.core.transient`
+* `solr.core.loadOnStartup`
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/content-streams.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/content-streams.adoc b/solr/solr-ref-guide/src/content-streams.adoc
new file mode 100644
index 0000000..f26467a
--- /dev/null
+++ b/solr/solr-ref-guide/src/content-streams.adoc
@@ -0,0 +1,48 @@
+= Content Streams
+:page-shortname: content-streams
+:page-permalink: content-streams.html
+
+Content streams are bulk data passed with a request to Solr.
+
+When Solr RequestHandlers are accessed using path based URLs, the `SolrQueryRequest` object containing the parameters of the request may also contain a list of ContentStreams containing bulk data for the request. (The name SolrQueryRequest is a bit misleading: it is involved in all requests, regardless of whether it is a query request or an update request.)
+
+[[ContentStreams-StreamSources]]
+== Stream Sources
+
+Currently request handlers can get content streams in a variety of ways:
+
+* For multipart file uploads, each file is passed as a stream.
+* For POST requests where the content-type is not `application/x-www-form-urlencoded`, the raw POST body is passed as a stream. The full POST body is parsed as parameters and included in the Solr parameters.
+* The contents of parameter `stream.body` is passed as a stream.
+* If remote streaming is enabled and URL content is called for during request handling, the contents of each `stream.url` and `stream.file` parameters are fetched and passed as a stream.
+
+By default, curl sends a `contentType="application/x-www-form-urlencoded"` header. If you need to test a SolrContentHeader content stream, you will need to set the content type with curl's `-H` flag.
+
+[[ContentStreams-RemoteStreaming]]
+== RemoteStreaming
+
+Remote streaming lets you send the contents of a URL as a stream to a given SolrRequestHandler. You could use remote streaming to send a remote or local file to an update plugin.
+
+For convenience, remote streaming is enabled in most of the example `solrconfig.xml` files included with Solr, however it is not recommended in a production situation without additional security between you and untrusted remote clients.
+
+[source,xml]
+----
+ <!-- *** WARNING ***
+ The settings below authorize Solr to fetch remote files, You
+ should make sure your system has some authentication before
+ using enableRemoteStreaming="true"
+ -->
+ <requestParsers enableRemoteStreaming="true" />
+----
+
+The default behavior, when `enableRemoteStreaming` is not specified in `solrconfig.xml` is to _not_ allow remote streaming (i.e., `enableRemoteStreaming="false"`).
+
+[IMPORTANT]
+====
+If you `enableRemoteStreaming="true"` is used, be aware that this allows _anyone_ to send a request to any URL or local file. If <<ContentStreams-DebuggingRequests,DumpRequestHandler>> is enabled, it will allow anyone to view any file on your system.
+====
+
+[[ContentStreams-DebuggingRequests]]
+== Debugging Requests
+
+The implicit "dump" RequestHandler (see <<implicit-requesthandlers.adoc#implicit-requesthandlers,Implicit RequestHandlers>>) simply outputs the contents of the SolrQueryRequest using the specified writer type `wt`. This is a useful tool to help understand what streams are available to the RequestHandlers.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/copying-fields.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/copying-fields.adoc b/solr/solr-ref-guide/src/copying-fields.adoc
new file mode 100644
index 0000000..af02df0
--- /dev/null
+++ b/solr/solr-ref-guide/src/copying-fields.adoc
@@ -0,0 +1,40 @@
+= Copying Fields
+:page-shortname: copying-fields
+:page-permalink: copying-fields.html
+
+You might want to interpret some document fields in more than one way. Solr has a mechanism for making copies of fields so that you can apply several distinct field types to a single piece of incoming information.
+
+The name of the field you want to copy is the _source_, and the name of the copy is the _destination_. In `schema.xml`, it's very simple to make copies of fields:
+
+[source,xml]
+----
+<copyField source="cat" dest="text" maxChars="30000" />
+----
+
+In this example, we want Solr to copy the `cat` field to a field named `text`. Fields are copied before <<understanding-analyzers-tokenizers-and-filters.adoc#understanding-analyzers-tokenizers-and-filters,analysis>> is done, meaning you can have two fields with identical original content, but which use different analysis chains and are stored in the index differently.
+
+In the example above, if the `text` destination field has data of its own in the input documents, the contents of the `cat` field will be added as additional values – just as if all of the values had originally been specified by the client. Remember to configure your fields as `multivalued="true"` if they will ultimately get multiple values (either from a multivalued source or from multiple `copyField` directives).
+
+A common usage for this functionality is to create a single "search" field that will serve as the default query field when users or clients do not specify a field to query. For example, `title`, `author`, `keywords`, and `body` may all be fields that should be searched by default, with copy field rules for each field to copy to a `catchall` field (for example, it could be named anything). Later you can set a rule in `solrconfig.xml` to search the `catchall` field by default. One caveat to this is your index will grow when using copy fields. However, whether this becomes problematic for you and the final size will depend on the number of fields being copied, the number of destination fields being copied to, the analysis in use, and the available disk space.
+
+The `maxChars` parameter, an `int` parameter, establishes an upper limit for the number of characters to be copied from the source value when constructing the value added to the destination field. This limit is useful for situations in which you want to copy some data from the source field, but also control the size of index files.
+
+Both the source and the destination of `copyField` can contain either leading or trailing asterisks, which will match anything. For example, the following line will copy the contents of all incoming fields that match the wildcard pattern `*_t` to the text field.:
+
+[source,xml]
+----
+<copyField source="*_t" dest="text" maxChars="25000" />
+----
+
+[IMPORTANT]
+====
+The `copyField` command can use a wildcard (*) character in the `dest` parameter only if the `source` parameter contains one as well. `copyField` uses the matching glob from the source field for the `dest` field name into which the source content is copied.
+====
+
+Copying is done at the stream source level and no copy feeds into another copy. This means that copy fields cannot be chained i.e. _you cannot_ copy from `here` to `there` and then from `there` to `elsewhere`. However, the same source field can be copied to multiple destination fields:
+
+[source,xml]
+----
+<copyField source="here" dest="there"/>
+<copyField source="here" dest="elsewhere"/>
+----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/core-specific-tools.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/core-specific-tools.adoc b/solr/solr-ref-guide/src/core-specific-tools.adoc
new file mode 100644
index 0000000..54144c5
--- /dev/null
+++ b/solr/solr-ref-guide/src/core-specific-tools.adoc
@@ -0,0 +1,36 @@
+= Core-Specific Tools
+:page-shortname: core-specific-tools
+:page-permalink: core-specific-tools.html
+:page-children: ping, plugins-stats-screen, replication-screen, segments-info
+
+The Core-Specific tools are a group of UI screens that allow you to see core-level information.
+
+In the left-hand navigation bar, you will see a pull-down menu titled "Core Selector". Clicking on the menu will show a list of Solr cores hosted on this Solr node, with a search box that can be used to find a specific core by name.
+
+When you select a core from the pull-down, the main display of the page will show some basic metadata about the core, and a secondary menu will appear in the left nav with links to additional core specific administration screens.
+
+You can also define a configuration file called `admin-extra.html` that includes links or other information you would like to display in the "Admin Extra" part of this main screen.
+
+.Core overview screen
+image::images/core-specific-tools/core_dashboard.png[image,width=515,height=250]
+
+The core-specific UI screens are listed below, with a link to the section of this guide to find out more:
+
+// TODO: SOLR-10655 BEGIN: refactor this into a 'core-screens-list.include.adoc' file for reuse
+* <<ping.adoc#ping,Ping>> - lets you ping a named core and determine whether the core is active.
+* <<plugins-stats-screen.adoc#plugins-stats-screen,Plugins/Stats>> - shows statistics for plugins and other installed components.
+* <<replication-screen.adoc#replication-screen,Replication>> - shows you the current replication status for the core, and lets you enable/disable replication.
+* <<segments-info.adoc#segments-info,Segments Info>> - Provides a visualization of the underlying Lucene index segments.
+// TODO: SOLR-10655 END
+
+If you are running a single node instance of Solr, additional UI screens normally displayed on a per-collection bases will also be listed:
+
+// TODO: SOLR-10655 BEGIN: refactor this into a 'collection-screens-list.include.adoc' file for reuse
+* <<analysis-screen.adoc#analysis-screen,Analysis>> - lets you analyze the data found in specific fields.
+* <<dataimport-screen.adoc#dataimport-screen,Dataimport>> - shows you information about the current status of the Data Import Handler.
+* <<documents-screen.adoc#documents-screen,Documents>> - provides a simple form allowing you to execute various Solr indexing commands directly from the browser.
+* <<files-screen.adoc#files-screen,Files>> - shows the current core configuration files such as `solrconfig.xml`.
+* <<query-screen.adoc#query-screen,Query>> - lets you submit a structured query about various elements of a core.
+* <<stream-screen.adoc#stream-screen,Stream>> - allows you to submit streaming expressions and see results and parsing explanations.
+* <<schema-browser-screen.adoc#schema-browser-screen,Schema Browser>> - displays schema data in a browser window.
+// TODO: SOLR-10655 END