Skip to content

Commit 754bc1d

Browse files
committed
fix spellings
1 parent 3e6b76b commit 754bc1d

26 files changed

+94
-47
lines changed

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

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
[[date-time-providers]]
88
== Date time providers
99

10-
Not typically something you'll have to pass to the client but all calls to `System.DateTime.UtcNow`
10+
Not typically something you'll have to pass to the client but all calls to `System.DateTime.UtcNow`
1111
in the client have been abstracted by `IDateTimeProvider`. This allows us to unit test timeouts and cluster failover
1212
without being bound to wall clock time as calculated by using `System.DateTime.UtcNow` directly.
1313

@@ -32,7 +32,7 @@ to provide a custom implementation for.
3232
var dateTimeProvider = DateTimeProvider.Default;
3333
----
3434

35-
The default timeout calculation is: `min(timeout * 2 ^ (attempts * 0.5 -1), maxTimeout)`, where the
35+
The default timeout calculation is: `min(timeout * 2 ^ (attempts * 0.5 -1), maxTimeout)`, where the
3636
default values for `timeout` and `maxTimeout` are
3737

3838
[source,csharp]
@@ -45,7 +45,7 @@ var maxTimeout = TimeSpan.FromMinutes(30);
4545
Plotting these defaults looks as followed:
4646

4747
[[timeout]]
48-
.Default formula, x-axis time in minutes, y-axis number of attempts to revive
48+
.Default formula, x-axis number of attempts to revive, y-axis time in minutes
4949
image::timeoutplot.png[dead timeout]
5050

5151
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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -67,7 +67,7 @@ var audit = new Auditor(() => Framework.Cluster
6767
The first call goes to 9200 which succeeds
6868

6969
The 2nd call does a ping on 9201 because its used for the first time.
70-
It fails and so we ping 9202 which also fails. We then ping 9203 becuase
70+
It fails and so we ping 9202 which also fails. We then ping 9203 because
7171
we haven't used it before and it succeeds
7272

7373
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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ round robin over the `live` nodes to evenly distribute request load over all kno
1414

1515
`GetNext` is implemented in a lock free thread safe fashion, meaning each callee gets returned its own cursor to advance
1616
over the internal list of nodes. This to guarantee each request that needs to fall over tries all the nodes without
17-
suffering from noisy neighboors advancing a global cursor.
17+
suffering from noisy neighbours advancing a global cursor.
1818

1919
[source,csharp]
2020
----

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@ When selecting nodes the connection pool will try and skip all the nodes that ar
1313

1414
GetNext is implemented in a lock free thread safe fashion, meaning each callee gets returned its own cursor to advance
1515
over the internal list of nodes. This to guarantee each request that needs to fall over tries all the nodes without
16-
suffering from noisy neighboors advancing a global cursor.
16+
suffering from noisy neighbours advancing a global cursor.
1717

1818
[source,csharp]
1919
----

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@ Here we seed our connection with 5 known nodes 9200-9204 of which we think
1717
9202, 9203, 9204 are master eligible nodes. Our virtualized cluster will throw once when doing
1818
a search on 9201. This should a sniff to be kicked off.
1919

20-
When the call fails on 9201 the sniff succeeds and returns a new cluster of healty nodes
20+
When the call fails on 9201 the sniff succeeds and returns a new cluster of healthy nodes
2121
this cluster only has 3 nodes and the known masters are 9200 and 9202 but a search on 9201
2222
still fails once
2323

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
== Sniffing periodically
99

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

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

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,8 +8,8 @@
88
== Document Paths
99

1010
Many API's in Elasticsearch describe a path to a document. In NEST, besides generating a constructor that takes
11-
and Index, Type and Id seperately, we also generate a constructor taking a `DocumentPath` that allows you to describe the path
12-
to your document more succintly
11+
and Index, Type and Id separately, we also generate a constructor taking a `DocumentPath` that allows you to describe the path
12+
to your document more succinctly
1313

1414
=== Creating new instances
1515

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ Expect("_mappings,_aliases")
2525

2626
=== Implicit conversion
2727

28-
Here we instantiate a GET index request whichs takes two features, settings and warmers.
28+
Here we instantiate a GET index request which takes two features, settings and warmers.
2929
Notice how we can use the `Feature` enum directly.
3030

3131
[source,csharp]

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

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -64,7 +64,7 @@ to prevent ambiguity over which property should be used when resolving the path
6464
=== Implicit Conversion
6565

6666
As you can see from the previous examples, using the constructor is rather involved and cumbersome.
67-
Becuase of this, you can also implicitly convert strings and expressions to a `Field`
67+
Because of this, you can also implicitly convert strings and expressions to a `Field`
6868

6969
[source,csharp]
7070
----
@@ -411,7 +411,7 @@ var fieldNameOnA = client.Infer.Field(Field<A>(p => p.C.Name));
411411
var fieldNameOnB = client.Infer.Field(Field<B>(p => p.C.Name));
412412
----
413413

414-
Here we have to similary shaped expressions on coming from A and on from B
414+
Here we have two similarly shaped expressions, one coming from A and one from B
415415
that will resolve to the same field name, as expected
416416

417417
[source,csharp]
@@ -444,7 +444,7 @@ fieldNameOnA.Should().Be("d.name");
444444
fieldNameOnB.Should().Be("c.name");
445445
----
446446

447-
however we didn't break inferrence on the first client instance using its separate connection settings
447+
however we didn't break inference on the first client instance using its separate connection settings
448448

449449
[source,csharp]
450450
----
@@ -466,7 +466,7 @@ To wrap up, the precedence in which field names are inferred is:
466466

467467
. A NEST property mapping
468468

469-
. Ask the serializer if the property has a verbatim value e.g it has an explicit JsonPropery attribute.
469+
. Ask the serializer if the property has a verbatim value e.g it has an explicit JsonProperty attribute.
470470

471471
. Pass the MemberInfo's Name to the DefaultFieldNameInferrer which by default camelCases
472472

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ NEST has a number of ways in which an index name can be specified
1414

1515
=== Default Index name on ConnectionSettings
1616

17-
A default index name can be specified on `ConnectionSettings` usinf `.DefaultIndex()`.
17+
A default index name can be specified on `ConnectionSettings` using `.DefaultIndex()`.
1818
This is the default index name to use when no other index name can be resolved for a request
1919

2020
[source,csharp]

0 commit comments

Comments
 (0)