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 2019/12/17 20:13:03 UTC
[lucene-solr] branch branch_8_4 updated (cb7765a -> 7f5edd7)
This is an automated email from the ASF dual-hosted git repository.
ctargett pushed a change to branch branch_8_4
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git.
from cb7765a Ref Guide: Upgrade notes for 8.4
new 2fcca58 Ref Guide: make section headings in Headline Case
new 7f5edd7 Ref Guide: fix typos & standardize spellings
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
solr/solr-ref-guide/src/aliases.adoc | 2 +-
.../authentication-and-authorization-plugins.adoc | 2 +-
.../src/cluster-node-management.adoc | 6 +--
solr/solr-ref-guide/src/collection-management.adoc | 32 ++++++++--------
.../solr-ref-guide/src/command-line-utilities.adoc | 2 +-
.../src/common-query-parameters.adoc | 4 +-
solr/solr-ref-guide/src/config-sets.adoc | 4 +-
solr/solr-ref-guide/src/configsets-api.adoc | 2 +-
solr/solr-ref-guide/src/coreadmin-api.adoc | 4 +-
.../src/defining-core-properties.adoc | 2 +-
solr/solr-ref-guide/src/distributed-requests.adoc | 4 +-
solr/solr-ref-guide/src/enabling-ssl.adoc | 2 +-
solr/solr-ref-guide/src/format-of-solr-xml.adoc | 6 ++-
.../src/implicit-requesthandlers.adoc | 2 +-
solr/solr-ref-guide/src/json-query-dsl.adoc | 2 +-
.../src/jwt-authentication-plugin.adoc | 2 +-
.../src/major-changes-in-solr-7.adoc | 4 +-
.../src/major-changes-in-solr-8.adoc | 2 +-
.../src/package-manager-internals.adoc | 43 +++++++++++-----------
solr/solr-ref-guide/src/package-manager.adoc | 31 +++++++---------
.../src/performance-statistics-reference.adoc | 4 +-
solr/solr-ref-guide/src/resource-loading.adoc | 6 +--
solr/solr-ref-guide/src/securing-solr.adoc | 4 +-
.../src/solr-control-script-reference.adoc | 4 +-
.../src/solr-cores-and-solr-xml.adoc | 2 +-
.../solrcloud-autoscaling-policy-preferences.adoc | 18 ++++-----
.../src/solrcloud-autoscaling-triggers.adoc | 4 +-
.../solrcloud-configuration-and-parameters.adoc | 2 +-
solr/solr-ref-guide/src/solrcloud.adoc | 2 +-
.../src/the-dismax-query-parser.adoc | 12 +++---
.../src/updating-parts-of-documents.adoc | 2 +-
...ng-zookeeper-to-manage-configuration-files.adoc | 2 +-
32 files changed, 108 insertions(+), 112 deletions(-)
[lucene-solr] 01/02: Ref Guide: make section headings in Headline
Case
Posted by ct...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
ctargett pushed a commit to branch branch_8_4
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git
commit 2fcca580441ca187c99bf2973df3e710e6561ef6
Author: Cassandra Targett <ca...@lucidworks.com>
AuthorDate: Tue Dec 17 12:12:34 2019 -0600
Ref Guide: make section headings in Headline Case
---
.../src/package-manager-internals.adoc | 37 +++++++++++-----------
solr/solr-ref-guide/src/package-manager.adoc | 27 +++++++---------
.../src/solr-control-script-reference.adoc | 4 +--
.../solrcloud-autoscaling-policy-preferences.adoc | 10 +++---
4 files changed, 36 insertions(+), 42 deletions(-)
diff --git a/solr/solr-ref-guide/src/package-manager-internals.adoc b/solr/solr-ref-guide/src/package-manager-internals.adoc
index 470d076..3a8589f 100644
--- a/solr/solr-ref-guide/src/package-manager-internals.adoc
+++ b/solr/solr-ref-guide/src/package-manager-internals.adoc
@@ -17,7 +17,7 @@ At the heart of the system, we have classloader isolation. To achieve this, the
The root classloader which has all the jars from Solr classpath. This requires Solr node restart to change anything.
A set of named classloaders that inherit from the root classloader. The life cycles of the named classloaders are tied to the package configuration in ZK. As soon as the configuration is modified, the corresponding classloaders are reloaded and components are asked to reload.
-== Package loading security
+== Package Loading Security
Packages are disabled by default. Start all your nodes with the system property `-Denable.packages=true` to use this feature.
*Example*
@@ -27,7 +27,7 @@ Packages are disabled by default. Start all your nodes with the system property
$ bin/solr -c -Denable.packages=true
----
-=== Upload your keys
+=== Upload Your Keys
Package binaries must be signed with your private keys and ensure your public keys are published in Zookeeper
*Example*
@@ -51,7 +51,7 @@ Package store is a distributed file store which can store arbitrary files in the
* Users can’t create files starting with period (.)
* It is agnostic of content type of files. You may store jars as well as other files.
-=== How does the Package Store work?
+=== How Does the Package Store Work?
When a file is uploaded to the PackageStore ,
* It’s saved to the local file system
@@ -67,7 +67,7 @@ The end points are
* `GET /api/node/files/{full/path/to/file}?meta=true` get the metadata of the file
* `GET /api/node/files/{full/path/to/}` get the list of files in `/full/path/to`
-=== Signing your artifacts
+=== Signing Your Artifacts
Use the following steps to upload a jar signed with your public key:
@@ -116,13 +116,13 @@ A Package have the following attributes:
For every package / version in the packages definition, there is a unique `SolrResourceLoader` instance. This is a child of the `CoreContainer` resource loader.
-=== `packages.json`
+=== packages.json
The package configurations live in a file called /packages.json in Zookeeper. At any given moment we can have multiple versions of a given package in the package configuration. The system will always use the latest version . Versions are sorted by their numeric value and the biggest is the latest.
*example:*
-[source, json]
+[source,json]
----
{
"packages" : {
@@ -134,44 +134,46 @@ The package configurations live in a file called /packages.json in Zookeeper. At
},
{"version" : "0.2",
"files" : ["/path/to/myplugin/1.0/plugin.jar"]
- }]}},
+ }]}}}
----
-== API end points
+== API Endpoints
* `GET /api/cluster/package` Get the list of packages
* `POST /api/cluster/package` edit packages
** `add` command: add a version of a package
** `delete` command : delete a version of a package
-=== How to upgrade?
+=== How to Upgrade?
Use the add command to add a version that is bigger than the current version
-=== How to downgrade ?
+=== How to Downgrade ?
Use the delete command to delete a version that is the highest and the next highest version will be chosen
-=== Using multiple versions in parallel in each collection
+=== Using Multiple Versions in Parallel
We use the `params.json` in the collection config to store a version of a package it uses. by default it is the $LATEST.
+
[source, json]
----
{"params":{
"PKG_VERSIONS": {
"mypkg": "0.1",
"pkg2" : "$LATEST",
- }}
+ }}}
----
+
* for `mypkg` use the version `0.1` irrespective of whether there is a newer version is available or not
* for `pkg2` use the latest. This is optional. The default is ‘$LATEST’
-=== The workflow
+=== The Workflow
* A new version of a package is added
* The package loader loads the classes and notifies every plugin holder of the availability of the new version
* It checks if it is supposed to use a specific version, Ignore the update
* If not, reload the plugin
-=== Using them in Plugins
+=== Using Them in Plugins
Any class name can be prefixed with the packagename e.g : `mypkg:fully.qualified.ClassName` and Solr would use the latest version of the package to load the classes from. The plugins loaded from packages cannot depend on core level classes.
*Plugin declaration in `solrconfig.xml`*
@@ -182,7 +184,7 @@ Any class name can be prefixed with the packagename e.g : `mypkg:fully.qualified
</requestHandler>
----
-=== Full working example
+=== Full Working Example
1) create a package
@@ -339,7 +341,7 @@ $ curl http://localhost:8983/solr/gettingstarted/test?omitHeader=true
----
Note that the `Version` value is `"2"` . So the plugin is updated
-=== How to avoid automatic upgrade (while only using internal APIs)?
+=== How to Avoid Automatic Upgrade
The default version used in any collection is always the latest. However, setting a per-collection property in the `params.json` ensures that the versions are always fixed irrespective of the new versions added
@@ -352,6 +354,3 @@ $ curl http://localhost:8983/solr/gettingstarted/config/params -H 'Content-type:
}
}}'
----
-
-
-
diff --git a/solr/solr-ref-guide/src/package-manager.adoc b/solr/solr-ref-guide/src/package-manager.adoc
index edf88a3..ae84c9e 100644
--- a/solr/solr-ref-guide/src/package-manager.adoc
+++ b/solr/solr-ref-guide/src/package-manager.adoc
@@ -18,7 +18,7 @@
// specific language governing permissions and limitations
// under the License.
-== Glossary of terms
+== Glossary of Terms
=== Package
A set of jar files (usually one) containing one or more <<solr-plugins.adoc#solr-plugins,Solr plugins>>. Each jar file is also accompanied by a signature string (which can be verified against a supplied public key).
@@ -36,7 +36,7 @@ The package manager in Solr consists of the following internal components:
In this guide, we will focus on the Package Manager CLI, which essentially uses the other APIs and components internally. For details on the other components (and hence details of inner workings of the package manager), please refer to <<package-manager-internals.adoc#package-manager-internals,Package Manager internals>>.
-== Interacting with the package manager
+== Interacting with the Package Manager
Essentially, these are the phases in using the package manager:
@@ -46,33 +46,30 @@ Essentially, these are the phases in using the package manager:
* Deploying packages on to collections
* Updating packages
-=== Starting Solr with package management support
+=== Starting Solr with Package Management Support
Start all Solr nodes with the `-Denable.packages=true` parameter. There are security consequences in doing so. At a minimum, no unauthorized user should have write access to Zookeeper instances, since it would then be possible to install packages from untrusted sources (e.g. malicious repositories).
[source,bash]
----
-
$ bin/solr -c -Denable.packages=true
----
-=== Adding trusted repositories
+=== Adding Trusted Repositories
In order to install packages into Solr, one has to add a repository hosting the packages. A repository is essentially a web service hosting package artifacts (jar files) and a public key (to validate the signatures of the jar files while installing). Note: Please do not add repositories that you don't trust or control. Also, only add repositories that are based on https and avoid repositories based on http to safeguard against MITM attacks.
[source,bash]
----
-
$ bin/solr package add-repo <name-of-repo> <repo-url>
----
-=== Listing and installing packages
+=== Listing and Installing Packages
To list installed packages:
[source,bash]
----
-
$ bin/solr package list-installed
----
@@ -81,7 +78,6 @@ To list packages available for installation from added repositories:
[source,bash]
----
-
$ bin/solr package list-available
----
@@ -89,15 +85,14 @@ To install a package:
[source,bash]
----
-
$ bin/solr package install <package-name>[:<version>]
----
-=== Deploying a package on to a collection
+=== Deploying a Package to a Collection
Once a package has been installed, the plugins contained in it can be used in a collection, using either of the two methods:
-==== Deploying using `deploy` command
+==== Deploying using deploy Command
This can be done using the package manager's `deploy` command, provided the package supports it (package author's documentation would usually mention that):
[source,bash]
@@ -107,7 +102,7 @@ $ bin/solr package deploy <package-name>:[version] -collections <collection1>[,<
This may prompt you to execute a command to deploy the package. If you pass `-y` to the command, then this prompt can be skipped.
-==== Deploying manually
+==== Deploying Manually
Alternatively, it is also possible manually edit a configset (solrconfig.xml, managedschema / schema.xml etc.) and using it by RELOADing a collection.
Example: Add a request handler from the package `mypackage` to a configset's solrconfig.xml:
@@ -125,7 +120,7 @@ curl "http://localhost:8983/api/collections/collection1/config/params" \
-H 'Content-type:application/json' -d "{set: {PKG_VERSIONS: {mypackage: '1.0.0'}}}"
----
-==== Verifying the deployment
+==== Verifying the Deployment
After deploying, verify that the collection is using the package:
[source,bash]
@@ -134,7 +129,7 @@ After deploying, verify that the collection is using the package:
$ bin/solr package list-deployed -c <collection>
----
-=== Updating packages
+=== Updating Packages
In order to update a package, first step is make sure the updated version is available in the added repositories by running `list-available` command. Next, install the new version of the package from the repositories.
@@ -156,4 +151,4 @@ You can run the `list-deployed` command to verify that this collection is using
== Security
Except the `add-repo` step, all other steps can be executed using a HTTP endpoint in Solr (see <<package-manager-internals.adoc#package-manager-internals,Package Manager internals>>). This step registers the public key of the trusted repository, and hence can only be executed using the package manager (CLI) having direct write access to Zookeeper. Hence, as you can imagine, it is important to protect Zookeeper from unauthorized write access.
-Also, keep in mind, that it is possible to install any package from a trusted and an already added repository. Hence, if you want to use some packages in production, then it is better to setup your own repository and add that to Solr, instead of adding a generic third-party repository that is beyond your administrative control.
\ No newline at end of file
+Also, keep in mind, that it is possible to install any package from a trusted and an already added repository. Hence, if you want to use some packages in production, then it is better to setup your own repository and add that to Solr, instead of adding a generic third-party repository that is beyond your administrative control.
diff --git a/solr/solr-ref-guide/src/solr-control-script-reference.adoc b/solr/solr-ref-guide/src/solr-control-script-reference.adoc
index d676545..644f763 100644
--- a/solr/solr-ref-guide/src/solr-control-script-reference.adoc
+++ b/solr/solr-ref-guide/src/solr-control-script-reference.adoc
@@ -881,7 +881,7 @@ Examples of this command:
`bin/solr zk mkroot /solr/production`
-== Exporting data to a file
+== Exporting Data to a File
*Example*
@@ -897,7 +897,7 @@ Export all documents from a collection `gettingstarted` to a file called `gettin
* `fields`: a comma separated list of fields to be exported.
* `limit` : number of documents, default is 100, send `-1` to import all the documents.
-=== Importing the data to a collection
+=== Importing the Data to a Collection
*Example: importing the `jsonl` files*
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc
index d776092..a998b07 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc
@@ -500,7 +500,7 @@ Number of iterations of the simulation loop. Default is 10.
Results of the simulation contain the initial suggestions, suggestions at each step of the
simulation and the final simulated state of the cluster.
-=== Simulation scenario tool
+=== Simulation Scenario Tool
The autoscaling command-line tool supports also the execution of end-to-end simulation scenarios consisting of
several cluster- and collection-level operations and events.
@@ -520,7 +520,7 @@ Keys and values additionally use www-urlencoded format to avoid meta-characters
The `params` part of the line closely follows a regular Solr params representation on purpose - in many cases
the content of this part of the command is passed directly to the respective collection- or cluster-level API.
-==== Scenario context
+==== Scenario Context
Scenario has a context, which is simply a map of key-value pairs. Before executing each command the context is
updated to contain the current values for the following properties:
@@ -543,7 +543,7 @@ For example, assuming a system property is set 'foo=bar', the following command
load_snapshot path=/tmp/${foo}
----
-==== Scenario commands
+==== Scenario Commands
The following commands are supported (command names are case insensitive, but params aren't):
* `create_cluster numNodes=N[&disableMetricsHistory=false&timeSourcee=simTime:50]` - create a simulated cluster with N nodes
@@ -569,7 +569,7 @@ The following commands are supported (command names are case insensitive, but pa
* `index_docs numDocs=NNN[&start=XXX]` - simulate bulk indexing of a large number of documents.
* `assert condition=(equals | not_equals | null | not_null)&(key=objectPath | value=myValue)[&expected=value]` - assert a condition. When `key` is specified then it can be an object path to complex values present in the scenario's context.
-==== Example scenarios
+==== Example Scenarios
Example scenario testing the behavior of `.autoAddReplicas` trigger:
[source,text]
----
@@ -638,4 +638,4 @@ loop_start iterations=${justCalc}
calculate_suggestions
loop_end
dump redact=true
-----
\ No newline at end of file
+----
[lucene-solr] 02/02: Ref Guide: fix typos & standardize spellings
Posted by ct...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
ctargett pushed a commit to branch branch_8_4
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git
commit 7f5edd7dcd9ce387c9377dbadcf08353bad94def
Author: Cassandra Targett <ca...@lucidworks.com>
AuthorDate: Tue Dec 17 12:59:17 2019 -0600
Ref Guide: fix typos & standardize spellings
---
solr/solr-ref-guide/src/aliases.adoc | 2 +-
.../authentication-and-authorization-plugins.adoc | 2 +-
.../src/cluster-node-management.adoc | 6 ++--
solr/solr-ref-guide/src/collection-management.adoc | 32 +++++++++++-----------
.../solr-ref-guide/src/command-line-utilities.adoc | 2 +-
.../src/common-query-parameters.adoc | 4 +--
solr/solr-ref-guide/src/config-sets.adoc | 4 +--
solr/solr-ref-guide/src/configsets-api.adoc | 2 +-
solr/solr-ref-guide/src/coreadmin-api.adoc | 4 +--
.../src/defining-core-properties.adoc | 2 +-
solr/solr-ref-guide/src/distributed-requests.adoc | 4 +--
solr/solr-ref-guide/src/enabling-ssl.adoc | 2 +-
solr/solr-ref-guide/src/format-of-solr-xml.adoc | 6 ++--
.../src/implicit-requesthandlers.adoc | 2 +-
solr/solr-ref-guide/src/json-query-dsl.adoc | 2 +-
.../src/jwt-authentication-plugin.adoc | 2 +-
.../src/major-changes-in-solr-7.adoc | 4 +--
.../src/major-changes-in-solr-8.adoc | 2 +-
.../src/package-manager-internals.adoc | 6 ++--
solr/solr-ref-guide/src/package-manager.adoc | 4 +--
.../src/performance-statistics-reference.adoc | 4 +--
solr/solr-ref-guide/src/resource-loading.adoc | 6 ++--
solr/solr-ref-guide/src/securing-solr.adoc | 4 +--
.../src/solr-cores-and-solr-xml.adoc | 2 +-
.../solrcloud-autoscaling-policy-preferences.adoc | 8 +++---
.../src/solrcloud-autoscaling-triggers.adoc | 4 +--
.../solrcloud-configuration-and-parameters.adoc | 2 +-
solr/solr-ref-guide/src/solrcloud.adoc | 2 +-
.../src/the-dismax-query-parser.adoc | 12 ++++----
.../src/updating-parts-of-documents.adoc | 2 +-
...ng-zookeeper-to-manage-configuration-files.adoc | 2 +-
31 files changed, 72 insertions(+), 70 deletions(-)
diff --git a/solr/solr-ref-guide/src/aliases.adoc b/solr/solr-ref-guide/src/aliases.adoc
index 58615d8..2bc268a 100644
--- a/solr/solr-ref-guide/src/aliases.adoc
+++ b/solr/solr-ref-guide/src/aliases.adoc
@@ -76,7 +76,7 @@ When adding data, you should usually direct documents to the alias (e.g., refere
The Solr server and `CloudSolrClient` will direct an update request to the first collection that an alias points to.
Once the server receives the data it will perform the necessary routing.
-WARNING: It's extremely important with all routed aliases that the route values NOT change. Re-indexing a document
+WARNING: It's extremely important with all routed aliases that the route values NOT change. Reindexing a document
with a different route value for the same ID produces two distinct documents with the same ID accessible via the alias.
All query time behavior of the routed alias is *_undefined_* and not easily predictable once duplicate ID's exist.
diff --git a/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc b/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc
index 62f40cb..9e8e724 100644
--- a/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc
+++ b/solr/solr-ref-guide/src/authentication-and-authorization-plugins.adoc
@@ -184,6 +184,6 @@ Each Authentication plugin may also decide to secure inter-node requests on its
The `PKIAuthenticationPlugin` provides a built-in authentication mechanism where each Solr node is a super user and is fully trusted by other Solr nodes through the use of Public Key Infrastructure (PKI). Each Authentication plugn may choose to delegate all or some inter-node traffic to the PKI plugin.
-For each outgoing request `PKIAuthenticationPlugin` adds a special header `'SolrAuth'` which carries the timestamp and principal encrypted using the private key of that node. The public key is exposed through an API so that any node can read it whenever it needs it. Any node who gets the request with that header, would get the public key from the sender and decrypt the information. If it is able to decrypt the data, the request trusted. It is invalid if the timestamp is more than 5 secs [...]
+For each outgoing request `PKIAuthenticationPlugin` adds a special header `'SolrAuth'` which carries the timestamp and principal encrypted using the private key of that node. The public key is exposed through an API so that any node can read it whenever it needs it. Any node who gets the request with that header, would get the public key from the sender and decrypt the information. If it is able to decrypt the data, the request trusted. It is invalid if the timestamp is more than 5 secs [...]
The timeout is configurable through a system property called `pkiauth.ttl`. For example, if you wish to bump up the time-to-live to 10 seconds (10000 milliseconds), start each node with a property `'-Dpkiauth.ttl=10000'`.
diff --git a/solr/solr-ref-guide/src/cluster-node-management.adoc b/solr/solr-ref-guide/src/cluster-node-management.adoc
index 2ac7e66..7c28fc8 100644
--- a/solr/solr-ref-guide/src/cluster-node-management.adoc
+++ b/solr/solr-ref-guide/src/cluster-node-management.adoc
@@ -168,7 +168,7 @@ http://localhost:8983/solr/admin/collections?action=CLUSTERPROP&name=urlScheme&v
It is possible to set cluster-wide default values for certain attributes of a collection, using the `defaults` parameter.
*Set/update default values*
-[source]
+[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '
{
@@ -186,7 +186,7 @@ curl -X POST -H 'Content-type:application/json' --data-binary '
----
*Unset the only value of `nrtReplicas`*
-[source]
+[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '
{
@@ -201,7 +201,7 @@ curl -X POST -H 'Content-type:application/json' --data-binary '
----
*Unset all values in `defaults`*
-[source]
+[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '
{ "set-obj-property" : {
diff --git a/solr/solr-ref-guide/src/collection-management.adoc b/solr/solr-ref-guide/src/collection-management.adoc
index d96aac7..99bc0db 100644
--- a/solr/solr-ref-guide/src/collection-management.adoc
+++ b/solr/solr-ref-guide/src/collection-management.adoc
@@ -660,10 +660,10 @@ http://localhost:8983/solr/admin/collections?action=MIGRATE&collection=test1&spl
`/admin/collections?action=REINDEXCOLLECTION&name=_name_`
-The REINDEXCOLLECTION command re-indexes a collection using existing data from the
+The REINDEXCOLLECTION command reindexes a collection using existing data from the
source collection.
-NOTE: Re-indexing is potentially a lossy operation - some of the existing indexed data that is not
+NOTE: Reindexing is potentially a lossy operation - some of the existing indexed data that is not
available as stored fields may be lost, so users should use this command
with caution, evaluating the potential impact by using different source and target
collection names first, and preserving the source collection until the evaluation is
@@ -671,19 +671,19 @@ complete.
The target collection must not exist (and may not be an alias). If the target
collection name is the same as the source collection then first a unique sequential name
-will be generated for the target collection, and then after re-indexing is done an alias
+will be generated for the target collection, and then after reindexing is done an alias
will be created that points from the source name to the actual sequentially-named target collection.
-When re-indexing is started the source collection is put in <<readonlymode,read-only mode>> to ensure that
+When reindexing is started the source collection is put in <<readonlymode,read-only mode>> to ensure that
all source documents are properly processed.
Using optional parameters a different index schema, collection shape (number of shards and replicas)
or routing parameters can be requested for the target collection.
-Re-indexing is executed as a streaming expression daemon, which runs on one of the
+Reindexing is executed as a streaming expression daemon, which runs on one of the
source collection's replicas. It is usually a time-consuming operation so it's recommended to execute
-it as an asynchronous request in order to avoid request time outs. Only one re-indexing operation may
-execute concurrently for a given source collection. Long-running, erroneous or crashed re-indexing
+it as an asynchronous request in order to avoid request time outs. Only one reindexing operation may
+execute concurrently for a given source collection. Long-running, erroneous or crashed reindexing
operations may be terminated by using the `abort` option, which also removes partial results.
=== REINDEXCOLLECTION Parameters
@@ -694,9 +694,9 @@ Source collection name, may be an alias. This parameter is required.
`cmd`::
Optional command. Default command is `start`. Currently supported commands are:
* `start` - default, starts processing if not already running,
-* `abort` - aborts an already running re-indexing (or clears a left-over status after a crash),
+* `abort` - aborts an already running reindexing (or clears a left-over status after a crash),
and deletes partial results,
-* `status` - returns detailed status of a running re-indexing command.
+* `status` - returns detailed status of a running reindexing command.
`target`::
Target collection name, optional. If not specified a unique name will be generated and
@@ -705,10 +705,10 @@ collection name to the unique sequentially-named collection, effectively "hiding
the original source collection from regular update and search operations.
`q`::
-Optional query to select documents for re-indexing. Default value is `\*:*`.
+Optional query to select documents for reindexing. Default value is `\*:*`.
`fl`::
-Optional list of fields to re-index. Default value is `*`.
+Optional list of fields to reindex. Default value is `*`.
`rows`::
Documents are transferred in batches. Depending on the average size of the document large
@@ -732,7 +732,7 @@ be deleted.
`async`::
Optional request ID to track this action which will be <<collections-api.adoc#asynchronous-calls,processed asynchronously>>.
-When the re-indexing process has completed the target collection is marked using
+When the reindexing process has completed the target collection is marked using
`property.rx: "finished"`, and the source collection state is updated to become read-write.
On any errors the command will delete any temporary and target collections and also reset the
state of the source collection's read-only flag.
@@ -770,9 +770,9 @@ for the purpose of indexing and searching. The source collection is assumed to b
}
}
----
-As a result a new collection `.rx_newCollection_2` has been created, with selected documents re-indexed to 3 shards, and
+As a result a new collection `.rx_newCollection_2` has been created, with selected documents reindexed to 3 shards, and
with an alias pointing from `newCollection` to this one. The status also shows that the source collection
-was already an alias to `.rx_newCollection_1`, which was likely a result of a previous re-indexing.
+was already an alias to `.rx_newCollection_1`, which was likely a result of a previous reindexing.
[[colstatus]]
== COLSTATUS: Detailed Status of a Collection's Indexes
@@ -860,7 +860,7 @@ This section also shows `topN` values by size from each field.
Data types shown in the response can be roughly divided into the following groups:
-* `storedFields` - represents the raw uncompressed data in stored fields. Eg. for UTF-8 strings this represents
+* `storedFields` - represents the raw uncompressed data in stored fields. For example, for UTF-8 strings this represents
the aggregated sum of the number of bytes in the strings' UTF-8 representation, for long numbers this is 8 bytes per value, etc.
* `terms_terms` - represents the aggregated size of the term dictionary. The size of this data is affected by the
@@ -876,7 +876,7 @@ has an `omitNorms` flag in the schema, which is common for fields that don't nee
* `termVectors` - represents the aggregated size of term vectors.
-* `docValues_*` - represents aggregated size of doc values, by type (eg. `docValues_numeric`, `docValues_binary`, etc).
+* `docValues_*` - represents aggregated size of doc values, by type (e.g., `docValues_numeric`, `docValues_binary`, etc).
* `points` - represents aggregated size of point values.
diff --git a/solr/solr-ref-guide/src/command-line-utilities.adoc b/solr/solr-ref-guide/src/command-line-utilities.adoc
index 8c5ce09..83be372 100644
--- a/solr/solr-ref-guide/src/command-line-utilities.adoc
+++ b/solr/solr-ref-guide/src/command-line-utilities.adoc
@@ -128,7 +128,7 @@ Using the boostrap command with a ZooKeeper chroot in the `-zkhost` parameter, e
./server/scripts/cloud-scripts/zkcli.sh -zkhost 127.0.0.1:9983 -cmd putfile /my_zk_file.txt /tmp/my_local_file.txt
----
-=== Link a Collection to a ConfigSet
+=== Link a Collection to a Configset
[source,bash]
----
diff --git a/solr/solr-ref-guide/src/common-query-parameters.adoc b/solr/solr-ref-guide/src/common-query-parameters.adoc
index 82d69d6..3a85a06 100644
--- a/solr/solr-ref-guide/src/common-query-parameters.adoc
+++ b/solr/solr-ref-guide/src/common-query-parameters.adoc
@@ -231,7 +231,7 @@ This value is only checked at the time of:
. Document collection
. Doc Values reading
-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, custom components, etc., this parameter is not expected to abort the request. Regular search, JSON Facet and Analytics handler abandon requests in according to this parameter.
+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, custom components, etc., this parameter is not expected to abort the request. Regular search, JSON Facet and Analytics handler abandon requests in according to this parameter.
== segmentTerminateEarly Parameter
@@ -277,7 +277,7 @@ fq=quantity_in_stock:[5 TO *]
fq={!frange l=10 u=100}mul(popularity,price)
fq={!frange cost=200 l=0}pow(mul(sum(1, query('tag:smartphone')), div(1,avg_rating)), 2.3)
-These are the same filters run w/o caching. The simple range query on the `quantity_in_stock` field will be run in parallel with the main query like a traditional lucene filter, while the 2 `frange` filters will only be checked against each document has already matched the main query and the `quantity_in_stock` range query -- first the simpler `mul(popularity,price)` will be checked (because of its implicit `cost=100`) and only if it matches will the final very complex filter (with its [...]
+These are the same filters run w/o caching. The simple range query on the `quantity_in_stock` field will be run in parallel with the main query like a traditional Lucene filter, while the 2 `frange` filters will only be checked against each document has already matched the main query and the `quantity_in_stock` range query -- first the simpler `mul(popularity,price)` will be checked (because of its implicit `cost=100`) and only if it matches will the final very complex filter (with its [...]
[source,text]
q=some keywords
diff --git a/solr/solr-ref-guide/src/config-sets.adoc b/solr/solr-ref-guide/src/config-sets.adoc
index b846dcb..c1752be 100644
--- a/solr/solr-ref-guide/src/config-sets.adoc
+++ b/solr/solr-ref-guide/src/config-sets.adoc
@@ -1,4 +1,4 @@
-= Config Sets
+= Configsets
// Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements. See the NOTICE file
// distributed with this work for additional information
@@ -95,4 +95,4 @@ The Configsets API has some other operations as well, and likewise, so does the
To upload a file to a configset already stored on ZooKeeper, you can use <<solr-control-script-reference.adoc#copy-between-local-files-and-zookeeper-znodes,`bin/solr zk cp`>>.
-CAUTION: By default, ZooKeeper's file size limit is 1MB. If your files are larger than this, you'll need to either <<setting-up-an-external-zookeeper-ensemble.adoc#increasing-the-file-size-limit,increase the ZooKeeper file size limit>> or store them instead <<libs.adoc#lib-directives-in-solrconfig,on the filesystem>>.
\ No newline at end of file
+CAUTION: By default, ZooKeeper's file size limit is 1MB. If your files are larger than this, you'll need to either <<setting-up-an-external-zookeeper-ensemble.adoc#increasing-the-file-size-limit,increase the ZooKeeper file size limit>> or store them instead <<libs.adoc#lib-directives-in-solrconfig,on the filesystem>>.
diff --git a/solr/solr-ref-guide/src/configsets-api.adoc b/solr/solr-ref-guide/src/configsets-api.adoc
index 8d231b6..761bc0e 100644
--- a/solr/solr-ref-guide/src/configsets-api.adoc
+++ b/solr/solr-ref-guide/src/configsets-api.adoc
@@ -27,7 +27,7 @@ Once a configset has been uploaded to ZooKeeper, use the configset name when cre
Configsets do not have to be shared between collections if they are uploaded with this API, but this API makes it easier to do so if you wish. An alternative to uploading your configsets in advance would be to put the configuration files into a directory under `server/solr/configsets` and using the directory name as the `-d` parameter when using `bin/solr create` to create a collection.
-NOTE: 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>>.
+NOTE: 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,Configsets>>.
The API works by passing commands to the `configs` endpoint. The path to the endpoint varies depending on the API being used: the v1 API uses `solr/admin/configs`, while the v2 API uses `api/cluster/configs`. Examples of both types are provided below.
diff --git a/solr/solr-ref-guide/src/coreadmin-api.adoc b/solr/solr-ref-guide/src/coreadmin-api.adoc
index d6c6689..53b3191 100644
--- a/solr/solr-ref-guide/src/coreadmin-api.adoc
+++ b/solr/solr-ref-guide/src/coreadmin-api.adoc
@@ -60,7 +60,7 @@ Your CREATE call must be able to find a configuration, or it will not succeed.
When you are running SolrCloud and create a new core for a collection, the configuration will be inherited from the collection. Each collection is linked to a configName, which is stored in ZooKeeper. This satisfies the configuration requirement. There is something to note, though: if you're running SolrCloud, you should *NOT* use the CoreAdmin API at all. Use the <<collections-api.adoc#collections-api,Collections API>>.
-When you are not running SolrCloud, if you have <<config-sets.adoc#config-sets,Config Sets>> defined, you can use the `configSet` parameter as documented below. If there are no configsets, then the `instanceDir` specified in the CREATE call must already exist, and it must contain a `conf` directory which in turn must contain `solrconfig.xml`, your schema (usually named either `managed-schema` or `schema.xml`), and any files referenced by those configs.
+When you are not running SolrCloud, if you have <<config-sets.adoc#config-sets,Configsets>> defined, you can use the `configSet` parameter as documented below. If there are no configsets, then the `instanceDir` specified in the CREATE call must already exist, and it must contain a `conf` directory which in turn must contain `solrconfig.xml`, your schema (usually named either `managed-schema` or `schema.xml`), and any files referenced by those configs.
The config and schema filenames can be specified with the `config` and `schema` parameters, but these are expert options. One thing you could do to avoid creating the `conf` directory is use `config` and `schema` parameters that point at absolute paths, but this can lead to confusing configurations unless you fully understand what you are doing.
====
@@ -89,7 +89,7 @@ Name of the schema file to use for the core. Please note that if you are using a
Name of the data directory relative to `instanceDir`.
`configSet`::
-Name of the configset to use for this core. For more information, see the section <<config-sets.adoc#config-sets,Config Sets>>.
+Name of the configset to use for this core. For more information, see the section <<config-sets.adoc#config-sets,Configsets>>.
`collection`::
The name of the collection to which this core belongs. The default is the name of the core. `collection._param_=_value_` causes a property of `_param_=_value_` to be set if a new collection is being created. Use `collection.configName=_config-name_` to point to the configuration for a new collection.
diff --git a/solr/solr-ref-guide/src/defining-core-properties.adoc b/solr/solr-ref-guide/src/defining-core-properties.adoc
index dedd513..e96840b 100644
--- a/solr/solr-ref-guide/src/defining-core-properties.adoc
+++ b/solr/solr-ref-guide/src/defining-core-properties.adoc
@@ -74,7 +74,7 @@ The following properties are available:
`dataDir`:: The core's data directory (where indexes are stored) as either an absolute pathname, or a path relative to the value of `instanceDir`. This is `data` by default.
-`configSet`:: The name of a defined configset, if desired, to use to configure the core (see the section <<config-sets.adoc#config-sets,Config Sets>> for more details).
+`configSet`:: The name of a defined configset, if desired, to use to configure the core (see the section <<config-sets.adoc#config-sets,Configsets>> for more details).
`properties`:: The name of the properties file for this core. The value can be an absolute pathname or a path relative to the value of `instanceDir`.
diff --git a/solr/solr-ref-guide/src/distributed-requests.adoc b/solr/solr-ref-guide/src/distributed-requests.adoc
index 4d06728..7b9a109 100644
--- a/solr/solr-ref-guide/src/distributed-requests.adoc
+++ b/solr/solr-ref-guide/src/distributed-requests.adoc
@@ -185,9 +185,9 @@ Applied after sorting by inherent replica attributes, this property defines a fa
+
`random`, the default, randomly shuffles replicas for each request. This distributes requests evenly, but can result in sub-optimal cache usage for shards with replication factor > 1.
+
-`stable:dividend:_paramName_` parses an integer from the value associated with the given param name; this integer is used as the dividend (mod equivalent replica count) to determine (via list rotation) order of preference among equivalent replicas.
+`stable:dividend:_paramName_` parses an integer from the value associated with the given parameter name; this integer is used as the dividend (mod equivalent replica count) to determine (via list rotation) order of preference among equivalent replicas.
+
-`stable[:hash[:_paramName_]]` the string value associated with the given param name is hashed to a dividend that is used to determine replica preference order (analogous to the explicit `dividend` property above); `_paramName_` defaults to `q` if not specified, providing stable routing keyed to the string value of the "main query". Note that this may be inappropriate for some use cases (e.g., static main queries that leverage parameter substitution)
+`stable[:hash[:_paramName_]]` the string value associated with the given parameter name is hashed to a dividend that is used to determine replica preference order (analogous to the explicit `dividend` property above); `_paramName_` defaults to `q` if not specified, providing stable routing keyed to the string value of the "main query". Note that this may be inappropriate for some use cases (e.g., static main queries that leverage parameter substitution)
Examples:
diff --git a/solr/solr-ref-guide/src/enabling-ssl.adoc b/solr/solr-ref-guide/src/enabling-ssl.adoc
index 93cf2ea..4b403c6 100644
--- a/solr/solr-ref-guide/src/enabling-ssl.adoc
+++ b/solr/solr-ref-guide/src/enabling-ssl.adoc
@@ -334,7 +334,7 @@ NOTE: If your operating system does not include curl, you can download binaries
=== Create a SolrCloud Collection using bin/solr
-Create a 2-shard, replicationFactor=1 collection named mycollection using the default configset (_default):
+Create a 2-shard, replicationFactor=1 collection named mycollection using the `_default` configset:
.*nix command
[source,bash]
diff --git a/solr/solr-ref-guide/src/format-of-solr-xml.adoc b/solr/solr-ref-guide/src/format-of-solr-xml.adoc
index 5d95efd..899da94 100644
--- a/solr/solr-ref-guide/src/format-of-solr-xml.adoc
+++ b/solr/solr-ref-guide/src/format-of-solr-xml.adoc
@@ -100,7 +100,7 @@ Sets the maximum number of clauses allowed in any boolean query.
+
This global limit provides a safety constraint on the number of clauses allowed in any boolean queries 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.
+
-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 <<query-settings-in-solrconfig#maxbooleanclauses,`<maxBooleanClauses>` setting 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.
+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 <<query-settings-in-solrconfig#maxbooleanclauses,`<maxBooleanClauses>` setting 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.
+
[source,xml]
----
@@ -216,7 +216,9 @@ A NamedList specifying replica routing preference configuration. This may be use
</lst>
</shardHandlerFactory>
----
-Replica routing may also be specified (overriding defaults) per-request, via the `shards.preference` request parameter. If a request contains both dividend param and hash param, dividend param takes priority for routing. For configuring `stable` routing, the `hash` param implicitly defaults to a hash of the String value of the main query param (i.e., `q`). `dividend` param must be configured explicitly; there is no implicit default. If only `dividend` routing is desired, `hash` may be ex [...]
+Replica routing may also be specified (overriding defaults) per-request, via the `shards.preference` request parameter. If a request contains both `dividend` and `hash`, `dividend` takes priority for routing. For configuring `stable` routing, the `hash` parameter implicitly defaults to a hash of the String value of the main query parameter (i.e., `q`).
++
+The `dividend` parameter must be configured explicitly; there is no implicit default. If only `dividend` routing is desired, `hash` may be explicitly set to the empty string, entirely disabling implicit hash-based routing.
=== The <metrics> Element
diff --git a/solr/solr-ref-guide/src/implicit-requesthandlers.adoc b/solr/solr-ref-guide/src/implicit-requesthandlers.adoc
index 53b8e67..9174b10 100644
--- a/solr/solr-ref-guide/src/implicit-requesthandlers.adoc
+++ b/solr/solr-ref-guide/src/implicit-requesthandlers.adoc
@@ -47,7 +47,7 @@ Logging:: Retrieve and modify registered loggers.
v2: `api/node/logging` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/ShowFileRequestHandler.html[LoggingHandler] |`_ADMIN_LOGGING`
|===
-Luke:: Expose the internal lucene index. This handler must have a collection name in the path to the endpoint.
+Luke:: Expose the internal Lucene index. This handler must have a collection name in the path to the endpoint.
+
*Documentation*: http://wiki.apache.org/solr/LukeRequestHandler
+
diff --git a/solr/solr-ref-guide/src/json-query-dsl.adoc b/solr/solr-ref-guide/src/json-query-dsl.adoc
index 778a1b3..185b1fc 100644
--- a/solr/solr-ref-guide/src/json-query-dsl.adoc
+++ b/solr/solr-ref-guide/src/json-query-dsl.adoc
@@ -270,7 +270,7 @@ include::{example-source-dir}JsonRequestApiTest.java[tag=solrj-ipod-query-bool]
====
--
-If lucene is the default query parser, the example above can be simplified to:
+If `lucene` is the default query parser, the example above can be simplified to:
[.dynamic-tabs]
--
diff --git a/solr/solr-ref-guide/src/jwt-authentication-plugin.adoc b/solr/solr-ref-guide/src/jwt-authentication-plugin.adoc
index b463efb..25b0517 100644
--- a/solr/solr-ref-guide/src/jwt-authentication-plugin.adoc
+++ b/solr/solr-ref-guide/src/jwt-authentication-plugin.adoc
@@ -164,7 +164,7 @@ Let's comment on this config:
== Editing JWT Authentication Plugin Configuration
-All properties mentioned above, except the 'issuers' array, can be set or changed using the Config Edit API. You can thus start with a simple configuration with only `class` configured and then configure the rest using the API.
+All properties mentioned above, except the 'issuers' array, can be set or changed using the <<basic-authentication-plugin.adoc#editing-basic-authentication-plugin-configuration,Authentication API>>. You can thus start with a simple configuration with only `class` configured and then configure the rest using the API.
=== Set a Configuration Property
diff --git a/solr/solr-ref-guide/src/major-changes-in-solr-7.adoc b/solr/solr-ref-guide/src/major-changes-in-solr-7.adoc
index 17d571c..b81552d 100644
--- a/solr/solr-ref-guide/src/major-changes-in-solr-7.adoc
+++ b/solr/solr-ref-guide/src/major-changes-in-solr-7.adoc
@@ -67,7 +67,7 @@ See the section <<solrcloud-autoscaling.adoc#solrcloud-autoscaling,SolrCloud Aut
== Configuration and Default Changes
-=== New Default ConfigSet
+=== New Default Configset
Several changes have been made to configsets that ship with Solr; not only their content but how Solr behaves in regard to them:
* The `data_driven_configset` and `basic_configset` have been removed, and replaced by the `_default` configset. The `sample_techproducts_configset` also remains, and is designed for use with the example documents shipped with Solr in the `example/exampledocs` directory.
@@ -121,7 +121,7 @@ This may affect users who bring up replicas and they are automatically registere
* The `handleSelect` parameter in `solrconfig.xml` now defaults to `false` if the `luceneMatchVersion` is 7.0.0 or above. This causes Solr to ignore the `qt` parameter if it is present in a request. If you have request handlers without a leading '/', you can set `handleSelect="true"` or consider migrating your configuration.
+
The `qt` parameter is still used as a SolrJ special parameter that specifies the request handler (tail URL path) to use.
-* The lucenePlusSort query parser (aka the "Old Lucene Query Parser") has been deprecated and is no longer implicitly defined. If you wish to continue using this parser until Solr 8 (when it will be removed), you must register it in your `solrconfig.xml`, as in: `<queryParser name="lucenePlusSort" class="solr.OldLuceneQParserPlugin"/>`.
+* The `lucenePlusSort` query parser (aka the "Old Lucene Query Parser") has been deprecated and is no longer implicitly defined. If you wish to continue using this parser until Solr 8 (when it will be removed), you must register it in your `solrconfig.xml`, as in: `<queryParser name="lucenePlusSort" class="solr.OldLuceneQParserPlugin"/>`.
* The name of `TemplateUpdateRequestProcessorFactory` is changed to `template` from `Template` and the name of `AtomicUpdateProcessorFactory` is changed to `atomic` from `Atomic`
** Also, `TemplateUpdateRequestProcessorFactory` now uses `{}` instead of `${}` for `template`.
diff --git a/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc b/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc
index 9b0a323..d524f63 100644
--- a/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc
+++ b/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc
@@ -403,7 +403,7 @@ See the https://wiki.apache.org/solr/ReleaseNote73[7.3 Release Notes] for an ove
When upgrading to Solr 7.3, users should be aware of the following major changes from v7.2:
-*ConfigSets*
+*Configsets*
* Collections created without specifying a configset name have used a copy of the `_default` configset since Solr 7.0. Before 7.3, the copied configset was named the same as the collection name, but from 7.3 onwards it will be named with a new ".AUTOCREATED" suffix. This is to prevent overwriting custom configset names.
diff --git a/solr/solr-ref-guide/src/package-manager-internals.adoc b/solr/solr-ref-guide/src/package-manager-internals.adoc
index 3a8589f..90ed865 100644
--- a/solr/solr-ref-guide/src/package-manager-internals.adoc
+++ b/solr/solr-ref-guide/src/package-manager-internals.adoc
@@ -28,7 +28,7 @@ $ bin/solr -c -Denable.packages=true
----
=== Upload Your Keys
-Package binaries must be signed with your private keys and ensure your public keys are published in Zookeeper
+Package binaries must be signed with your private keys and ensure your public keys are published in ZooKeeper.
*Example*
[source,bash]
@@ -36,7 +36,7 @@ Package binaries must be signed with your private keys and ensure your public ke
$ openssl genrsa -out my_key.pem 512
# create the public key in .der format
$ openssl rsa -in my_key.pem -pubout -outform DER -out my_key.der
-# upload to Zookeeper
+# upload to ZooKeeper
$ server/scripts/cloud-scripts/zkcli.sh -zkhost 127.0.0.1:9983 -cmd makepath /keys/exe/
$ server/scripts/cloud-scripts/zkcli.sh -zkhost 127.0.0.1:9983 -cmd putfile /keys/exe/my_key.der my_key.der
----
@@ -118,7 +118,7 @@ For every package / version in the packages definition, there is a unique `SolrR
=== packages.json
-The package configurations live in a file called /packages.json in Zookeeper. At any given moment we can have multiple versions of a given package in the package configuration. The system will always use the latest version . Versions are sorted by their numeric value and the biggest is the latest.
+The package configurations live in a file called /packages.json in ZooKeeper. At any given moment we can have multiple versions of a given package in the package configuration. The system will always use the latest version . Versions are sorted by their numeric value and the biggest is the latest.
*example:*
diff --git a/solr/solr-ref-guide/src/package-manager.adoc b/solr/solr-ref-guide/src/package-manager.adoc
index ae84c9e..e7d7f85 100644
--- a/solr/solr-ref-guide/src/package-manager.adoc
+++ b/solr/solr-ref-guide/src/package-manager.adoc
@@ -48,7 +48,7 @@ Essentially, these are the phases in using the package manager:
=== Starting Solr with Package Management Support
-Start all Solr nodes with the `-Denable.packages=true` parameter. There are security consequences in doing so. At a minimum, no unauthorized user should have write access to Zookeeper instances, since it would then be possible to install packages from untrusted sources (e.g. malicious repositories).
+Start all Solr nodes with the `-Denable.packages=true` parameter. There are security consequences in doing so. At a minimum, no unauthorized user should have write access to ZooKeeper instances, since it would then be possible to install packages from untrusted sources (e.g. malicious repositories).
[source,bash]
----
@@ -149,6 +149,6 @@ $ bin/solr package deploy mypackage:2.0.0 --update -collections mycollection
You can run the `list-deployed` command to verify that this collection is using the newly added version.
== Security
-Except the `add-repo` step, all other steps can be executed using a HTTP endpoint in Solr (see <<package-manager-internals.adoc#package-manager-internals,Package Manager internals>>). This step registers the public key of the trusted repository, and hence can only be executed using the package manager (CLI) having direct write access to Zookeeper. Hence, as you can imagine, it is important to protect Zookeeper from unauthorized write access.
+Except the `add-repo` step, all other steps can be executed using a HTTP endpoint in Solr (see <<package-manager-internals.adoc#package-manager-internals,Package Manager internals>>). This step registers the public key of the trusted repository, and hence can only be executed using the package manager (CLI) having direct write access to ZooKeeper. Hence, as you can imagine, it is important to protect ZooKeeper from unauthorized write access.
Also, keep in mind, that it is possible to install any package from a trusted and an already added repository. Hence, if you want to use some packages in production, then it is better to setup your own repository and add that to Solr, instead of adding a generic third-party repository that is beyond your administrative control.
diff --git a/solr/solr-ref-guide/src/performance-statistics-reference.adoc b/solr/solr-ref-guide/src/performance-statistics-reference.adoc
index a5300fb..ed8bae0 100644
--- a/solr/solr-ref-guide/src/performance-statistics-reference.adoc
+++ b/solr/solr-ref-guide/src/performance-statistics-reference.adoc
@@ -102,11 +102,11 @@ they are very different in nature, thus making it difficult to measure the laten
local requests separately. Solr 8.4 introduced additional statistics that help to do this.
These metrics are structured the same as `requestTimes` and `totalTime` metrics above but they use
-different full names, eg. `QUERY./select.distrib.requestTimes` and `QUERY./select.local.requestTimes`.
+different full names, e.g., `QUERY./select.distrib.requestTimes` and `QUERY./select.local.requestTimes`.
The metrics under the `distrib` path correspond to the time it takes for a (potentially) distributed
request to complete all remote calls plus any local processing, and return the result to the caller.
The metrics under the `local` path correspond to the time it takes for a local call (non-distributed,
-i.e. being processed only by the Solr core where the handler operates) to complete.
+i.e., being processed only by the Solr core where the handler operates) to complete.
== Update Handler
diff --git a/solr/solr-ref-guide/src/resource-loading.adoc b/solr/solr-ref-guide/src/resource-loading.adoc
index 944fb37..dda6026 100644
--- a/solr/solr-ref-guide/src/resource-loading.adoc
+++ b/solr/solr-ref-guide/src/resource-loading.adoc
@@ -27,9 +27,9 @@ After you update a resource, you'll typically need to _reload_ the affected coll
Restarting all affected Solr nodes also works.
<<managed-resources.adoc#managed-resources,Managed resources>> can be manipulated via APIs and do not need an explicit reload.
-== Resources in ConfigSets
+== Resources in Configsets
-<<config-sets.adoc#config-sets,ConfigSets>> are the directories containing solrconfig.xml, the schema, and resources referenced by them.
+<<config-sets.adoc#config-sets,Configsets>> are the directories containing solrconfig.xml, the schema, and resources referenced by them.
In SolrCloud they are in ZooKeeper whereas in standalone they are on the file system.
In either mode, configSets might be shared or might be dedicated to a configSet.
Prefer to put resources here.
@@ -41,4 +41,4 @@ This choice may make sense if the resource is too large for a configSet in ZooKe
However it's up to you to somehow ensure that all nodes in your cluster have access to these resources.
Finally, and this is very unusual, resources can also be packaged inside `.jar` files from which they will be referenced.
-That might make sense for default resources wherein a plugin user can override it via placing the same-named file in a configSet.
\ No newline at end of file
+That might make sense for default resources wherein a plugin user can override it via placing the same-named file in a configSet.
diff --git a/solr/solr-ref-guide/src/securing-solr.adoc b/solr/solr-ref-guide/src/securing-solr.adoc
index d5a77ca..b2d8703 100644
--- a/solr/solr-ref-guide/src/securing-solr.adoc
+++ b/solr/solr-ref-guide/src/securing-solr.adoc
@@ -58,7 +58,7 @@ Authorization makes sure that only users with the necessary roles/permissions ca
Audit logging will record an audit trail of incoming reqests to your cluster, such as users being denied access to admin APIs. Learn more about audit logging and how to implement an audit logger plugin here in the <<audit-logging.adoc#audit-logging,Audit Logging>> chapter.
-== Securing Zookeeper Traffic
+== Securing ZooKeeper Traffic
-Zookeeper is a central and important part of a SolrCloud cluster and understanding how to secure
+ZooKeeper is a central and important part of a SolrCloud cluster and understanding how to secure
its content is covered in the <<zookeeper-access-control.adoc#zookeeper-access-control,ZooKeeper Access Control>> page.
diff --git a/solr/solr-ref-guide/src/solr-cores-and-solr-xml.adoc b/solr/solr-ref-guide/src/solr-cores-and-solr-xml.adoc
index 07d8c53..4e86683 100644
--- a/solr/solr-ref-guide/src/solr-cores-and-solr-xml.adoc
+++ b/solr/solr-ref-guide/src/solr-cores-and-solr-xml.adoc
@@ -33,4 +33,4 @@ The following sections describe these options in more detail.
* *<<format-of-solr-xml.adoc#format-of-solr-xml,Format of solr.xml>>*: Details on how to define `solr.xml`, including the acceptable parameters for the `solr.xml` file
* *<<defining-core-properties.adoc#defining-core-properties,Defining core.properties>>*: Details on placement of `core.properties` and available property options.
* *<<coreadmin-api.adoc#coreadmin-api,CoreAdmin API>>*: Tools and commands for core administration using a REST API.
-* *<<config-sets.adoc#config-sets,Config Sets>>*: How to use configsets to avoid duplicating effort when defining a new core.
+* *<<config-sets.adoc#config-sets,Configsets>>*: How to use configsets to avoid duplicating effort when defining a new core.
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc
index a998b07..b1c8acd 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-policy-preferences.adoc
@@ -517,7 +517,7 @@ params := [ path, '?' ] key, '=', value { '&', key, '=', value } *
Keys and values additionally use www-urlencoded format to avoid meta-characters and non-ascii characters.
-The `params` part of the line closely follows a regular Solr params representation on purpose - in many cases
+The `params` part of the line closely follows a regular Solr parameter representation on purpose - in many cases
the content of this part of the command is passed directly to the respective collection- or cluster-level API.
==== Scenario Context
@@ -544,7 +544,7 @@ load_snapshot path=/tmp/${foo}
----
==== Scenario Commands
-The following commands are supported (command names are case insensitive, but params aren't):
+The following commands are supported (command names are case insensitive, but parameter names are not):
* `create_cluster numNodes=N[&disableMetricsHistory=false&timeSourcee=simTime:50]` - create a simulated cluster with N nodes
* `load_snapshot (path=/some/path | zkHost=ZK_CONNECT_STRING)` - create a simulated cluster from an autoscaling snapshot or from a live cluster.
@@ -557,7 +557,7 @@ The following commands are supported (command names are case insensitive, but pa
* `loop_start [iterations=N]`, `loop_end` - iterate commands enclosed in `loop_start` / `loop_end` N times, or until a loop abort is requested.
* `set_op_delays op1=delayMs1&op2=delayMs2...` - set operation delays for specific collection commands to simulate slow execution.
* `solr_request /admin/handler?httpMethod=POST&stream.body={'json':'body'}&other=params` - execute one of SolrRequest types supported by `SimCloudManager`.
-* `run [time=60000]` - run the simulator for some time, allowing background tasks to execute (eg. trigger event processing).
+* `run [time=60000]` - run the simulator for some time, allowing background tasks to execute (e.g., trigger event processing).
* `wait_collection collection=test&shards=N&replicas=M[&withInactive=false&requireLeaders=true&wait=90]` - wait until the collection shape matches the criteria or the wait time elapses (in which case an error is thrown).
* `event_listener trigger=triggerName&stage=SUCCEEDED[&beforeAction=foo | &afterAction=bar]` - prepare to listen for a specific trigger event.
* `wait_event trigger=triggerName[&wait=90]` - wait until an event specified in `event_listener` is captured or a wait time elapses (in which cases an error is thrown).
@@ -576,7 +576,7 @@ Example scenario testing the behavior of `.autoAddReplicas` trigger:
# standard comment
// java comment
create_cluster numNodes=2 // inline comment
-// load autoscaling config from a json string. Notice that the value must be URL-encoded
+// load autoscaling config from a JSON string. Notice that the value must be URL-encoded
load_autoscaling json={'cluster-policy'+:+[{'replica'+:+'<3',+'shard'+:+'#EACH',+'collection'+:+'testCollection','node':'#ANY'}]}&defaultWaitFor=10
solr_request /admin/collections?action=CREATE&autoAddReplicas=true&name=testCollection&numShards=2&replicationFactor=2&maxShardsPerNode=2
wait_collection collection=testCollection&shards=2&replicas=2
diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-triggers.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-triggers.adoc
index 860b1f9..bf1b969 100644
--- a/solr/solr-ref-guide/src/solrcloud-autoscaling-triggers.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-triggers.adoc
@@ -566,7 +566,7 @@ are not used with low `every` values and an external scheduling process such as
====
== Default Triggers
-A fresh installation of SolrCloud always creates some default triggers. If these triggers are missing (eg. they were
+A fresh installation of SolrCloud always creates some default triggers. If these triggers are missing (e.g., they were
deleted) they are re-created on any autoscaling configuration change or Overseer restart. These triggers can be
suspended if their functionality somehow interferes with other configuration but they can't be permanently deleted.
@@ -598,7 +598,7 @@ Overseer leader such event may not be properly processed by the triggers (which
For this reason a special marker is created in ZooKeeper so that when the next Overseer leader is elected the
triggers will be able to learn about and process these past events.
-Triggers don't delete these markers once they are done processing (because several triggers may need them and eg.
+Triggers don't delete these markers once they are done processing (because several triggers may need them and e.g.,
scheduled triggers may run at arbitrary times with arbitrary delays) so Solr needs a mechanism to clean up
old markers for such events so that they don't accumulate over time. This trigger action performs the clean-up
- it deletes markers older than the configured time-to-live (by default it's 48 hours).
diff --git a/solr/solr-ref-guide/src/solrcloud-configuration-and-parameters.adoc b/solr/solr-ref-guide/src/solrcloud-configuration-and-parameters.adoc
index 6f739f0..572b974 100644
--- a/solr/solr-ref-guide/src/solrcloud-configuration-and-parameters.adoc
+++ b/solr/solr-ref-guide/src/solrcloud-configuration-and-parameters.adoc
@@ -29,4 +29,4 @@ The following sections cover these topics:
* <<parameter-reference.adoc#parameter-reference,Parameter Reference>>
* <<command-line-utilities.adoc#command-line-utilities,Command Line Utilities>>
* <<solrcloud-with-legacy-configuration-files.adoc#solrcloud-with-legacy-configuration-files,SolrCloud with Legacy Configuration Files>>
-* <<configsets-api.adoc#configsets-api,ConfigSets API>>
+* <<configsets-api.adoc#configsets-api,Configsets API>>
diff --git a/solr/solr-ref-guide/src/solrcloud.adoc b/solr/solr-ref-guide/src/solrcloud.adoc
index 7e61122..909a878 100644
--- a/solr/solr-ref-guide/src/solrcloud.adoc
+++ b/solr/solr-ref-guide/src/solrcloud.adoc
@@ -42,7 +42,7 @@ In this section, we'll cover everything you need to know about using Solr in Sol
** <<parameter-reference.adoc#parameter-reference,Parameter Reference>>
** <<command-line-utilities.adoc#command-line-utilities,Command Line Utilities>>
** <<solrcloud-with-legacy-configuration-files.adoc#solrcloud-with-legacy-configuration-files,SolrCloud with Legacy Configuration Files>>
-** <<configsets-api.adoc#configsets-api,ConfigSets API>>
+** <<configsets-api.adoc#configsets-api,Configsets API>>
* <<rule-based-replica-placement.adoc#rule-based-replica-placement,Rule-based Replica Placement>>
* <<cross-data-center-replication-cdcr.adoc#cross-data-center-replication-cdcr,Cross Data Center Replication (CDCR)>>
* <<solrcloud-autoscaling.adoc#solrcloud-autoscaling,SolrCloud Autoscaling>>
diff --git a/solr/solr-ref-guide/src/the-dismax-query-parser.adoc b/solr/solr-ref-guide/src/the-dismax-query-parser.adoc
index a2ca3d7..111df51 100644
--- a/solr/solr-ref-guide/src/the-dismax-query-parser.adoc
+++ b/solr/solr-ref-guide/src/the-dismax-query-parser.adoc
@@ -84,7 +84,7 @@ When specifying `mm` values, keep in mind the following:
* No matter what number the calculation arrives at, Solr will never use a value greater than the number of optional clauses, or a value less than 1. In other words, no matter how low or how high the calculated result, the minimum number of required matches will never be less than 1 or greater than the number of clauses.
* When searching across multiple fields that are configured with different query analyzers, the number of optional clauses may differ between the fields. In such a case, the value specified by mm applies to the maximum number of optional clauses. For example, if a query clause is treated as stopword for one of the fields, the number of optional clauses for that field will be smaller than for the other fields. A query with such a stopword clause would not return a match in that field if m [...]
-The default value of `mm` is 0% (all clauses optional), unless `q.op` is specified as "AND", in which case `mm` defaults to 100% (all clauses required).
+The default value of `mm` is 0% (all clauses optional), unless `q.op` is specified as "AND", in which case `mm` defaults to 100% (all clauses required).
=== pf (Phrase Fields) Parameter
@@ -132,25 +132,25 @@ bq=category:food^10
bq=category:deli^5
----
-Using the `bq` parameter in this way is functionally equivilent to combining your `q` and `bq` params into a single larger boolean query, where the (original) `q` param is "mandatory" and the other clauses are optional:
+Using the `bq` parameter in this way is functionally equivilent to combining your `q` and `bq` parameters into a single larger boolean query, where the (original) `q` parameter is "mandatory" and the other clauses are optional:
[source,text]
----
q=(+cheese category:food^10 category:deli^5)
----
-The only difference between the above examples, is that using the `bq` param allows you to specify these extra clauses independently (ie: as configuration defaults) from the main query.
+The only difference between the above examples, is that using the `bq` parameter allows you to specify these extra clauses independently (i.e., as configuration defaults) from the main query.
[TIP]
[[bq-bf-shortcomings]]
.Additive Boosts vs Multiplicative Boosts
====
-Generally speaking, using `bq` (or `bf`, below) is considered a poor way to "boost" documents by a secondary query because it has an "Additive" effect on the final score. The overall impact a particular `bq` param will have on a given document can vary a lot depending on the _absolute_ values of the scores from the original query as well as the `bq` query, which in turn depends on the complexity of the original query, and various scoring factors (TF, IDF, average field length, etc.)
+Generally speaking, using `bq` (or `bf`, below) is considered a poor way to "boost" documents by a secondary query because it has an "Additive" effect on the final score. The overall impact a particular `bq` parameter will have on a given document can vary a lot depending on the _absolute_ values of the scores from the original query as well as the `bq` query, which in turn depends on the complexity of the original query, and various scoring factors (TF, IDF, average field length, etc.)
"Multiplicative Boosting" is generally considered to be a more predictable method of influcing document score, because it acts as a "scaling factor" -- increasing (or decreasing) the scores of each document by a _relative_ amount.
-The <<other-parsers.adoc#boost-query-parser,`{!boost}` QParser>> provides a convinient wrapper for implementing multiplicitive boosting, and the <<the-extended-dismax-query-parser.adoc#extended-dismax-parameters,`{!edismax}` QParser>> offers a `boost` query param short cut for using it.
+The <<other-parsers.adoc#boost-query-parser,`{!boost}` QParser>> provides a convinient wrapper for implementing multiplicitive boosting, and the <<the-extended-dismax-query-parser.adoc#extended-dismax-parameters,`{!edismax}` QParser>> offers a `boost` query parameter shortcut for using it.
====
@@ -166,7 +166,7 @@ bf=div(1,sum(1,price))^1.5
Specifying functions with the bf parameter is essentially just shorthand for using the `bq` parameter (<<#bq-bf-shortcomings,with the same shortcomings>>) combined with the `{!func}` parser -- with the addition of the simplified "query boost" syntax.
-For example, the two `bf` params listed below, are completely equivilent to the two `bq` params below:
+For example, the two `bf` parameters listed below, are completely equivalent to the two `bq` parameters below:
[source,text]
----
diff --git a/solr/solr-ref-guide/src/updating-parts-of-documents.adoc b/solr/solr-ref-guide/src/updating-parts-of-documents.adoc
index f40cecf..847e911 100644
--- a/solr/solr-ref-guide/src/updating-parts-of-documents.adoc
+++ b/solr/solr-ref-guide/src/updating-parts-of-documents.adoc
@@ -109,7 +109,7 @@ Solr supports modifying, adding and removing child documents as part of atomic u
Schema and configuration requirements are detailed in
<<updating-parts-of-documents#field-storage, Field Storage>> and <<indexing-nested-documents#schema-configuration, Indexing Nested Documents>>. +
Under the hood, Solr retrieves the whole nested structure, deletes the old documents,
-and re-indexes the structure after applying the atomic update. +
+and reindexes the structure after applying the atomic update. +
Syntactically, nested/partial updates are very similar to a regular atomic update,
as demonstrated by the examples below.
diff --git a/solr/solr-ref-guide/src/using-zookeeper-to-manage-configuration-files.adoc b/solr/solr-ref-guide/src/using-zookeeper-to-manage-configuration-files.adoc
index fe13460..ee60018 100644
--- a/solr/solr-ref-guide/src/using-zookeeper-to-manage-configuration-files.adoc
+++ b/solr/solr-ref-guide/src/using-zookeeper-to-manage-configuration-files.adoc
@@ -53,7 +53,7 @@ IMPORTANT: It's a good idea to keep these files under version control.
== Uploading Configuration Files using bin/solr or SolrJ
-In production situations, <<config-sets.adoc#config-sets,Config Sets>> can also be uploaded to ZooKeeper independent of collection creation using either Solr's <<solr-control-script-reference.adoc#solr-control-script-reference,Solr Control Script>> or SolrJ.
+In production situations, <<config-sets.adoc#config-sets,Configsets>> can also be uploaded to ZooKeeper independent of collection creation using either Solr's <<solr-control-script-reference.adoc#solr-control-script-reference,Solr Control Script>> or SolrJ.
The below command can be used to upload a new configset using the bin/solr script.