diff --git a/docs/community/integrations.asciidoc b/docs/community/integrations.asciidoc index bb2ff6850a0..8b938933af8 100644 --- a/docs/community/integrations.asciidoc +++ b/docs/community/integrations.asciidoc @@ -59,7 +59,7 @@ * http://searchbox-io.github.com/wp-elasticsearch/[Wp-Elasticsearch]: Elasticsearch WordPress Plugin - + * https://github.com/wallmanderco/elasticsearch-indexer[Elasticsearch Indexer]: Elasticsearch WordPress Plugin @@ -90,7 +90,7 @@ A Java Object Search Engine Mapping (OSEM) for Elasticsearch * https://github.com/twitter/storehaus[Twitter Storehaus]: - Thin asynchronous scala client for storehaus. + Thin asynchronous Scala client for Storehaus. * https://doc.tiki.org/Elasticsearch[Tiki Wiki CMS Groupware] Tiki has native support for Elasticsearch. This provides faster & better search (facets, etc), along with some Natural Language Processing features (ex.: More like this) diff --git a/docs/groovy-api/anatomy.asciidoc b/docs/groovy-api/anatomy.asciidoc index fe172266547..33d8ef72f3d 100644 --- a/docs/groovy-api/anatomy.asciidoc +++ b/docs/groovy-api/anatomy.asciidoc @@ -50,7 +50,7 @@ failure: [source,js] -------------------------------------------------- indexR.success = {IndexResponse response -> - pritnln "Indexed $response.id into $response.index/$response.type" + println "Indexed $response.id into $response.index/$response.type" } indexR.failure = {Throwable t -> println "Failed to index: $t.message" diff --git a/docs/java-api/query-dsl-filters.asciidoc b/docs/java-api/query-dsl-filters.asciidoc index 2240a3b93fc..2e8e8221a8a 100644 --- a/docs/java-api/query-dsl-filters.asciidoc +++ b/docs/java-api/query-dsl-filters.asciidoc @@ -1,7 +1,7 @@ [[query-dsl-filters]] == Query DSL - Filters -elasticsearch provides a full Java query dsl in a similar manner to the +elasticsearch provides a full Java query DSL in a similar manner to the REST {ref}/query-dsl.html[Query DSL]. The factory for filter builders is `FilterBuilders`. @@ -182,7 +182,7 @@ FilterBuilder filter = geoDistanceRangeFilter("pin.location") <1> <5> include lower value means that `from` is `gt` when `false` or `gte` when `true` <6> include upper value means that `to` is `lt` when `false` or `lte` when `true` <7> optimize bounding box: `memory`, `indexed` or `none` -<8> distance computation mode: `GeoDistance.SLOPPY_ARC` (default), `GeoDistance.ARC` (slighly more precise but +<8> distance computation mode: `GeoDistance.SLOPPY_ARC` (default), `GeoDistance.ARC` (slightly more precise but significantly slower) or `GeoDistance.PLANE` (faster, but inaccurate on long distances and close to the poles) Note that you can cache the result using diff --git a/docs/reference/docs/delete.asciidoc b/docs/reference/docs/delete.asciidoc index 1cf2aedf2ae..d157b9efc43 100644 --- a/docs/reference/docs/delete.asciidoc +++ b/docs/reference/docs/delete.asciidoc @@ -58,7 +58,7 @@ document to not be deleted. Many times, the routing value is not known when deleting a document. For those cases, when specifying the `_routing` mapping as `required`, and -no routing value is specified, the delete will be broadcasted +no routing value is specified, the delete will be broadcast automatically to all shards. [float] diff --git a/docs/reference/search.asciidoc b/docs/reference/search.asciidoc index e1609ae75f9..9a0de108c5a 100644 --- a/docs/reference/search.asciidoc +++ b/docs/reference/search.asciidoc @@ -11,7 +11,7 @@ exception of the <> endpoints. [[search-routing]] == Routing -When executing a search, it will be broadcasted to all the index/indices +When executing a search, it will be broadcast to all the index/indices shards (round robin between replicas). Which shards will be searched on can be controlled by providing the `routing` parameter. For example, when indexing tweets, the routing value can be the user name: diff --git a/docs/resiliency/index.asciidoc b/docs/resiliency/index.asciidoc index b1f3c7a3049..8497a02567c 100644 --- a/docs/resiliency/index.asciidoc +++ b/docs/resiliency/index.asciidoc @@ -449,7 +449,7 @@ In order to best validate for resiliency in Elasticsearch, we rewrote the Elasti Each of our integration tests runs against a cluster with a random number of nodes, and indices have a random number of shards and replicas. Merge settings change for every run, indexing is done in serial or async fashion or even wrapped in a bulk operation and thread pool sizes vary to ensure that we don’t produce a deadlock no matter what happens. The list of places we use this randomization infrastructure is long, and growing every day, and has saved us headaches several times before we shipped a particular feature. -At Elasticsearch, we live the philosophy that we can miss a bug once, but never a second time. We make our tests more evil as you go, introducing randomness in all the areas where we discovered bugs. We figure if our tests don’t fail, weare not trying hard enough! If you are interested in how we have evolved our test infrastructure over time check out https://github.com/elasticsearch/elasticsearch/issues?q=label%3Atest[issues labeled with ``test'' on GitHub]. +At Elasticsearch, we live the philosophy that we can miss a bug once, but never a second time. We make our tests more evil as you go, introducing randomness in all the areas where we discovered bugs. We figure if our tests don’t fail, we are not trying hard enough! If you are interested in how we have evolved our test infrastructure over time check out https://github.com/elasticsearch/elasticsearch/issues?q=label%3Atest[issues labeled with ``test'' on GitHub]. [float] === Lucene Loses Data On File Descriptors Failure (STATUS: DONE, v0.90.0)