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/07 19:48:36 UTC
lucene-solr:jira/solr-10290: SOLR-10296: conversion, letters M + N
Repository: lucene-solr
Updated Branches:
refs/heads/jira/solr-10290 7d7fb52ab -> 0ffdf3d54
SOLR-10296: conversion, letters M + N
Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/0ffdf3d5
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/0ffdf3d5
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/0ffdf3d5
Branch: refs/heads/jira/solr-10290
Commit: 0ffdf3d543dc009caaf10b616cc9ee8c84ef2dac
Parents: 7d7fb52
Author: Cassandra Targett <ct...@apache.org>
Authored: Sun May 7 14:48:04 2017 -0500
Committer: Cassandra Targett <ct...@apache.org>
Committed: Sun May 7 14:48:04 2017 -0500
----------------------------------------------------------------------
.../major-changes-from-solr-5-to-solr-6.adoc | 16 ----
.../src/making-and-restoring-backups.adoc | 69 ++++++----------
solr/solr-ref-guide/src/managed-resources.adoc | 67 +++++++++-------
.../src/mbean-request-handler.adoc | 14 ++--
solr/solr-ref-guide/src/merging-indexes.adoc | 14 ++--
solr/solr-ref-guide/src/metrics-reporting.adoc | 82 +++++++++-----------
solr/solr-ref-guide/src/morelikethis.adoc | 23 +++---
.../src/near-real-time-searching.adoc | 25 +++---
8 files changed, 135 insertions(+), 175 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/0ffdf3d5/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc b/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
index cf80231..3ae6f6c 100644
--- a/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
+++ b/solr/solr-ref-guide/src/major-changes-from-solr-5-to-solr-6.adoc
@@ -4,12 +4,10 @@
There are some major changes in Solr 6 to consider before starting to migrate your configurations and indexes. There are many hundreds of changes, so a thorough review of the <<upgrading-solr.adoc#upgrading-solr,Upgrading Solr>> section as well as the {solr-javadocs}/changes/Changes.html[CHANGES.txt] file in your Solr instance will help you plan your migration to Solr 6. This section attempts to highlight some of the major changes you should be aware of.
-[[MajorChangesfromSolr5toSolr6-HighlightsofNewFeaturesinSolr6]]
== Highlights of New Features in Solr 6
Some of the major improvements in Solr 6 include:
-[[MajorChangesfromSolr5toSolr6-StreamingExpressions]]
=== Streaming Expressions
Introduced in Solr 5, <<streaming-expressions.adoc#streaming-expressions,Streaming Expressions>> allow querying Solr and getting results as a stream of data, sorted and aggregated as requested.
@@ -22,37 +20,30 @@ Several new expression types have been added in Solr 6:
* Publish/Subscribe messaging.
* JDBC connections to pull data from other systems and join with documents in the Solr index.
-[[MajorChangesfromSolr5toSolr6-ParallelSQLInterface]]
=== Parallel SQL Interface
Built on streaming expressions, new in Solr 6 is a <<parallel-sql-interface.adoc#parallel-sql-interface,Parallel SQL interface>> to be able to send SQL queries to Solr. SQL statements are compiled to streaming expressions on the fly, providing the full range of aggregations available to streaming expression requests. A JDBC driver is included, which allows using SQL clients and database visualization tools to query your Solr index and import data to other systems.
-[[MajorChangesfromSolr5toSolr6-CrossDataCenterReplication]]
=== Cross Data Center Replication
Replication across data centers is now possible with <<cross-data-center-replication-cdcr-.adoc#cross-data-center-replication-cdcr-,Cross Data Center Replication>>. Using an active-passive model, a SolrCloud cluster can be replicated to another data center, and monitored with a new API.
-[[MajorChangesfromSolr5toSolr6-GraphQueryParser]]
=== Graph Query Parser
A new <<other-parsers.adoc#OtherParsers-GraphQueryParser,`graph` query parser>> makes it possible to to graph traversal queries of Directed (Cyclic) Graphs modelled using Solr documents.
-[[MajorChangesfromSolr5toSolr6-DocValues]]
=== DocValues
Most non-text field types in the Solr sample configsets now default to using <<docvalues.adoc#docvalues,DocValues>>.
-[[MajorChangesfromSolr5toSolr6-Java8Required]]
== Java 8 Required
The minimum supported version of Java for Solr 6 (and the <<using-solrj.adoc#using-solrj,SolrJ client libraries>>) is now Java 8.
-[[MajorChangesfromSolr5toSolr6-IndexFormatChanges]]
== Index Format Changes
Solr 6 has no support for reading Lucene/Solr 4.x and earlier indexes. Be sure to run the Lucene `IndexUpgrader` included with Solr 5.5 if you might still have old 4x formatted segments in your index. Alternatively: fully optimize your index with Solr 5.5 to make sure it consists only of one up-to-date index segment.
-[[MajorChangesfromSolr5toSolr6-ManagedSchemaisnowtheDefault]]
== Managed Schema is now the Default
Solr's default behavior when a `solrconfig.xml` does not explicitly define a `<schemaFactory/>` is now dependent on the `luceneMatchVersion` specified in that `solrconfig.xml`. When `luceneMatchVersion < 6.0`, `ClassicIndexSchemaFactory` will continue to be used for back compatibility, otherwise an instance of <<schema-factory-definition-in-solrconfig.adoc#schema-factory-definition-in-solrconfig,`ManagedIndexSchemaFactory`>> will be used.
@@ -64,23 +55,16 @@ The most notable impacts of this change are:
Please review the <<schema-factory-definition-in-solrconfig.adoc#schema-factory-definition-in-solrconfig,Schema Factory Definition in SolrConfig>> section for more details.
-[[MajorChangesfromSolr5toSolr6-DefaultSimilarityChanges]]
== Default Similarity Changes
Solr's default behavior when a Schema does not explicitly define a global <<other-schema-elements.adoc#other-schema-elements,`<similarity/>`>> is now dependent on the `luceneMatchVersion` specified in the `solrconfig.xml`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarityFactory` will be used, otherwise an instance of `SchemaSimlarityFactory` will be used. Most notably this change means that users can take advantage of per Field Type similarity declarations, with out needing to also explicitly declare a global usage of `SchemaSimlarityFactory`.
Regardless of whether it is explicitly declared, or used as an implicit global default, `SchemaSimlarityFactory`'s implicit behavior when a Field Types do not declare an explicit `<similarity />` has also been changed to depend on the the `luceneMatchVersion`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarity` will be used, otherwise an instance of `BM25Simlarity` will be used. A `defaultSimFromFieldType` init option may be specified on the `SchemaSimilarityFactory` declaration to change this behavior. Please review the `SchemaSimlarityFactory` javadocs for more details
-// OLD_CONFLUENCE_ID: MajorChangesfromSolr5toSolr6-Replica&ShardDeleteCommandChanges
-
-[[MajorChangesfromSolr5toSolr6-Replica_ShardDeleteCommandChanges]]
== Replica & Shard Delete Command Changes
DELETESHARD and DELETEREPLICA now default to deleting the instance directory, data directory, and index directory for any replica they delete. Please review the <<collections-api.adoc#collections-api,Collection API>> documentation for details on new request parameters to prevent this behavior if you wish to keep all data on disk when using these commands
-// OLD_CONFLUENCE_ID: MajorChangesfromSolr5toSolr6-facet.date.*ParametersRemoved
-
-[[MajorChangesfromSolr5toSolr6-facet.date._ParametersRemoved]]
== `facet.date.*` Parameters Removed
The `facet.date` parameter (and associated `facet.date.*` parameters) that were deprecated in Solr 3.x have been removed completely. If you have not yet switched to using the equivalent <<faceting.adoc#faceting,`facet.range`>> functionality you must do so now before upgrading.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/0ffdf3d5/solr/solr-ref-guide/src/making-and-restoring-backups.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/making-and-restoring-backups.adoc b/solr/solr-ref-guide/src/making-and-restoring-backups.adoc
index 0e63c54..9fea23d 100644
--- a/solr/solr-ref-guide/src/making-and-restoring-backups.adoc
+++ b/solr/solr-ref-guide/src/making-and-restoring-backups.adoc
@@ -4,9 +4,8 @@
If you are worried about data loss, and of course you _should_ be, you need a way to back up your Solr indexes so that you can recover quickly in case of catastrophic failure.
-Solr provides two approaches to backing up and restoring Solr cores or collections, depending on how you are running Solr. If you run SolrCloud, you will use the Collections API; if you run Solr in standalone mode, you will use the replication handler.
+Solr provides two approaches to backing up and restoring Solr cores or collections, depending on how you are running Solr. If you run in SolrCloud mode, you will use the Collections API. If you run Solr in standalone mode, you will use the replication handler.
-[[MakingandRestoringBackups-SolrCloud]]
== SolrCloud
Support for backups when running SolrCloud is provided with the <<collections-api.adoc#collections-api,Collections API>>. This allows the backups to be generated across multiple shards, and restored to the same number of shards and replicas as the original collection.
@@ -16,21 +15,18 @@ Two commands are available:
* `action=BACKUP`: This command backs up Solr indexes and configurations. More information is available in the section <<collections-api.adoc#CollectionsAPI-backup,Backup Collection>>.
* `action=RESTORE`: This command restores Solr indexes and configurations. More information is available in the section <<collections-api.adoc#CollectionsAPI-restore,Restore Collection>>.
-[[MakingandRestoringBackups-StandaloneMode]]
== Standalone Mode
Backups and restoration uses Solr's replication handler. Out of the box, Solr includes implicit support for replication so this API can be used. Configuration of the replication handler can, however, be customized by defining your own replication handler in `solrconfig.xml` . For details on configuring the replication handler, see the section <<index-replication.adoc#IndexReplication-ConfiguringtheReplicationHandler,Configuring the ReplicationHandler>>.
-[[MakingandRestoringBackups-BackupAPI]]
=== Backup API
The backup API requires sending a command to the `/replication` handler to back up the system.
You can trigger a back-up with an HTTP command like this (replace "gettingstarted" with the name of the core you are working with):
-*Backup API*
-
-[source,bash]
+.Backup API Example
+[source,text]
----
http://localhost:8983/solr/gettingstarted/replication?command=backup
----
@@ -41,7 +37,7 @@ Only one backup call can be made against a core at any point in time. While an o
The backup request can also take the following additional parameters:
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Description
|location |The path where the backup will be created. If the path is not absolute then the backup path will be relative to Solr's instance directory.
@@ -51,20 +47,17 @@ The backup request can also take the following additional parameters:
|commitName |The name of the commit which was used while taking a snapshot using the CREATESNAPSHOT command.
|===
-[[MakingandRestoringBackups-BackupStatus]]
=== Backup Status
The backup operation can be monitored to see if it has completed by sending the `details` command to the `/replication` handler, as in this example:
-*Status API*
-
-[source,bash]
+.Status API Example
+[source,text]
----
http://localhost:8983/solr/gettingstarted/replication?command=details
----
-*Output Snippet*
-
+.Output Snippet
[source,xml]
----
<lst name="backup">
@@ -78,16 +71,14 @@ http://localhost:8983/solr/gettingstarted/replication?command=details
If it failed then a `snapShootException` will be sent in the response.
-[[MakingandRestoringBackups-RestoreAPI]]
=== Restore API
Restoring the backup requires sending the `restore` command to the `/replication` handler, followed by the name of the backup to restore.
You can restore from a backup with a command like this:
-*Example Usage*
-
-[source,bash]
+.Example Usage
+[source,text]
----
http://localhost:8983/solr/gettingstarted/replication?command=restore&name=backup_name
----
@@ -98,7 +89,7 @@ The restore request can also take these additional parameters:
[cols=",",options="header",]
|===
-|Name |Description
+|Parameter |Description
|location |The location of the backup snapshot file. If not specified, it looks for backups in Solr's data directory.
|name |The name of the backed up index snapshot to be restored. If the name is not provided it looks for backups with `snapshot.<timestamp>` format in the location directory. It picks the latest timestamp backup in that case.
|repository |The name of the repository to be used for the backup. If no repository is specified then the local filesystem repository will be used automatically.
@@ -108,20 +99,17 @@ The restore command is an asynchronous call. Once the restore is complete the da
Only one restore call can can be made against a core at one point in time. While an ongoing restore operation is happening subsequent calls for restoring will throw an exception.
-[[MakingandRestoringBackups-RestoreStatusAPI]]
=== Restore Status API
You can also check the status of a restore operation by sending the `restorestatus` command to the `/replication` handler, as in this example:
-*Status API*
-
-[source,bash]
+.Status API Example
+[source,text]
----
http://localhost:8983/solr/gettingstarted/replication?command=restorestatus
----
-*Output*
-
+.Status API Output
[source,xml]
----
<response>
@@ -138,23 +126,21 @@ http://localhost:8983/solr/gettingstarted/replication?command=restorestatus
The status value can be "In Progress" , "success" or "failed". If it failed then an "exception" will also be sent in the response.
-[[MakingandRestoringBackups-CreateSnapshotAPI]]
=== Create Snapshot API
The snapshot functionality is different from the backup functionality as the index files aren't copied anywhere. The index files are snapshotted in the same index directory and can be referenced while taking backups.
You can trigger a snapshot command with an HTTP command like this (replace "techproducts" with the name of the core you are working with):
-*Create Snapshot API*
-
-[source,bash]
+.Create Snapshot API Example
+[source,text]
----
http://localhost:8983/solr/admin/cores?action=CREATESNAPSHOT&core=techproducts&commitName=commit1
----
The list snapshot request parameters are:
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Description
|commitName |Specify the commit name to store the snapshot as
@@ -162,46 +148,42 @@ The list snapshot request parameters are:
|async |Request ID to track this action which will be processed asynchronously
|===
-[[MakingandRestoringBackups-ListSnapshotAPI]]
=== List Snapshot API
The list snapshot functionality lists all the taken snapshots for a particular core.
You can trigger a list snapshot command with an HTTP command like this (replace "techproducts" with the name of the core you are working with):
-*List Snapshot API*
-
-[source,bash]
+.List Snapshot API
+[source,text]
----
http://localhost:8983/solr/admin/cores?action=LISTSNAPSHOTS&core=techproducts&commitName=commit1
----
The list snapshot request parameters are:
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Description
|core |name of the core to whose snapshots we want to list
|async |Request ID to track this action which will be processed asynchronously
|===
-[[MakingandRestoringBackups-DeleteSnapshotAPI]]
=== Delete Snapshot API
The delete snapshot functionality deletes a particular snapshot for a particular core.
You can trigger a delete snapshot command with an HTTP command like this (replace "techproducts" with the name of the core you are working with):
-*Delete Snapshot API*
-
-[source,bash]
+.Delete Snapshot API Example
+[source,text]
----
http://localhost:8983/solr/admin/cores?action=DELETESNAPSHOT&core=techproducts&commitName=commit1
----
The delete snapshot request parameters are:
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Description
|commitName |Specify the commit name to be deleted
@@ -209,9 +191,6 @@ The delete snapshot request parameters are:
|async |Request ID to track this action which will be processed asynchronously
|===
-// OLD_CONFLUENCE_ID: MakingandRestoringBackups-Backup/RestoreStorageRepositories
-
-[[MakingandRestoringBackups-Backup_RestoreStorageRepositories]]
== Backup/Restore Storage Repositories
Solr provides interfaces to plug different storage systems for backing up and restoring. For example, you can have a Solr cluster running on a local filesystem like EXT3 but you can backup the indexes to a HDFS filesystem or vice versa.
@@ -220,9 +199,7 @@ The repository interfaces needs to be configured in the solr.xml file . While ru
If no repository is configured then the local filesystem repository will be used automatically.
-Example solr.xml section to configure a repository like https://cwiki.apache.org/confluence/display/solr/Running+Solr+on+HDFS[HDFS] .
-
-*Output*
+Example solr.xml section to configure a repository like https://cwiki.apache.org/confluence/display/solr/Running+Solr+on+HDFS[HDFS]:
[source,xml]
----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/0ffdf3d5/solr/solr-ref-guide/src/managed-resources.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/managed-resources.adoc b/solr/solr-ref-guide/src/managed-resources.adoc
index 709f1cd..732c873 100644
--- a/solr/solr-ref-guide/src/managed-resources.adoc
+++ b/solr/solr-ref-guide/src/managed-resources.adoc
@@ -2,7 +2,13 @@
:page-shortname: managed-resources
:page-permalink: managed-resources.html
-Managed resources expose a REST API endpoint for performing Create-Read-Update-Delete (CRUD) operations on a Solr object. Any long-lived Solr object that has configuration settings and/or data is a good candidate to be a managed resource. Managed resources complement other programmatically manageable components in Solr, such as the RESTful schema API to add fields to a managed schema. Consider a Web-based UI that offers Solr-as-a-Service where users need to configure a set of stop words and synonym mappings as part of an initial setup process for their search application. This type of use case can easily be supported using the Managed Stop Filter & Managed Synonym Filter Factories provided by Solr, via the Managed resources REST API. Users can also write their own custom plugins, that leverage the same internal hooks to make additional resources REST managed.
+Managed resources expose a REST API endpoint for performing Create-Read-Update-Delete (CRUD) operations on a Solr object.
+
+Any long-lived Solr object that has configuration settings and/or data is a good candidate to be a managed resource. Managed resources complement other programmatically manageable components in Solr, such as the RESTful schema API to add fields to a managed schema.
+
+Consider a Web-based UI that offers Solr-as-a-Service where users need to configure a set of stop words and synonym mappings as part of an initial setup process for their search application. This type of use case can easily be supported using the Managed Stop Filter & Managed Synonym Filter Factories provided by Solr, via the Managed resources REST API.
+
+Users can also write their own custom plugins, that leverage the same internal hooks to make additional resources REST managed.
All of the examples in this section assume you are running the "techproducts" Solr example:
@@ -17,7 +23,7 @@ bin/solr -e techproducts
Let's begin learning about managed resources by looking at a couple of examples provided by Solr for managing stop words and synonyms using a REST API. After reading this section, you'll be ready to dig into the details of how managed resources are implemented in Solr so you can start building your own implementation.
[[ManagedResources-Stopwords]]
-=== Stop words
+=== Stop Words
To begin, you need to define a field type that uses the <<filter-descriptions.adoc#FilterDescriptions-ManagedStopFilter,ManagedStopFilterFactory>>, such as:
@@ -26,21 +32,27 @@ To begin, you need to define a field type that uses the <<filter-descriptions.ad
<fieldType name="managed_en" positionIncrementGap="100">
<analyzer>
<tokenizer class="solr.StandardTokenizerFactory"/>
- <filter class="solr.ManagedStopFilterFactory"
- managed="english" />
+ <filter class="solr.ManagedStopFilterFactory" <1>
+ managed="english" /> <2>
</analyzer>
</fieldType>
----
-There are two important things to notice about this field type definition. First, the filter implementation class is *`solr.ManagedStopFilterFactory`* . This is a special implementation of the <<filter-descriptions.adoc#FilterDescriptions-StopFilter,StopFilterFactory>> that uses a set of stop words that are managed from a REST API. Second, the *`managed=”english”`* attribute gives a name to the set of managed stop words, in this case indicating the stop words are for English text.
+There are two important things to notice about this field type definition:
+
+<1> The filter implementation class is `solr.ManagedStopFilterFactory`. This is a special implementation of the <<filter-descriptions.adoc#FilterDescriptions-StopFilter,StopFilterFactory>> that uses a set of stop words that are managed from a REST API.
+
+<2> The `managed=”english”` attribute gives a name to the set of managed stop words, in this case indicating the stop words are for English text.
The REST endpoint for managing the English stop words in the techproducts collection is: `/solr/techproducts/schema/analysis/stopwords/english`.
-The example resource path should be mostly self-explanatory. It should be noted that the ManagedStopFilterFactory implementation determines the */schema/analysis/stopwords* part of the path, which makes sense because this is an analysis component defined by the schema. It follows that a field type that uses the following filter:
+The example resource path should be mostly self-explanatory. It should be noted that the ManagedStopFilterFactory implementation determines the `/schema/analysis/stopwords` part of the path, which makes sense because this is an analysis component defined by the schema.
+
+It follows that a field type that uses the following filter:
[source,xml]
----
-<filter class="solr.ManagedStopFilterFactory"
+<filter class="solr.ManagedStopFilterFactory"
managed="french" />
----
@@ -70,14 +82,14 @@ Assuming you sent this request to Solr, the response body is a JSON document:
"an",
"and",
"are",
- ... ]
+ ]
}
}
----
-The `sample_techproducts_configs` <<config-sets.adoc#config-sets,config set>> ships with a pre-built set of managed stop words, however you should only interact with this file using the API and not edit it directly.
+The `sample_techproducts_configs` <<config-sets.adoc#config-sets,configset>> ships with a pre-built set of managed stop words, however you should only interact with this file using the API and not edit it directly.
-One thing that should stand out to you in this response is that it contains a *`managedList`* of words as well as `**initArgs**` . This is an important concept in this framework—managed resources typically have configuration and data. For stop words, the only configuration parameter is a boolean that determines whether to ignore the case of tokens during stop word filtering (ignoreCase=true|false). The data is a list of words, which is represented as a JSON array named *`managedList`* in the response.
+One thing that should stand out to you in this response is that it contains a `managedList` of words as well as `initArgs`. This is an important concept in this framework -- managed resources typically have configuration and data. For stop words, the only configuration parameter is a boolean that determines whether to ignore the case of tokens during stop word filtering (ignoreCase=true|false). The data is a list of words, which is represented as a JSON array named `managedList` in the response.
Now, let’s add a new word to the English stop word list using an HTTP PUT:
@@ -104,22 +116,22 @@ To delete a stop word, you would do:
curl -X DELETE "http://localhost:8983/solr/techproducts/schema/analysis/stopwords/english/foo"
----
-Note: PUT/POST is used to add terms to an existing list instead of replacing the list entirely. This is because it is more common to add a term to an existing list than it is to replace a list altogether, so the API favors the more common approach of incrementally adding terms especially since deleting individual terms is also supported.
+NOTE: PUT/POST is used to add terms to an existing list instead of replacing the list entirely. This is because it is more common to add a term to an existing list than it is to replace a list altogether, so the API favors the more common approach of incrementally adding terms especially since deleting individual terms is also supported.
[[ManagedResources-Synonyms]]
=== Synonyms
-For the most part, the API for managing synonyms behaves similar to the API for stop words, except instead of working with a list of words, it uses a map, where the value for each entry in the map is a set of synonyms for a term. As with stop words, the `sample_techproducts_configs` <<config-sets.adoc#config-sets,config set>> includes a pre-built set of synonym mappings suitable for the sample data that is activated by the following field type definition in schema.xml:
+For the most part, the API for managing synonyms behaves similar to the API for stop words, except instead of working with a list of words, it uses a map, where the value for each entry in the map is a set of synonyms for a term. As with stop words, the `sample_techproducts_configs` <<config-sets.adoc#config-sets,configset>> includes a pre-built set of synonym mappings suitable for the sample data that is activated by the following field type definition in schema.xml:
[source,xml]
----
<fieldType name="managed_en" positionIncrementGap="100">
<analyzer>
<tokenizer class="solr.StandardTokenizerFactory"/>
- <filter class="solr.ManagedStopFilterFactory"
+ <filter class="solr.ManagedStopFilterFactory"
managed="english" />
- <filter class="solr.ManagedSynonymFilterFactory"
+ <filter class="solr.ManagedSynonymFilterFactory"
managed="english" />
</analyzer>
@@ -157,7 +169,7 @@ This request will return a response that looks like:
"joyful"]}}}
----
-Managed synonyms are returned under the *managedMap* property which contains a JSON Map where the value of each entry is a set of synonyms for a term, such as "happy" has synonyms "glad" and "joyful" in the example above.
+Managed synonyms are returned under the `managedMap` property which contains a JSON Map where the value of each entry is a set of synonyms for a term, such as "happy" has synonyms "glad" and "joyful" in the example above.
To add a new synonym mapping, you can PUT/POST a single mapping such as:
@@ -182,23 +194,27 @@ Lastly, you can delete a mapping by sending a DELETE request to the managed endp
[[ManagedResources-ApplyingChanges]]
== Applying Changes
-Changes made to managed resources via this REST API are not applied to the active Solr components until the Solr collection (or Solr core in single server mode) is reloaded. For example:, after adding or deleting a stop word, you must reload the core/collection before changes become active; related APIs: <<coreadmin-api.adoc#coreadmin-api,CoreAdmin API>> and <<collections-api.adoc#collections-api,Collections API>>.
+Changes made to managed resources via this REST API are not applied to the active Solr components until the Solr collection (or Solr core in single server mode) is reloaded.
+
+For example: after adding or deleting a stop word, you must reload the core/collection before changes become active; related APIs: <<coreadmin-api.adoc#coreadmin-api,CoreAdmin API>> and <<collections-api.adoc#collections-api,Collections API>>.
This approach is required when running in distributed mode so that we are assured changes are applied to all cores in a collection at the same time so that behavior is consistent and predictable. It goes without saying that you don’t want one of your replicas working with a different set of stop words or synonyms than the others.
-One subtle outcome of this _apply-changes-at-reload_ approach is that the once you make changes with the API, there is no way to read the active data. In other words, the API returns the most up-to-date data from an API perspective, which could be different than what is currently being used by Solr components. However, the intent of this API implementation is that changes will be applied using a reload within a short time frame after making them so the time in which the data returned by the API differs from what is active in the server is intended to be negligible.
+One subtle outcome of this _apply-changes-at-reload_ approach is that the once you make changes with the API, there is no way to read the active data. In other words, the API returns the most up-to-date data from an API perspective, which could be different than what is currently being used by Solr components.
+
+However, the intent of this API implementation is that changes will be applied using a reload within a short time frame after making them so the time in which the data returned by the API differs from what is active in the server is intended to be negligible.
[IMPORTANT]
====
-
Changing things like stop words and synonym mappings typically require re-indexing existing documents if being used by index-time analyzers. The RestManager framework does not guard you from this, it simply makes it possible to programmatically build up a set of stop words, synonyms etc.
-
====
[[ManagedResources-RestManagerEndpoint]]
== RestManager Endpoint
-Metadata about registered ManagedResources is available using the */schema/managed* endpoint for each collection. Assuming you have the *managed_en* field type shown above defined in your schema.xml, sending a GET request to the following resource will return metadata about which schema-related resources are being managed by the RestManager:
+Metadata about registered ManagedResources is available using the `/schema/managed` endpoint for each collection.
+
+Assuming you have the `managed_en` field type shown above defined in your schema.xml, sending a GET request to the following resource will return metadata about which schema-related resources are being managed by the RestManager:
[source,bash]
----
@@ -231,9 +247,9 @@ The response body is a JSON document containing metadata about managed resources
You can also create new managed resource using PUT/POST to the appropriate URL – before ever configuring anything that uses these resources.
-For example: imagine we want to build up a set of German stop words. Before we can start adding stop words, we need to create the endpoint:
+For example, imagine we want to build up a set of German stop words. Before we can start adding stop words, we need to create the endpoint:
-`/solr/techproducts/schema/analysis/stopwords/german `
+`/solr/techproducts/schema/analysis/stopwords/german`
To create this endpoint, send the following PUT/POST request to the endpoint we wish to create:
@@ -254,7 +270,7 @@ curl -X PUT -H 'Content-type:application/json' --data-binary '["die"]' \
For most users, creating resources in this way should never be necessary, since managed resources are created automatically when configured.
-However: You may want to explicitly delete managed resources if they are no longer being used by a Solr component.
+However, You may want to explicitly delete managed resources if they are no longer being used by a Solr component.
For instance, the managed resource for German that we created above can be deleted because there are no Solr components that are using it, whereas the managed resource for English stop words cannot be deleted because there is a token filter declared in schema.xml that is using it.
@@ -262,8 +278,3 @@ For instance, the managed resource for German that we created above can be delet
----
curl -X DELETE "http://localhost:8983/solr/techproducts/schema/analysis/stopwords/german"
----
-
-[[ManagedResources-RelatedTopics]]
-== Related Topics
-
-* https://lucidworks.com/blog/2014/03/31/introducing-solrs-restmanager-and-managed-stop-words-and-synonyms/[Using Solr’s REST APIs to manage stop words and synonyms] by Tim Potter @ Lucidworks.com
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/0ffdf3d5/solr/solr-ref-guide/src/mbean-request-handler.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/mbean-request-handler.adoc b/solr/solr-ref-guide/src/mbean-request-handler.adoc
index a8ab4a3..cd5e96e 100644
--- a/solr/solr-ref-guide/src/mbean-request-handler.adoc
+++ b/solr/solr-ref-guide/src/mbean-request-handler.adoc
@@ -6,7 +6,7 @@ The MBean Request Handler offers programmatic access to the information provided
The MBean Request Handler accepts the following parameters:
-[width="100%",cols="25%,25%,25%,25%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Type |Default |Description
|key |multivalued |all |Restricts results by object key.
@@ -16,27 +16,27 @@ The MBean Request Handler accepts the following parameters:
|===
[[MBeanRequestHandler-Examples]]
-=== Examples
+== Examples
The following examples assume you are running Solr's `techproducts` example configuration:
-[source,java]
+[source,bash]
----
bin/solr start -e techproducts
----
To return information about the CACHE category only:
-`http://localhost:8983/solr/techproducts/admin/mbeans?cat=CACHE`
+`\http://localhost:8983/solr/techproducts/admin/mbeans?cat=CACHE`
To return information and statistics about the CACHE category only, formatted in JSON:
-`http://localhost:8983/solr/techproducts/admin/mbeans?stats=true&cat=CACHE&indent=true&wt=json`
+`\http://localhost:8983/solr/techproducts/admin/mbeans?stats=true&cat=CACHE&indent=true&wt=json`
To return information for everything, and statistics for everything except the `fieldCache`:
-`http://localhost:8983/solr/techproducts/admin/mbeans?stats=true&f.fieldCache.stats=false`
+`\http://localhost:8983/solr/techproducts/admin/mbeans?stats=true&f.fieldCache.stats=false`
To return information and statistics for the `fieldCache` only:
-`http://localhost:8983/solr/techproducts/admin/mbeans?key=fieldCache&stats=true`
+`\http://localhost:8983/solr/techproducts/admin/mbeans?key=fieldCache&stats=true`
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/0ffdf3d5/solr/solr-ref-guide/src/merging-indexes.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/merging-indexes.adoc b/solr/solr-ref-guide/src/merging-indexes.adoc
index 651ff64..bf554aa 100644
--- a/solr/solr-ref-guide/src/merging-indexes.adoc
+++ b/solr/solr-ref-guide/src/merging-indexes.adoc
@@ -16,20 +16,16 @@ Optimally, the two indexes should be built using the same schema.
To merge the indexes, do the following:
-1. Make sure that both indexes you want to merge are closed.
-2. Issue this command:
+. Make sure that both indexes you want to merge are closed.
+. Issue this command:
+
-[source,java]
+[source,bash]
----
-java -cp $SOLR/server/solr-webapp/webapp/WEB-INF/lib/lucene-core-VERSION.jar:$SOLR/server/solr-webapp/webapp/WEB-INF/lib/lucene-misc-VERSION.jar
- org/apache/lucene/misc/IndexMergeTool
- /path/to/newindex
- /path/to/old/index1
- /path/to/old/index2
+java -cp $SOLR/server/solr-webapp/webapp/WEB-INF/lib/lucene-core-VERSION.jar:$SOLR/server/solr-webapp/webapp/WEB-INF/lib/lucene-misc-VERSION.jar org/apache/lucene/misc/IndexMergeTool /path/to/newindex /path/to/old/index1 /path/to/old/index2
----
+
This will create a new index at `/path/to/newindex` that contains both index1 and index2.
-3. Copy this new directory to the location of your application's solr index (move the old one aside first, of course) and start Solr.
+. Copy this new directory to the location of your application's solr index (move the old one aside first, of course) and start Solr.
[[MergingIndexes-UsingCoreAdmin]]
== Using CoreAdmin
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/0ffdf3d5/solr/solr-ref-guide/src/metrics-reporting.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/metrics-reporting.adoc b/solr/solr-ref-guide/src/metrics-reporting.adoc
index 38ca2f3..a5c0034 100644
--- a/solr/solr-ref-guide/src/metrics-reporting.adoc
+++ b/solr/solr-ref-guide/src/metrics-reporting.adoc
@@ -2,19 +2,22 @@
:page-shortname: metrics-reporting
:page-permalink: metrics-reporting.html
-Solr includes a developer API and instrumentation for the collection of detailed performance-oriented metrics throughout the life-cycle of Solr service and its various components. Internally it uses the http://metrics.dropwizard.io[Dropwizard Metrics API], which uses the following classes of meters to measure events:
+Solr includes a developer API and instrumentation for the collection of detailed performance-oriented metrics throughout the life-cycle of Solr service and its various components.
+
+Internally this feature uses the http://metrics.dropwizard.io[Dropwizard Metrics API], which uses the following classes of meters to measure events:
* *counters* - simply count events. They provide a single long value, e.g., the number of requests.
* *meters* - additionally compute rates of events. Provide a count (as above) and 1-, 5-, and 15-minute exponentially decaying rates, similar to the Unix system load average.
-* *histograms* - calculate approximate distribution of events according to their values. Provide the following approximate statistics, with a similar exponential decay as above: mean (arithmetic average), median, maximum, minimum, standard deviation, and 75-th, 95-th, 98-th, 99-th and 999-th percentiles.
+* *histograms* - calculate approximate distribution of events according to their values. Provide the following approximate statistics, with a similar exponential decay as above: mean (arithmetic average), median, maximum, minimum, standard deviation, and 75^th^, 95^th^, 98^th^, 99^th^ and 999^th^ percentiles.
* *timers* - measure the number and duration of events. They provide a count and histogram of timings.
* *gauges* - offer instantaneous reading of a current value, e.g., current queue depth, current number of active connections, free heap size.
-Each group of related metrics with unique names is managed in a **metric registry**. Solr maintains several such registries, each corresponding to a high-level group such as: `jvm`, `jetty`, `http`, `node`, and `core` (see <<MetricsReporting-MetricGroups,Metric Registries>> below).
+Each group of related metrics with unique names is managed in a *metric registry*. Solr maintains several such registries, each corresponding to a high-level group such as: `jvm`, `jetty`, `http`, `node`, and `core` (see <<Metric Registries>> below).
+
+For each group (and/or for each registry) there can be several *reporters*, which are components responsible for communication of metrics from selected registries to external systems. Currently implemented reporters support emitting metrics via JMX, Ganglia, Graphite and SLF4J.
-For each group (and/or for each registry) there can be several **reporters**, which are components responsible for communication of metrics from selected registries to external systems. Currently implemented reporters support emitting metrics via JMX, Ganglia, Graphite and SLF4J. There is also a dedicated `/admin/metrics` handler that can be queried to report all or a subset of the current metrics from multiple registries.
+There is also a dedicated `/admin/metrics` handler that can be queried to report all or a subset of the current metrics from multiple registries.
-[[MetricsReporting-MetricRegistries]]
== Metric Registries
Solr includes multiple metric registries, which group related metrics.
@@ -23,9 +26,6 @@ Metrics are maintained and accumulated through all lifecycles of components from
These are the major groups of metrics that are collected:
-// OLD_CONFLUENCE_ID: MetricsReporting-JVMRegistry(solr.jvm):
-
-[[MetricsReporting-JVMRegistry_solr.jvm_]]
=== JVM Registry (`solr.jvm`):
* direct and mapped buffer pools
@@ -35,34 +35,24 @@ These are the major groups of metrics that are collected:
* heap, non-heap memory and GC pools
* number of threads, their states and deadlocks
-// OLD_CONFLUENCE_ID: MetricsReporting-Node/CoreContainerRegistry(solr.node):
-
-[[MetricsReporting-Node_CoreContainerRegistry_solr.node_]]
=== Node / CoreContainer Registry (`solr.node`):
* handler requests (count, timing): collections, info, admin, configSets, etc.
* number of cores (loaded, lazy, unloaded)
-// OLD_CONFLUENCE_ID: MetricsReporting-Core(SolrCore)Registry(solr.core.<collection>...,oneforeachcore):
+=== Core (SolrCore) Registry:
-[[MetricsReporting-Core_SolrCore_Registry_solr.core._collection_..._oneforeachcore_]]
-=== <<MetricsReporting-CoreLevelMetrics,Core (SolrCore) Registry>> (`solr.core.<collection>...`, one for each core):
+The <<Core Level Metrics,Core (SolrCore) Registry>> includes `solr.core.<collection>`, one for each core.
* all common RequestHandler-s report: request timers / counters, timeouts, errors.
-* <<MetricsReporting-IndexMergeMetrics,index-level events>>: meters for minor / major merges, number of merged docs, number of deleted docs, gauges for currently running merges and their size.
+* <<Index Merge Metrics,index-level events>>: meters for minor / major merges, number of merged docs, number of deleted docs, gauges for currently running merges and their size.
* shard replication and transaction log replay on replicas (TBD, SOLR-9856)
* TBD: caches, update handler details, and other relevant SolrInfoMBean-s
-// OLD_CONFLUENCE_ID: MetricsReporting-HTTPRegistry(solr.http):
-
-[[MetricsReporting-HTTPRegistry_solr.http_]]
=== HTTP Registry (`solr.http`):
* open / available / pending connections for shard handler and update handler
-// OLD_CONFLUENCE_ID: MetricsReporting-JettyRegistry(solr.jetty):
-
-[[MetricsReporting-JettyRegistry_solr.jetty_]]
=== Jetty Registry (`solr.jetty`):
* threads and pools,
@@ -71,7 +61,6 @@ These are the major groups of metrics that are collected:
In the future, metrics will be added for shard leaders and cluster nodes, including aggregations from per-core metrics.
-[[MetricsReporting-Reporters]]
== Reporters
Reporter configurations are specified in `solr.xml` file in `<metrics><reporter>` sections, for example:
@@ -90,13 +79,12 @@ Reporter configurations are specified in `solr.xml` file in `<metrics><reporter>
<str name="prefix">example</str>
<str name="logger">updatesLogger</str>
<str name="filter">QUERYHANDLER./update</str>
- </reporter>
+ </reporter>
</metrics>
...
</solr>
----
-[[MetricsReporting-ReporterArguments]]
=== Reporter Arguments
Reporter plugins use the following arguments:
@@ -113,11 +101,14 @@ Additionally, several implementation-specific initialization arguments can be sp
* *prefix* - (optional str) prefix to be added to metric names, may be helpful in logical grouping of related Solr instances, e.g., machine name or cluster name. Default is empty string, ie. just the registry name and metric name will be used to form a fully-qualified metric name.
* *filter* - (optional str) if not empty then only metric names that start with this value will be reported. Default is no filtering, ie. all metrics from selected registry will be reported.
-Reporters are instantiated for every group and registry that they were configured for, at the time when the respective components are initialized (e.g., on JVM startup or SolrCore load). When reporters are created their configuration is validated (and e.g., necessary connections are established). Uncaught errors at this initialization stage cause the reporter to be discarded from the running configuration. Reporters are closed when the corresponding component is being closed (e.g., on SolrCore close, or JVM shutdown) but metrics that they reported are still maintained in respective registries, as explained in the previous section.
+Reporters are instantiated for every group and registry that they were configured for, at the time when the respective components are initialized (e.g., on JVM startup or SolrCore load).
+
+When reporters are created their configuration is validated (and e.g., necessary connections are established). Uncaught errors at this initialization stage cause the reporter to be discarded from the running configuration.
+
+Reporters are closed when the corresponding component is being closed (e.g., on SolrCore close, or JVM shutdown) but metrics that they reported are still maintained in respective registries, as explained in the previous section.
The following sections provide information on implementation-specific arguments. All implementation classes provided with Solr can be found under `org.apache.solr.metrics.reporters`.
-[[MetricsReporting-JMXReporter]]
=== JMX Reporter
The JMX Reporter uses the `org.apache.solr.metrics.reporters.SolrJmxReporter` class.
@@ -135,18 +126,19 @@ Object names created by this reporter are hierarchical, dot-separated but also p
* category, scope and name for request handlers
* or additional `name1, name2, ... nameN` elements for metrics from other components.
-[[MetricsReporting-SLF4JReporter]]
=== SLF4J Reporter
The SLF4J Reporter uses the `org.apache.solr.metrics.reporters.SolrSlf4jReporter` class.
-It takes the following arguments, in addition to the common arguments <<MetricsReporting-ReporterArguments,above>>.
+It takes the following arguments, in addition to the common arguments <<Reporter Arguments,above>>.
* *logger* - (optional str) name of the logger to use. Default is empty, in which case the group or registry name will be used if specified in the plugin configuration.
-Users can specify logger name (and the corresponding logger configuration in e.g., Log4j configuration) to output metrics-related logging to separate file(s), which can then be processed by external applications. Each log line produced by this reporter consists of configuration-specific fields, and a message that follows this format:
+Users can specify logger name (and the corresponding logger configuration in e.g., Log4j configuration) to output metrics-related logging to separate file(s), which can then be processed by external applications.
-[source,java]
+Each log line produced by this reporter consists of configuration-specific fields, and a message that follows this format:
+
+[source,text]
----
type=COUNTER, name={}, count={}
@@ -161,12 +153,11 @@ type=HISTOGRAM, name={}, count={}, min={}, max={}, mean={}, stddev={}, median={}
(curly braces added only as placeholders for actual values).
-[[MetricsReporting-GraphiteReporter]]
=== Graphite Reporter
The http://graphiteapp.org[Graphite] Reporter uses the `org.apache.solr.metrics.reporters.SolrGraphiteReporter`) class.
-It takes the following attributes, in addition to the common attributes <<MetricsReporting-ReporterArguments,above>>.
+It takes the following attributes, in addition to the common attributes <<Reporter Arguments,above>>.
* *host* - (required str) host name where Graphite server is running.
* *port* - (required int) port number for the server
@@ -174,14 +165,14 @@ It takes the following attributes, in addition to the common attributes <<Metric
When plain-text protocol is used (`pickled==false`) it's possible to use this reporter to integrate with systems other than Graphite, if they can accept space-separated and line-oriented input over network in the following format:
-[source,java]
+[source,text]
----
dot.separated.metric.name[.and.attribute] value epochTimestamp
----
For example:
-[source,java]
+[source,plain]
----
example.solr.node.cores.lazy 0 1482932097
example.solr.node.cores.loaded 1 1482932097
@@ -192,28 +183,27 @@ example.solr.jetty.org.eclipse.jetty.server.handler.DefaultHandler.2xx-responses
example.solr.jetty.org.eclipse.jetty.server.handler.DefaultHandler.2xx-responses.mean_rate 0.5698031798408144 1482932097
----
-[[MetricsReporting-GangliaReporter]]
=== Ganglia Reporter
The http://ganglia.info[Ganglia] reporter uses the `org.apache.solr.metrics.reporters.SolrGangliaReporter` class.
-It take the following arguments, in addition to the common arguments <<MetricsReporting-ReporterArguments,above>>.
+It take the following arguments, in addition to the common arguments <<Reporter Arguments,above>>.
* *host* - (required str) host name where Ganglia server is running.
* *port* - (required int) port number for the server
* *multicast* - (optional bool) when true use multicast UDP communication, otherwise use UDP unicast. Default is false.
-[[MetricsReporting-CoreLevelMetrics]]
== Core Level Metrics
These metrics are available only on a per-core basis. Metrics that are aggregated across cores are not yet available.
-[[MetricsReporting-IndexMergeMetrics]]
=== Index Merge Metrics
-These metrics are collected in respective registries for each core (e.g., `solr.core.collection1....`), under the `INDEX` category. Basic metrics are always collected - collection of additional metrics can be turned on using boolean parameters in the `/config/indexConfig/metrics` section of `solrconfig.xml`:
+These metrics are collected in respective registries for each core (e.g., `solr.core.collection1....`), under the `INDEX` category.
+
+Basic metrics are always collected - collection of additional metrics can be turned on using boolean parameters in the `/config/indexConfig/metrics` section of `solrconfig.xml`:
-[source,java]
+[source,xml]
----
<config>
...
@@ -250,26 +240,24 @@ If the boolean flag `mergeDetails` is true then the following additional metrics
* `INDEX.merge.major.docs` - meter for the number of documents merged in major merge operations
* `INDEX.merge.major.deletedDocs` - meter for the number of deleted documents expunged in major merge operations
-[[MetricsReporting-MetricsAPI]]
== Metrics API
The `admin/metrics` endpoint provides access to all the metrics for all metric groups.
A few query parameters are available to limit the request:
-* **group**: The metric group to retrieve. The default is `all` to retrieve all metrics for all groups. Other possible values are: `jvm`, `jetty`, `node`, and `core`. More than one group can be specified in a request; multiple group names should be separated by a comma.
-* **type**: The type of metric to retrieve. The default is `all` to retrieve all metric types. Other possible values are `counter`, `gauge`, `histogram`, `meter`, and `timer`. More than one type can be specified in a request; multiple types should be separated by a comma.
-* **prefix**: The first characters of metric name that will filter the metrics returned to those starting with the provided string. It can be combined with group and/or type parameters. More than one prefix can be specified in a request; multiple prefixes should be separated by a comma. Prefix matching is also case-sensitive.
+* *group*: The metric group to retrieve. The default is `all` to retrieve all metrics for all groups. Other possible values are: `jvm`, `jetty`, `node`, and `core`. More than one group can be specified in a request; multiple group names should be separated by a comma.
+* *type*: The type of metric to retrieve. The default is `all` to retrieve all metric types. Other possible values are `counter`, `gauge`, `histogram`, `meter`, and `timer`. More than one type can be specified in a request; multiple types should be separated by a comma.
+* *prefix*: The first characters of metric name that will filter the metrics returned to those starting with the provided string. It can be combined with group and/or type parameters. More than one prefix can be specified in a request; multiple prefixes should be separated by a comma. Prefix matching is also case-sensitive.
Like other request handlers, the Metrics API can also take the `wt` parameter to define the output format.
-[[MetricsReporting-Examples]]
=== Examples
Request only "counter" type metrics in the "core" group, returned in JSON:
-`http://localhost:8983/solr/admin/metrics?wt=json&type=counter&group=core`
+`\http://localhost:8983/solr/admin/metrics?wt=json&type=counter&group=core`
Request only "core" group metrics that start with "INDEX", returned in JSON:
-`http://localhost:8983/solr/admin/metrics?wt=json&prefix=INDEX&group=core`
+`\http://localhost:8983/solr/admin/metrics?wt=json&prefix=INDEX&group=core`
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/0ffdf3d5/solr/solr-ref-guide/src/morelikethis.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/morelikethis.adoc b/solr/solr-ref-guide/src/morelikethis.adoc
index 753866f..d3e6b13 100644
--- a/solr/solr-ref-guide/src/morelikethis.adoc
+++ b/solr/solr-ref-guide/src/morelikethis.adoc
@@ -2,9 +2,15 @@
:page-shortname: morelikethis
:page-permalink: morelikethis.html
-The `MoreLikeThis` search component enables users to query for documents similar to a document in their result list. It does this by using terms from the original document to find similar documents in the index.
+The `MoreLikeThis` search component enables users to query for documents similar to a document in their result list.
-There are three ways to use MoreLikeThis. The first, and most common, is to use it as a request handler. In this case, you would send text to the MoreLikeThis request handler as needed (as in when a user clicked on a "similar documents" link). The second is to use it as a search component. This is less desirable since it performs the MoreLikeThis analysis on every document returned. This may slow search results. The final approach is to use it as a request handler but with externally supplied text. This case, also referred to as the MoreLikeThisHandler, will supply information about similar documents in the index based on the text of the input document.
+It does this by using terms from the original document to find similar documents in the index.
+
+There are three ways to use MoreLikeThis. The first, and most common, is to use it as a request handler. In this case, you would send text to the MoreLikeThis request handler as needed (as in when a user clicked on a "similar documents" link).
+
+The second is to use it as a search component. This is less desirable since it performs the MoreLikeThis analysis on every document returned. This may slow search results.
+
+The final approach is to use it as a request handler but with externally supplied text. This case, also referred to as the MoreLikeThisHandler, will supply information about similar documents in the index based on the text of the input document.
[[MoreLikeThis-HowMoreLikeThisWorks]]
== How MoreLikeThis Works
@@ -25,7 +31,7 @@ The next phase filters terms from the original document using thresholds defined
The table below summarizes the `MoreLikeThis` parameters supported by Lucene/Solr. These parameters can be used with any of the three possible MoreLikeThis approaches.
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Description
|mlt.fl |Specifies the fields to use for similarity. If possible, these should have stored `termVectors`.
@@ -45,7 +51,7 @@ The table below summarizes the `MoreLikeThis` parameters supported by Lucene/Sol
Using MoreLikeThis as a search component returns similar documents for each document in the response set. In addition to the common parameters, these additional options are available:
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Description
|mlt |If set to true, activates the `MoreLikeThis` component and enables Solr to return `MoreLikeThis` results.
@@ -57,7 +63,7 @@ Using MoreLikeThis as a search component returns similar documents for each docu
The table below summarizes parameters accessible through the `MoreLikeThisHandler`. It supports faceting, paging, and filtering using common query parameters, but does not work well with alternate query parsers.
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Description
|mlt.match.include |Specifies whether or not the response should include the matched document. If set to false, the response will look like a normal select response.
@@ -68,9 +74,4 @@ The table below summarizes parameters accessible through the `MoreLikeThisHandle
[[MoreLikeThis-MoreLikeThisQueryParser]]
== More Like This Query Parser
-The `mlt` query parser provides a mechanism to retrieve documents similar to a given document, like the handler. More information on the usage of the mlt query parser can be found <<other-parsers.adoc#other-parsers,here>>.
-
-[[MoreLikeThis-RelatedTopics]]
-== Related Topics
-
-* <<requesthandlers-and-searchcomponents-in-solrconfig.adoc#requesthandlers-and-searchcomponents-in-solrconfig,RequestHandlers and SearchComponents in SolrConfig>>
+The `mlt` query parser provides a mechanism to retrieve documents similar to a given document, like the handler. More information on the usage of the mlt query parser can be found int the section <<other-parsers.adoc#other-parsers,Other Parsers>>.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/0ffdf3d5/solr/solr-ref-guide/src/near-real-time-searching.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/near-real-time-searching.adoc b/solr/solr-ref-guide/src/near-real-time-searching.adoc
index a0f2e9a..c847f93 100644
--- a/solr/solr-ref-guide/src/near-real-time-searching.adoc
+++ b/solr/solr-ref-guide/src/near-real-time-searching.adoc
@@ -2,9 +2,13 @@
:page-shortname: near-real-time-searching
:page-permalink: near-real-time-searching.html
-Near Real Time (NRT) search means that documents are available for search almost immediately after being indexed: additions and updates to documents are seen in 'near' real time. Solr does not block updates while a commit is in progress. Nor does it wait for background merges to complete before opening a new search of indexes and returning.
+Near Real Time (NRT) search means that documents are available for search almost immediately after being indexed.
-With NRT, you can modify a `commit` command to be a **soft commit**, which avoids parts of a standard commit that can be costly. You will still want to do standard commits to ensure that documents are in stable storage, but *soft commits* let you see a very near real time view of the index in the meantime. However, pay special attention to cache and autowarm settings as they can have a significant impact on NRT performance.
+This allows additions and updates to documents to be seen in 'near' real time. Solr does not block updates while a commit is in progress. Nor does it wait for background merges to complete before opening a new search of indexes and returning.
+
+With NRT, you can modify a `commit` command to be a *soft commit*, which avoids parts of a standard commit that can be costly. You will still want to do standard commits to ensure that documents are in stable storage, but *soft commits* let you see a very near real time view of the index in the meantime.
+
+However, pay special attention to cache and autowarm settings as they can have a significant impact on NRT performance.
[[NearRealTimeSearching-CommitsandOptimizing]]
== Commits and Optimizing
@@ -17,7 +21,7 @@ An *optimize* is like a *hard commit* except that it forces all of the index seg
Soft commit takes uses two parameters: `maxDocs` and `maxTime`.
-[width="100%",cols="50%,50%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Description
|`maxDocs` |Integer. Defines the number of documents to queue before pushing them to the index. It works in conjunction with the `update_handler_autosoftcommit_max_time` parameter in that if either limit is reached, the documents will be pushed to the index.
@@ -47,7 +51,7 @@ It's better to use `maxTime` rather than `maxDocs` to modify an `autoSoftCommit`
[[NearRealTimeSearching-OptionalAttributesforcommitandoptimize]]
=== Optional Attributes for `commit` and `optimize`
-[width="100%",cols="34%,33%,33%",options="header",]
+[width="100%",options="header",]
|===
|Parameter |Valid Attributes |Description
|`waitSearcher` |true, false |Block until a new searcher is opened and registered as the main query searcher, making the changes visible. Default is true.
@@ -66,11 +70,11 @@ Example of `commit` and `optimize` with optional attributes:
----
[[NearRealTimeSearching-PassingcommitandcommitWithinparametersaspartoftheURL]]
-=== Passing `commit` and `commitWithin` parameters as part of the URL
+=== Passing `commit` and `commitWithin` Parameters as Part of the URL
Update handlers can also get `commit`-related parameters as part of the update URL. This example adds a small test document and causes an explicit commit to happen immediately afterwards:
-[source,xml]
+[source,text]
----
http://localhost:8983/solr/my_collection/update?stream.body=<add><doc>
<field name="id">testdoc</field></doc></add>&commit=true
@@ -78,25 +82,24 @@ http://localhost:8983/solr/my_collection/update?stream.body=<add><doc>
Alternately, you may want to use this:
-[source,xml]
+[source,text]
----
http://localhost:8983/solr/my_collection/update?stream.body=<optimize/>
----
This example causes the index to be optimized down to at most 10 segments, but won't wait around until it's done (`waitFlush=false`):
-[source,bash]
+[source,text]
----
curl 'http://localhost:8983/solr/my_collection/update?optimize=true&maxSegments=10&waitFlush=false'
----
This example adds a small test document with a `commitWithin` instruction that tells Solr to make sure the document is committed no later than 10 seconds later (this method is generally preferred over explicit commits):
-[source,bash]
+[source,text]
----
curl http://localhost:8983/solr/my_collection/update?commitWithin=10000
- -H "Content-Type: text/xml" --data-binary
- '<add><doc><field name="id">testdoc</field></doc></add>'
+ -H "Content-Type: text/xml" --data-binary '<add><doc><field name="id">testdoc</field></doc></add>'
----
[[NearRealTimeSearching-ChangingdefaultcommitWithinBehavior]]