This is an automated email from the ASF dual-hosted git repository.
pjfanning pushed a commit to branch 1.7.x
in repository https://gitbox.apache.org/repos/asf/pekko.git
The following commit(s) were added to refs/heads/1.7.x by this push:
new c72b5aedaf backport doc fixes (#3446)
c72b5aedaf is described below
commit c72b5aedaf9a70be7625e5c18b44450e64b9143f
Author: PJ Fanning <[email protected]>
AuthorDate: Sun Aug 16 13:11:44 2026 +0100
backport doc fixes (#3446)
* backport doc fixes
* add back some doc
Clarify the differences between inet-address and async-dns protocols in the
documentation.
---
docs/src/main/paradox/io-dns.md | 4 ++--
docs/src/main/paradox/split-brain-resolver.md | 14 +++++++-------
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/docs/src/main/paradox/io-dns.md b/docs/src/main/paradox/io-dns.md
index c81cba907d..b073412413 100644
--- a/docs/src/main/paradox/io-dns.md
+++ b/docs/src/main/paradox/io-dns.md
@@ -27,7 +27,7 @@ Users should pick one of the built in extensions.
@@@
-Pekko DNS is a pluggable way to interact with DNS. Implementations much
implement `org.apache.pekko.io.DnsProvider` and provide a configuration
+Pekko DNS is a pluggable way to interact with DNS. Implementations must
implement `org.apache.pekko.io.DnsProvider` and provide a configuration
block that specifies the implementation via `provider-object`.
@@@ note { title="DNS via Pekko Discovery" }
@@ -41,7 +41,7 @@ To select which `DnsProvider` to use set
`pekko.io.dns.resolver` to the location
There are currently two implementations:
* `inet-address` - Based on the JDK's `InetAddress`. Using this will be
subject to both the JVM's DNS cache and its built in one.
-* `async-dns` - A native implemention of the DNS protocol that does not use
any JDK classes or caches.
+* `async-dns` - A native implementation of the DNS protocol that does not use
any JDK classes or caches.
`inet-address` is the default implementation as it pre-dates `async-dns`,
`async-dns` will likely become the default in the next major release.
diff --git a/docs/src/main/paradox/split-brain-resolver.md
b/docs/src/main/paradox/split-brain-resolver.md
index f16843e37a..ac52324fd5 100644
--- a/docs/src/main/paradox/split-brain-resolver.md
+++ b/docs/src/main/paradox/split-brain-resolver.md
@@ -227,22 +227,22 @@ of 4 and 5 nodes the side with 5 nodes will survive and
the other 4 nodes will b
in the 5 node cluster, no more failures can be handled, because the remaining
cluster size would be
less than 5. In the case of another failure in that 5 node cluster all nodes
will be downed.
-Therefore it is important that you join new nodes when old nodes have been
removed.
+Therefore, it is important that you join new nodes when old nodes have been
removed.
Another consequence of this is that if there are unreachable nodes when
starting up the cluster,
before reaching this limit, the cluster may shut itself down immediately. This
is not an issue
if you start all nodes at approximately the same time or use the
`pekko.cluster.min-nr-of-members`
-to define required number of members before the leader changes member status
of 'Joining' members to 'Up'
+to define required number of members before the leader changes member status
of 'Joining' members to 'Up'.
You can tune the timeout after which downing decisions are made using the
`stable-after` setting.
You should not add more members to the cluster than **quorum-size * 2 - 1**. A
warning is logged
-if this recommendation is violated. If the exceeded cluster size remains when
a SBR decision is
+if this recommendation is violated. If the exceeded cluster size remains when
an SBR decision is
needed it will down all nodes because otherwise there is a risk that both
sides may down each
other and thereby form two separate clusters.
-For rolling updates it's best to leave the cluster gracefully via
+For rolling updates, it's best to leave the cluster gracefully via
@ref:[Coordinated Shutdown](coordinated-shutdown.md) (SIGTERM).
-For successful leaving SBR will not be used (no downing) but if there is an
unreachability problem
+For successful leaving, SBR will not be used (no downing) but if there is an
unreachability problem
at the same time as the rolling update is in progress there could be an SBR
decision. To avoid that
the total number of members limit is not exceeded during the rolling update
it's recommended to
leave and fully remove one node before adding a new one, when using
`static-quorum`.
@@ -380,7 +380,7 @@ See also configuration and additional dependency in
[Kubernetes Lease]($pekko.do
## Indirectly connected nodes
-In a malfunctional network there can be situations where nodes are observed as
unreachable via some network
+In a malfunctioning network there can be situations where nodes are observed
as unreachable via some network
links but they are still indirectly connected via other nodes, i.e. it's not a
clean network partition (or node crash).
When this situation is detected the Split Brain Resolvers will keep fully
connected nodes and down all the indirectly
@@ -453,7 +453,7 @@ You would like to configure this to a short duration to
have quick failover, but
risk of having multiple singleton/sharded instances running at the same time
and it may take a different
amount of time to act on the decision (dissemination of the down/removal). The
duration is by default
the same as the `stable-after` property (see @ref:[Stable
after](#stable-after) above). It is recommended to
-leave this value as is, but it can also be separately overriden with the
`pekko.cluster.down-removal-margin` property.
+leave this value as is, but it can also be separately overridden with the
`pekko.cluster.down-removal-margin` property.
Another concern for setting this
`stable-after`/`pekko.cluster.down-removal-margin` is dealing with JVM pauses
e.g.
garbage collection. When a node is unresponsive it is not known if it is due
to a pause, overload, a crash or a
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
