Merge branch 'master' of github.com:elastic/elasticsearch-net

Author: Mpdreamz

docs/asciidoc/aggregations/bucket/filter/filter-aggregation-usage.asciidoc

@@ -7,7 +7,7 @@
 [[filter-aggregation-usage]]
 == Filter Aggregation Usage
 
-Defines a single bucket of all the documents in the current document set context that match a specified filter. 
+Defines a single bucket of all the documents in the current document set context that match a specified filter.
 Often this will be used to narrow down the current aggregation context to a specific set of documents.
 
 Be sure to read the Elasticsearch documentation on {ref_current}/search-aggregations-bucket-filter-aggregation.html[Filter Aggregation]

docs/asciidoc/aggregations/pipeline/moving-average/moving-average-ewma-aggregation-usage.asciidoc

@@ -45,7 +45,7 @@ new SearchRequest<Project>()
     {
         Field = "startedOn",
         Interval = DateInterval.Month,
-        Aggregations = 
+        Aggregations =
             new SumAggregation("commits", "numberOfCommits") &&
             new MovingAverageAggregation("commits_moving_avg", "commits")
             {

docs/asciidoc/aggregations/pipeline/moving-average/moving-average-holt-linear-aggregation-usage.asciidoc

@@ -46,7 +46,7 @@ new SearchRequest<Project>()
     {
         Field = "startedOn",
         Interval = DateInterval.Month,
-        Aggregations = 
+        Aggregations =
             new SumAggregation("commits", "numberOfCommits") &&
             new MovingAverageAggregation("commits_moving_avg", "commits")
             {

docs/asciidoc/aggregations/pipeline/moving-average/moving-average-holt-winters-aggregation-usage.asciidoc

@@ -51,7 +51,7 @@ new SearchRequest<Project>()
     {
         Field = "startedOn",
         Interval = DateInterval.Month,
-        Aggregations = 
+        Aggregations =
             new SumAggregation("commits", "numberOfCommits") &&
             new MovingAverageAggregation("commits_moving_avg", "commits")
             {

docs/asciidoc/aggregations/pipeline/moving-average/moving-average-linear-aggregation-usage.asciidoc

@@ -44,7 +44,7 @@ new SearchRequest<Project>()
     {
         Field = "startedOn",
         Interval = DateInterval.Month,
-        Aggregations = 
+        Aggregations =
             new SumAggregation("commits", "numberOfCommits") &&
             new MovingAverageAggregation("commits_moving_avg", "commits")
             {

docs/asciidoc/aggregations/pipeline/moving-average/moving-average-simple-aggregation-usage.asciidoc

@@ -45,7 +45,7 @@ new SearchRequest<Project>()
     {
         Field = "startedOn",
         Interval = DateInterval.Month,
-        Aggregations = 
+        Aggregations =
             new SumAggregation("commits", "numberOfCommits") &&
             new MovingAverageAggregation("commits_moving_avg", "commits")
             {

docs/asciidoc/client-concepts/connection-pooling/building-blocks/date-time-providers.asciidoc

@@ -7,7 +7,7 @@
 [[date-time-providers]]
 == Date time providers
 
-Not typically something you'll have to pass to the client but all calls to `System.DateTime.UtcNow` 
+Not typically something you'll have to pass to the client but all calls to `System.DateTime.UtcNow`
 in the client have been abstracted by `IDateTimeProvider`. This allows us to unit test timeouts and cluster failover
 without being bound to wall clock time as calculated by using `System.DateTime.UtcNow` directly.
 
@@ -45,7 +45,7 @@ var maxTimeout = TimeSpan.FromMinutes(30);
 Plotting these defaults looks as followed:
 
 [[timeout]]
-.Default formula, x-axis time in minutes, y-axis number of attempts to revive
+.Default formula, x-axis number of attempts to revive, y-axis time in minutes
 image::timeoutplot.png[dead timeout]
 
 The goal here is that whenever a node is resurrected and is found to still be offline, we send it_back to the doghouse_ for an ever increasingly long period, until we hit a bounded maximum.

docs/asciidoc/client-concepts/connection-pooling/pinging/first-usage.asciidoc

@@ -67,7 +67,7 @@ var audit = new Auditor(() => Framework.Cluster
 The first call goes to 9200 which succeeds 
 
 The 2nd call does a ping on 9201 because its used for the first time.
-It fails and so we ping 9202 which also fails. We then ping 9203 becuase
+It fails and so we ping 9202 which also fails. We then ping 9203 because
 we haven't used it before and it succeeds 
 
 Finally we assert that the connectionpool has two nodes that are marked as dead 

docs/asciidoc/client-concepts/connection-pooling/round-robin/round-robin.asciidoc

@@ -14,7 +14,7 @@ round robin over the `live` nodes to evenly distribute request load over all kno
 
 `GetNext` is implemented in a lock free thread safe fashion, meaning each callee gets returned its own cursor to advance
 over the internal list of nodes. This to guarantee each request that needs to fall over tries all the nodes without
-suffering from noisy neighboors advancing a global cursor.
+suffering from noisy neighbours advancing a global cursor.
 
 [source,csharp]
 ----

docs/asciidoc/client-concepts/connection-pooling/round-robin/skip-dead-nodes.asciidoc

@@ -13,7 +13,7 @@ When selecting nodes the connection pool will try and skip all the nodes that ar
 
 GetNext is implemented in a lock free thread safe fashion, meaning each callee gets returned its own cursor to advance
 over the internal list of nodes. This to guarantee each request that needs to fall over tries all the nodes without
-suffering from noisy neighboors advancing a global cursor.
+suffering from noisy neighbours advancing a global cursor.
 
 [source,csharp]
 ----

docs/asciidoc/client-concepts/connection-pooling/sniffing/on-connection-failure.asciidoc

@@ -17,7 +17,7 @@ Here we seed our connection with 5 known nodes 9200-9204 of which we think
 9202, 9203, 9204 are master eligible nodes. Our virtualized cluster will throw once when doing
 a search on 9201. This should a sniff to be kicked off.
 
-When the call fails on 9201 the sniff succeeds and returns a new cluster of healty nodes
+When the call fails on 9201 the sniff succeeds and returns a new cluster of healthy nodes
 this cluster only has 3 nodes and the known masters are 9200 and 9202 but a search on 9201
 still fails once
 

docs/asciidoc/client-concepts/connection-pooling/sniffing/on-stale-cluster-state.asciidoc

@@ -8,7 +8,7 @@
 == Sniffing periodically
 
 Connection pools that return true for `SupportsReseeding` can be configured to sniff periodically.
-In addition to sniffing on startup and sniffing on failures, sniffing periodically can benefit scenerio's where
+In addition to sniffing on startup and sniffing on failures, sniffing periodically can benefit scenarios where
 clusters are often scaled horizontally during peak hours. An application might have a healthy view of a subset of the nodes
 but without sniffing periodically it will never find the nodes that have been added to help out with load
 

docs/asciidoc/client-concepts/connection-pooling/sniffing/role-detection.asciidoc

@@ -103,7 +103,7 @@ await pipeline.SniffAsync();
 [source,csharp]
 ----
 this._settings =
-    this._cluster.Client(u => new SniffingConnectionPool(new[] {u}), c => c.PrettyJson()).ConnectionSettings;
+    this._cluster.Node.Client(u => new SniffingConnectionPool(new[] {u}), c => c.PrettyJson()).ConnectionSettings;
 
 var pipeline = new RequestPipeline(this._settings, DateTimeProvider.Default, new MemoryStreamFactory(),
     new SearchRequestParameters());

docs/asciidoc/client-concepts/connection-pooling/sticky/skip-dead-nodes.asciidoc

@@ -39,7 +39,7 @@ node = pool.CreateView().First();
 node.Uri.Port.Should().Be(9200);
 ----
 
-After we marke the first node alive again we expect it to be hit again
+After we mark the first node alive again we expect it to be hit again
 
 [source,csharp]
 ----

docs/asciidoc/client-concepts/high-level/inference/document-paths.asciidoc

@@ -8,8 +8,8 @@
 == Document Paths
 
 Many API's in Elasticsearch describe a path to a document. In NEST, besides generating a constructor that takes
-and Index, Type and Id seperately, we also generate a constructor taking a `DocumentPath` that allows you to describe the path
-to your document more succintly
+and Index, Type and Id separately, we also generate a constructor taking a `DocumentPath` that allows you to describe the path
+to your document more succinctly
 
 === Creating new instances 
 

docs/asciidoc/client-concepts/high-level/inference/features-inference.asciidoc

@@ -23,7 +23,7 @@ Expect("_mappings,_aliases")
     .WhenSerializing(fieldString);
 ----
 
-Here we new an GET index elasticsearch request whichs takes Indices and Features.
+Here we new an GET index elasticsearch request which takes Indices and Features.
 Notice how we can use the Feature enum directly.
 
 [source,csharp]

docs/asciidoc/client-concepts/high-level/inference/field-inference.asciidoc

@@ -8,7 +8,7 @@
 == Field Inference
 
 Several places in the Elasticsearch API expect the path to a field from your original source document as a string.
-NEST allows you to use C# expressions to strongly type these field path strings. 
+NEST allows you to use C# expressions to strongly type these field path strings.
 
 These expressions are assigned to a type called `Field` and there are several ways to create an instance of one
 
@@ -311,7 +311,7 @@ and we want to append the suffix "raw" to each
 
 [source,csharp]
 ----
-var fieldExpressions = 
+var fieldExpressions =
     expressions.Select<Expression<Func<Project, object>>, Field>(e => e.AppendSuffix("raw")).ToList();
 
 Expect("name.raw").WhenSerializing(fieldExpressions[0]);
@@ -411,7 +411,7 @@ var fieldNameOnA = client.Infer.Field(Field<A>(p => p.C.Name));
 var fieldNameOnB = client.Infer.Field(Field<B>(p => p.C.Name));
 ----
 
-Here we have to similary shaped expressions on coming from A and on from B
+Here we have two similarly shaped expressions, one coming from A and one from B
 that will resolve to the same field name, as expected
 
 [source,csharp]
@@ -444,7 +444,7 @@ fieldNameOnA.Should().Be("d.name");
 fieldNameOnB.Should().Be("c.name");
 ----
 
-however we didn't break inferrence on the first client instance using its separate connection settings 
+however we didn't break inference on the first client instance using its separate connection settings 
 
 [source,csharp]
 ----
@@ -466,7 +466,7 @@ To wrap up, the precedence in which field names are inferred is:
 
 . A NEST property mapping
 
-. Ask the serializer if the property has a verbatim value e.g it has an explicit JsonPropery attribute.
+. Ask the serializer if the property has a verbatim value e.g it has an explicit JsonProperty attribute.
 
 . Pass the MemberInfo's Name to the DefaultFieldNameInferrer which by default camelCases
 

docs/asciidoc/client-concepts/high-level/inference/index-name-inference.asciidoc

@@ -12,9 +12,9 @@ as part of the request in order to know what index/indices a request should oper
 
 NEST has a number of ways in which an index name can be specified
 
-=== Default Index name on ConnectionSettings
+=== Default Index name on Connection Settings
 
-A default index name can be specified on `ConnectionSettings` usinf `.DefaultIndex()`.
+A default index name can be specified on `ConnectionSettings` using `.DefaultIndex()`.
 This is the default index name to use when no other index name can be resolved for a request
 
 [source,csharp]