diff --git a/akka-docs/src/main/paradox/actors.md b/akka-docs/src/main/paradox/actors.md
index a4851e9cae..a6dd214981 100644
--- a/akka-docs/src/main/paradox/actors.md
+++ b/akka-docs/src/main/paradox/actors.md
@@ -27,7 +27,7 @@ The [Actor Model](https://en.wikipedia.org/wiki/Actor_model) provides a higher l
 and distributed systems. It alleviates the developer from having to deal with
 explicit locking and thread management, making it easier to write correct
 concurrent and parallel systems. Actors were defined in the 1973 paper by Carl
-Hewitt but have been popularized by the Erlang language, and used for example at
+Hewitt but have been popularized by the Erlang language and used for example at
 Ericsson with great success to build highly concurrent and reliable telecom
 systems.
 
@@ -52,7 +52,7 @@ as well as @ref:[Actor References, Paths and Addresses](general/addressing.md).
 
 Actors are implemented by extending the `Actor` base trait and implementing the
 `receive` method. The `receive` method should define a series of case
-statements (which has the type `PartialFunction[Any, Unit]`) that defines
+statements (which has the type `PartialFunction[Any, Unit]`) that define
 which messages your Actor can handle, using standard Scala pattern matching,
 along with the implementation of how the messages should be processed.
 
@@ -61,12 +61,10 @@ along with the implementation of how the messages should be processed.
 @@@ div { .group-java }
 
 Actor classes are implemented by extending the `AbstractActor` class and setting
-the “initial behavior” in `createReceive` method.
+the “initial behavior” in the `createReceive` method.
 
-`createReceive` method has no arguments and returns `AbstractActor.Receive`. It 
-defines which messages your Actor can handle, along with the implementation of how 
-the messages should be processed. You can build such behavior with a builder named 
-`ReceiveBuilder`. This build has convenient factory in `AbstractActor` called `receiveBuilder`.
+The `createReceive` method has no arguments and returns `AbstractActor.Receive`. It defines which messages your Actor can handle, along with the implementation of how the messages should be processed. You can build such behavior with a builder named
+`ReceiveBuilder`. This build has a convenient factory in `AbstractActor` called `receiveBuilder`.
 
 @@@
 
@@ -78,8 +76,7 @@ Scala
 Java
 :  @@snip [MyActor.java](/akka-docs/src/test/java/jdocs/actor/MyActor.java) { #imports #my-actor }
 
-Please note that the Akka Actor @scala[`receive`] message loop is exhaustive, which 
-is different compared to Erlang and the late Scala Actors. This means that you 
+Please note that the Akka Actor @scala[`receive`] message loop is exhaustive, which is different compared to Erlang and the late Scala Actors. This means that you
 need to provide a pattern match for all messages that it can accept and if you
 want to be able to handle unknown messages then you need to have a default case
 as in the example above. Otherwise an `akka.actor.UnhandledMessage(message,
@@ -91,8 +88,8 @@ the actor shall reply to the received message then this must be done explicitly
 as explained below.
 
 The result of the @scala[`receive` method is a partial function object, which is]
-@java[`createReceive` method is `AbstractActor.Receive` which is a wrapper around partial 
-scala function object. It is] stored within the actor as its “initial behavior”, 
+@java[`createReceive` method is `AbstractActor.Receive` which is a wrapper around partial
+scala function object. It is] stored within the actor as its “initial behavior”,
 see @ref:[Become/Unbecome](#become-unbecome) for
 further information on changing the behavior of an actor after its
 construction.
@@ -109,7 +106,7 @@ construction.
 
 `Props` is a configuration class to specify options for the creation
 of actors, think of it as an immutable and thus freely shareable recipe for
-creating an actor including associated deployment information (e.g. which
+creating an actor including associated deployment information (e.g., which
 dispatcher to use, see more below). Here are some examples of how to create a
 `Props` instance.
 
@@ -144,16 +141,16 @@ Scala
 Java
 :  @@snip [ActorDocTest.java](/akka-docs/src/test/java/jdocs/actor/ActorDocTest.java) { #creating-props-deprecated }
 
-This method is not recommended to be used within another actor because it
+This method is not recommended being used within another actor because it
 encourages to close over the enclosing scope, resulting in non-serializable
 `Props` and possibly race conditions (breaking the actor encapsulation).
-On the other hand using this variant in a `Props` factory in
+On the other hand, using this variant in a `Props` factory in
 the actor’s companion object as documented under “Recommended Practices” below
 is completely fine.
 
 There were two use-cases for these methods: passing constructor arguments to
 the actor—which is solved by the newly introduced
-@scala[`Props.apply(clazz, args)`] @java[`Props.create(clazz, args)`] method above or the recommended practice
+@scala[`Props.apply(clazz, args)`] @java[`Props.create(clazz, args)`] method above or the recommended practice
 below—and creating actors “on the spot” as anonymous classes. The latter should
 be solved by making these actors named classes instead (if they are not
 declared within a top-level `object` then the enclosing instance’s `this`
@@ -172,17 +169,17 @@ encapsulation. Never pass an actor’s `this` reference into `Props`!
 
 There are two edge cases in actor creation with `Props`:
 
- * An actor with `AnyVal` arguments.
+* An actor with `AnyVal` arguments.
 
 @@snip [PropsEdgeCaseSpec.scala](/akka-docs/src/test/scala/docs/actor/PropsEdgeCaseSpec.scala) { #props-edge-cases-value-class }
 
 @@snip [PropsEdgeCaseSpec.scala](/akka-docs/src/test/scala/docs/actor/PropsEdgeCaseSpec.scala) { #props-edge-cases-value-class-example }
 
- * An actor with default constructor values.
+* An actor with default constructor values.
 
 @@snip [PropsEdgeCaseSpec.scala](/akka-docs/src/test/scala/docs/actor/PropsEdgeCaseSpec.scala) { #props-edge-cases-default-values }
 
-In both cases an `IllegalArgumentException` will be thrown stating
+In both cases, an `IllegalArgumentException` will be thrown stating
 no matching constructor could be found.
 
 The next section explains the recommended ways to create `Actor` props in a way,
@@ -193,11 +190,11 @@ which simultaneously safe-guards against these edge cases.
 #### Recommended Practices
 
 It is a good idea to provide @scala[factory methods on the companion object of each
-`Actor`] @java[static factory methods for each `Actor`] which help keeping the creation of 
+`Actor`] @java[static factory methods for each `Actor`] which help keeping the creation of
 suitable `Props` as close to the actor definition as possible. This also avoids the pitfalls
 associated with using the @scala[`Props.apply(...)` method which takes a by-name
-argument, since within a companion object] @java[ `Props.create(...)` method which takes 
-arguments as constructor parameters, since within static method] 
+argument, since within a companion object] @java[ `Props.create(...)` method which takes
+arguments as constructor parameters, since within static method]
 the given code block will not retain a reference to its enclosing scope:
 
 Scala
@@ -230,7 +227,7 @@ Java
 :  @@snip [ActorDocTest.java](/akka-docs/src/test/java/jdocs/actor/ActorDocTest.java) { #import-actorRef }
 
 Using the `ActorSystem` will create top-level actors, supervised by the
-actor system’s provided guardian actor, while using an actor’s context will
+actor system’s provided guardian actor while using an actor’s context will
 create a child actor.
 
 Scala
@@ -248,13 +245,13 @@ handle to the actor instance and the only way to interact with it. The
 `ActorRef` is immutable and has a one to one relationship with the Actor
 it represents. The `ActorRef` is also serializable and network-aware.
 This means that you can serialize it, send it over the wire and use it on a
-remote host and it will still be representing the same Actor on the original
+remote host, and it will still be representing the same Actor on the original
 node, across the network.
 
 The name parameter is optional, but you should preferably name your actors,
 since that is used in log messages and for identifying actors. The name must
 not be empty or start with `$`, but it may contain URL encoded characters
-(eg. `%20` for a blank space).  If the given name is already in use by
+(eg., `%20` for a blank space).  If the given name is already in use by
 another child to the same parent an `InvalidActorNameException` is thrown.
 
 Actors are automatically started asynchronously when created.
@@ -265,7 +262,7 @@ Actors are automatically started asynchronously when created.
 
 The recommended way to instantiate actor props uses reflection at runtime
 to determine the correct actor constructor to be invoked and due to technical
-limitations is not supported when said constructor takes arguments that are
+limitations it is not supported when said constructor takes arguments that are
 value classes.
 In these cases you should either unpack the arguments or create the props by
 calling the constructor manually:
@@ -320,22 +317,22 @@ actual Debug messages).
 
 In addition, it offers:
 
- * @scala[`self`] @java[`getSelf()`] reference to the `ActorRef` of the actor
- * @scala[`sender`] @java[`getSender()`] reference sender Actor of the last received message, typically used as described in
-   @scala[[Actor.Reply](#actor-reply)]
-   @java[[LambdaActor.Reply](#lambdaactor-reply)]
- * @scala[`supervisorStrategy`] @java[`supervisorStrategy()`] user overridable definition the strategy to use for supervising child actors
+* @scala[`self`] @java[`getSelf()`] reference to the `ActorRef` of the actor
+* @scala[`sender`] @java[`getSender()`] reference sender Actor of the last received message, typically used as described in
+  @scala[[Actor.Reply](#actor-reply)]
+  @java[[LambdaActor.Reply](#lambdaactor-reply)]
+* @scala[`supervisorStrategy`] @java[`supervisorStrategy()`] user overridable definition the strategy to use for supervising child actors
 
-   This strategy is typically declared inside the actor in order to have access
-to the actor’s internal state within the decider function: since failure is
-communicated as a message sent to the supervisor and processed like other
-messages (albeit outside of the normal behavior), all values and variables
-within the actor are available, as is the `sender` reference (which will
-be the immediate child reporting the failure; if the original failure
-occurred within a distant descendant it is still reported one level up at a
-time).
+  This strategy is typically declared inside the actor to have access
+  to the actor’s internal state within the decider function: since failure is
+  communicated as a message sent to the supervisor and processed like other
+  messages (albeit outside the normal behavior), all values and variables
+  within the actor are available, as is the `sender` reference (which will
+  be the immediate child reporting the failure; if the original failure
+  occurred within a distant descendant it is still reported one level up at a
+  time).
 
- * @scala[`context`] @java[`getContext()`] exposes contextual information for the actor and the current message, such as:
+* @scala[`context`] @java[`getContext()`] exposes contextual information for the actor and the current message, such as:
     * factory methods to create child actors (`actorOf`)
     * system that the actor belongs to
     * parent supervisor
@@ -358,7 +355,7 @@ Scala
 :  @@snip [Actor.scala](/akka-actor/src/main/scala/akka/actor/Actor.scala) { #lifecycle-hooks }
 
 Java
-:  @@snip [ActorDocTest.java](/akka-docs/src/test/java/jdocs/actor/ActorDocTest.java) { #lifecycle-callbacks }  
+:  @@snip [ActorDocTest.java](/akka-docs/src/test/java/jdocs/actor/ActorDocTest.java) { #lifecycle-callbacks }
 
 The implementations shown above are the defaults provided by the @scala[`Actor` trait.] @java[`AbstractActor` class.]
 
@@ -366,31 +363,31 @@ The implementations shown above are the defaults provided by the @scala[`Actor`
 
 ![actor_lifecycle.png](./images/actor_lifecycle.png)
 
-A path in an actor system represents a "place" which might be occupied
+A path in an actor system represents a "place" that might be occupied
 by a living actor. Initially (apart from system initialized actors) a path is
 empty. When `actorOf()` is called it assigns an *incarnation* of the actor
 described by the passed `Props` to the given path. An actor incarnation is
-identified by the path *and a UID*. 
+identified by the path *and a UID*.
 
 It is worth noting about the difference between:
 
-* restart 
-* stop, followed by re-creation of actor
+* restart
+* stop, followed by a re-creation of the actor
 
 as explained below.
 
 A restart only swaps the `Actor`
 instance defined by the `Props` but the incarnation and hence the UID remains
 the same.
-As long as the incarnation is same, you can keep using the same `ActorRef`.
+As long as the incarnation is the same, you can keep using the same `ActorRef`.
 Restart is handled by the @ref:[Supervision Strategy](fault-tolerance.md#creating-a-supervisor-strategy) of actor's parent actor,
 and there is more discussion about @ref:[what restart means](general/supervision.md#supervision-restart).
 
 The lifecycle of an incarnation ends when the actor is stopped. At
-that point the appropriate lifecycle events are called and watching actors
+that point, the appropriate lifecycle events are called and watching actors
 are notified of the termination. After the incarnation is stopped, the path can
-be reused again by creating an actor with `actorOf()`. In this case the
-name of the new incarnation will be the same as the previous one but the
+be reused again by creating an actor with `actorOf()`. In this case, the
+name of the new incarnation will be the same as the previous one, but the
 UIDs will differ. An actor can be stopped by the actor itself, another actor
 or the `ActorSystem` (see @ref:[Stopping actors](#stopping-actors)).
 
@@ -404,8 +401,8 @@ stop all the child Actors that this parent has created.
 @@@
 
 An `ActorRef` always represents an incarnation (path and UID) not just a
-given path. Therefore if an actor is stopped and a new one with the same
-name is created an `ActorRef` of the old incarnation will not point
+given path. Therefore, if an actor is stopped, and a new one with the same
+name is created then an `ActorRef` of the old incarnation will not point
 to the new one.
 
 `ActorSelection` on the other hand points to the path (or multiple paths
@@ -421,8 +418,8 @@ method of the `ActorSelection`, which returns a `Future` of the matching
 <a id="deathwatch"></a>
 ### Lifecycle Monitoring aka DeathWatch
 
-In order to be notified when another actor terminates (i.e. stops permanently,
-not temporary failure and restart), an actor may register itself for reception
+To be notified when another actor terminates (i.e., stops permanently,
+not a temporary failure and restart), an actor may register itself for reception
 of the `Terminated` message dispatched by the other actor upon
 termination (see @ref:[Stopping Actors](#stopping-actors)). This service is provided by the
 `DeathWatch` component of the actor system.
@@ -436,7 +433,7 @@ Java
 :  @@snip [ActorDocTest.java](/akka-docs/src/test/java/jdocs/actor/ActorDocTest.java) { #import-terminated #watch }
 
 It should be noted that the `Terminated` message is generated
-independent of the order in which registration and termination occur.
+independently of the order in which registration and termination occur.
 In particular, the watching actor will receive a `Terminated` message even if the
 watched actor has already been terminated at the time of registration.
 
@@ -444,7 +441,7 @@ Registering multiple times does not necessarily lead to multiple messages being
 generated, but there is no guarantee that only exactly one such message is
 received: if termination of the watched actor has generated and queued the
 message, and another registration is done before this message has been
-processed, then a second message will be queued, because registering for
+processed, then a second message will be queued because registering for
 monitoring of an already terminated actor leads to the immediate generation of
 the `Terminated` message.
 
@@ -463,10 +460,10 @@ Scala
 Java
 :  @@snip [ActorDocTest.java](/akka-docs/src/test/java/jdocs/actor/ActorDocTest.java) { #preStart }
 
-This method is called when the actor is first created. During restarts it is
+This method is called when the actor is first created. During restarts, it is
 called by the default implementation of `postRestart`, which means that
 by overriding that method you can choose whether the initialization code in
-this method is called only exactly once for this actor or for every restart.
+this method is called only exactly once for this actor or every restart.
 Initialization code which is part of the actor’s constructor will always be
 called when an instance of the actor class is created, which happens at every
 restart.
@@ -474,29 +471,29 @@ restart.
 <a id="restart-hook"></a>
 ### Restart Hooks
 
-All actors are supervised, i.e. linked to another actor with a fault
+All actors are supervised, i.e., linked to another actor with a fault
 handling strategy. Actors may be restarted in case an exception is thrown while
 processing a message (see @ref:[supervision](general/supervision.md)). This restart involves the hooks
 mentioned above:
 
- 1. The old actor is informed by calling `preRestart` with the exception
-which caused the restart and the message which triggered that exception; the
-latter may be `None` if the restart was not caused by processing a
-message, e.g. when a supervisor does not trap the exception and is restarted
-in turn by its supervisor, or if an actor is restarted due to a sibling’s
-failure. If the message is available, then that message’s sender is also
-accessible in the usual way (i.e. by calling `sender`).
-    This method is the best place for cleaning up, preparing hand-over to the
-fresh actor instance, etc.  By default it stops all children and calls
-`postStop`.
- 2. The initial factory from the `actorOf` call is used
-to produce the fresh instance.
- 3. The new actor’s `postRestart` method is invoked with the exception
-which caused the restart. By default the `preStart`
-is called, just as in the normal start-up case.
+1. The old actor is informed by calling `preRestart` with the exception
+   which caused the restart, and the message which triggered that exception; the
+   latter may be `None` if the restart was not caused by processing a
+   message, e.g. when a supervisor does not trap the exception and is restarted
+   in turn by its supervisor, or if an actor is restarted due to a sibling’s
+   failure. If the message is available, then that message’s sender is also
+   accessible in the usual way (i.e. by calling `sender`).
+   This method is the best place for cleaning up, preparing hand-over to the
+   fresh actor instance, etc.  By default, it stops all children and calls
+   `postStop`.
+2. The initial factory from the `actorOf` call is used
+   to produce the fresh instance.
+3. The new actor’s `postRestart` method is invoked with the exception
+   which caused the restart. By default the `preStart`
+   is called, just as in the normal start-up case.
 
 An actor restart replaces only the actual actor object; the contents of the
-mailbox is unaffected by the restart, so processing of messages will resume
+mailbox are unaffected by the restart, so the processing of messages will resume
 after the `postRestart` hook returns. The message
 that triggered the exception will not be received again. Any message
 sent to an actor while it is being restarted will be queued to its mailbox as
@@ -543,10 +540,10 @@ Java
 It is always preferable to communicate with other Actors using their ActorRef
 instead of relying upon ActorSelection. Exceptions are
 
- * sending messages using the @ref:[At-Least-Once Delivery](persistence.md#at-least-once-delivery) facility
- * initiating first contact with a remote system
+* sending messages using the @ref:[At-Least-Once Delivery](persistence.md#at-least-once-delivery) facility
+* initiating the first contact with a remote system
 
-In all other cases ActorRefs can be provided during Actor creation or
+In all other cases, ActorRefs can be provided during Actor creation or
 initialization, passing them from parent to child or introducing Actors by
 sending their ActorRefs to other Actors within messages.
 
@@ -577,7 +574,7 @@ does not match any actors the message will be dropped.
 To acquire an `ActorRef` for an `ActorSelection` you need to send
 a message to the selection and use the @scala[`sender()`] @java[`getSender()`] reference of the reply from
 the actor. There is a built-in `Identify` message that all Actors will
-understand and automatically reply to with a `ActorIdentity` message
+understand and automatically reply to with an `ActorIdentity` message
 containing the `ActorRef`. This message is handled specially by the
 actors which are traversed in the sense that if a concrete name lookup fails
 (i.e. a non-wildcard path element does not correspond to a live actor) then a
@@ -613,7 +610,7 @@ An example demonstrating actor look-up is given in @ref:[Remoting Sample](remoti
 Messages can be any kind of object but have to be immutable. @scala[Scala] @java[Akka] can’t enforce
 immutability (yet) so this has to be by convention. @scala[Primitives like String, Int,
 Boolean are always immutable. Apart from these the recommended approach is to
-use Scala case classes which are immutable (if you don’t explicitly expose the
+use Scala case classes that are immutable (if you don’t explicitly expose the
 state) and works great with pattern matching at the receiver side.]
 
 @@@
@@ -631,10 +628,10 @@ Java
 
 Messages are sent to an Actor through one of the following methods.
 
- * @scala[`!`] @java[`tell` ] means “fire-and-forget”, e.g. send a message asynchronously and return
-immediately. @scala[Also known as `tell`.]
- * @scala[`?`] @java[`ask`] sends a message asynchronously and returns a @scala[`Future`]@java[`CompletionStage`]
-representing a possible reply. @scala[Also known as `ask`.]
+* @scala[`!`] @java[`tell` ] means “fire-and-forget”, e.g. send a message asynchronously and return
+  immediately. @scala[Also known as `tell`.]
+* @scala[`?`] @java[`ask`] sends a message asynchronously and returns a @scala[`Future`]@java[`CompletionStage`]
+  representing a possible reply. @scala[Also known as `ask`.]
 
 Message ordering is guaranteed on a per-sender basis.
 
@@ -651,7 +648,7 @@ remoting. So always prefer `tell` for performance, and only `ask` if you must.
 
 In all these methods you have the option of passing along your own `ActorRef`.
 Make it a practice of doing so because it will allow the receiver actors to be able to respond
-to your message, since the sender reference is sent along with the message.
+to your message since the sender reference is sent along with the message.
 
 @@@
 
@@ -688,7 +685,7 @@ sender, but there can be cases where replies shall be routed to some other
 actor—e.g. the parent—in which the second argument to `tell` would be a
 different one. Outside of an actor and if no reply is needed the second
 argument can be `null`; if a reply is needed outside of an actor you can use
-the ask-pattern described next..
+the ask-pattern described next.
 
 @@@
 
@@ -722,10 +719,10 @@ which it is destroyed in order not to leak resources; see more below.
 @@@ warning
 
 To complete the @scala[`Future`]@java[`CompletionStage`] with an exception you need to send an `akka.actor.Status.Failure` message to the sender.
-This is *not done automatically* when an actor throws an exception while processing a message. 
+This is *not done automatically* when an actor throws an exception while processing a message.
 
 @scala[Please note that Scala's `Try` sub types `scala.util.Failure` and `scala.util.Success` are not treated
-specially, and would complete the ask @scala[`Future`]@java[`CompletionStage`] with the given value - only the `akka.actor.Status` messages
+especially, and would complete the ask @scala[`Future`]@java[`CompletionStage`] with the given value - only the `akka.actor.Status` messages
 are treated specially by the ask pattern.]
 
 @@@
@@ -763,7 +760,7 @@ inside actors you need to carefully avoid closing over
 the containing actor’s reference, i.e. do not call methods or access mutable state
 on the enclosing actor from within the callback. This would break the actor
 encapsulation and may introduce synchronization bugs and race conditions because
-the callback will be scheduled concurrently to the enclosing actor. Unfortunately
+the callback will be scheduled concurrently to the enclosing actor. Unfortunately,
 there is not yet a way to detect these illegal accesses at compile time.
 See also: @ref:[Actors and shared mutable state](general/jmm.md#jmm-shared-state)
 
@@ -825,24 +822,24 @@ trail, you can split the creation of the builder into multiple statements as in
 
 Using small methods is a good practice, also in actors. It's recommended to delegate the
 actual work of the message processing to methods instead of defining a huge `ReceiveBuilder`
-with lots of code in each lambda. A well structured actor can look like this:
+with lots of code in each lambda. A well-structured actor can look like this:
 
 @@snip [ActorDocTest.java](/akka-docs/src/test/java/jdocs/actor/ActorDocTest.java) { #well-structured }
 
 That has benefits such as:
 
- * easier to see what kind of messages the actor can handle
- * readable stack traces in case of exceptions
- * works better with performance profiling tools
- * Java HotSpot has a better opportunity for making optimizations
+* easier to see what kind of messages the actor can handle
+* readable stack traces in case of exceptions
+* works better with performance profiling tools
+* Java HotSpot has a better opportunity for making optimizations
 
-The `Receive` can be implemented in other ways than using the `ReceiveBuilder` since it in the
-end is just a wrapper around a Scala `PartialFunction`. In Java, you can implement `PartialFunction` by
+The `Receive` can be implemented in other ways than using the `ReceiveBuilder` since in the
+end, it is just a wrapper around a Scala `PartialFunction`. In Java, you can implement `PartialFunction` by
 extending `AbstractPartialFunction`. For example, one could implement an adapter
 to [Vavr Pattern Matching DSL](https://www.vavr.io/vavr-docs/#_pattern_matching). See the [Akka Vavr sample project](https://github.com/akka/akka-samples/tree/2.5/akka-sample-vavr) for more details.
 
 If the validation of the `ReceiveBuilder` match logic turns out to be a bottleneck for some of your
-actors you can consider to implement it at lower level by extending `UntypedAbstractActor` instead
+actors you can consider implementing it at a lower level by extending `UntypedAbstractActor` instead
 of `AbstractActor`. The partial functions created by the `ReceiveBuilder` consist of multiple lambda
 expressions for every match statement, where each lambda is referencing the code to be run. This is something
 that the JVM can have problems optimizing and the resulting code might not be as performant as the
@@ -859,7 +856,7 @@ untyped version. When extending `UntypedAbstractActor` each message is received
 If you want to have a handle for replying to a message, you can use
 @scala[`sender()`] @java[`getSender()`], which gives you an ActorRef. You can reply by sending to
 that ActorRef with @scala[`sender() ! replyMsg`.] @java[`getSender().tell(replyMsg, getSelf())`.] You can also store the ActorRef
-for replying later, or passing on to other actors. If there is no sender (a
+for replying later, or passing it on to other actors. If there is no sender (a
 message was sent without an actor or future context) then the sender
 defaults to a 'dead-letter' actor ref.
 
@@ -916,15 +913,15 @@ Each timer has a key and can be replaced or cancelled. It's guaranteed that a me
 previous incarnation of the timer with the same key is not received, even though it might already
 be enqueued in the mailbox when it was cancelled or the new timer was started.
 
-The timers are bound to the lifecycle of the actor that owns it, and thus are cancelled
-automatically when it is restarted or stopped. Note that the `TimerScheduler` is not thread-safe, 
+The timers are bound to the lifecycle of the actor that owns it and thus are cancelled
+automatically when it is restarted or stopped. Note that the `TimerScheduler` is not thread-safe,
 i.e. it must only be used within the actor that owns it.
 
 ## Stopping actors
 
 Actors are stopped by invoking the `stop` method of a `ActorRefFactory`,
 i.e. `ActorContext` or `ActorSystem`. Typically the context is used for stopping
-the actor itself or child actors and the system for stopping top level actors. The actual
+the actor itself or child actors and the system for stopping top-level actors. The actual
 termination of the actor is performed asynchronously, i.e. `stop` may return before
 the actor is stopped.
 
@@ -936,7 +933,7 @@ Java
 
 
 Processing of the current message, if any, will continue before the actor is stopped,
-but additional messages in the mailbox will not be processed. By default these
+but additional messages in the mailbox will not be processed. By default, these
 messages are sent to the `deadLetters` of the `ActorSystem`, but that
 depends on the mailbox implementation.
 
@@ -948,7 +945,7 @@ publishing `Terminated` on the @ref:[DeathWatch](#deathwatch), telling
 its supervisor). This procedure ensures that actor system sub-trees terminate
 in an orderly fashion, propagating the stop command to the leaves and
 collecting their confirmation back to the stopped supervisor. If one of the
-actors does not respond (i.e. processing a message for extended periods of time
+actors do not respond (i.e. processing a message for extended periods of time
 and therefore not receiving the stop command), this whole process will be
 stuck.
 
@@ -992,8 +989,7 @@ Java
 <a id="killing-actors"></a>
 ### Killing an Actor
 
-You can also "kill" an actor by sending a `Kill` message. Unlike `PoisonPill` this will cause 
-the actor to throw a `ActorKilledException`, triggering a failure. The actor will
+You can also "kill" an actor by sending a `Kill` message. Unlike `PoisonPill` this will cause the actor to throw a `ActorKilledException`, triggering a failure. The actor will
 suspend operation and its supervisor will be asked how to handle the failure,
 which may mean resuming the actor, restarting it or terminating it completely.
 See @ref:[What Supervision Means](general/supervision.md#supervision-directives) for more information.
@@ -1006,8 +1002,8 @@ Scala
 Java
 :  @@snip [ActorDocTest.java](/akka-docs/src/test/java/jdocs/actor/ActorDocTest.java) { #kill }
 
-In general though it is not recommended to overly rely on either `PoisonPill` or `Kill` in 
-designing your actor interactions, as often times a protocol-level message like `PleaseCleanupAndStop`
+In general, it is not recommended to overly rely on either `PoisonPill` or `Kill` in
+designing your actor interactions, as often a protocol-level message like `PleaseCleanupAndStop`
 which the actor knows how to handle is encouraged. The messages are there for being able to stop actors
 over which design you do not have control over.
 
@@ -1026,7 +1022,7 @@ When `gracefulStop()` returns successfully, the actor’s `postStop()` hook
 will have been executed: there exists a happens-before edge between the end of
 `postStop()` and the return of `gracefulStop()`.
 
-In the above example a custom `Manager.Shutdown` message is sent to the target
+In the above example, a custom `Manager.Shutdown` message is sent to the target
 actor to initiate the process of stopping the actor. You can use `PoisonPill` for
 this, but then you have limited possibilities to perform interactions with other actors
 before stopping the target actor. Simple cleanup tasks can be handled in `postStop`.
@@ -1034,9 +1030,9 @@ before stopping the target actor. Simple cleanup tasks can be handled in `postSt
 @@@ warning
 
 Keep in mind that an actor stopping and its name being deregistered are
-separate events which happen asynchronously from each other. Therefore it may
+separate events that happen asynchronously from each other. Therefore it may
 be that you will find the name still in use after `gracefulStop()`
-returned. In order to guarantee proper deregistration, only reuse names from
+returned. To guarantee proper deregistration, only reuse names from
 within a supervisor you control and only in response to a `Terminated`
 message, i.e. not for top-level actors.
 
@@ -1050,7 +1046,7 @@ message, i.e. not for top-level actors.
 Akka supports hotswapping the Actor’s message loop (e.g. its implementation) at
 runtime: invoke the `context.become` method from within the Actor.
 `become` takes a @scala[`PartialFunction[Any, Unit]`] @java[`PartialFunction<Object, BoxedUnit>`] that implements the new
-message handler. The hotswapped code is kept in a Stack which can be pushed and
+message handler. The hotswapped code is kept in a Stack that can be pushed and
 popped.
 
 @@@ warning
@@ -1073,7 +1069,7 @@ stack), which means that you do not use `unbecome`, instead always the
 next behavior is explicitly installed.
 
 The other way of using `become` does not replace but add to the top of
-the behavior stack. In this case care must be taken to ensure that the number
+the behavior stack. In this case, care must be taken to ensure that the number
 of “pop” operations (i.e. `unbecome`) matches the number of “push” ones
 in the long run, otherwise this amounts to a memory leak (which is why this
 behavior is not the default).
@@ -1165,11 +1161,9 @@ actor's state which have the same property.
 
 However, the @scala[`Stash` trait’s] @java[`AbstractActorWithStash`]
 implementation of `preRestart` will call `unstashAll()`. This means
-that prior to the actor restarting, it will transfer all stashed 
-messages back to the actor's mailbox.
+that before the actor restarts, it will transfer all stashed messages back to the actor's mailbox.
 
-The result of this is that when an actor is restarted, any stashed 
-messages will be delivered to the new incarnation of the actor. 
+The result of this is that when an actor is restarted, any stashed messages will be delivered to the new incarnation of the actor.
 This is usually the desired behavior.
 
 @@@ note
@@ -1190,7 +1184,7 @@ however you should keep in mind that "first match" wins - which may be important
 
 For example, imagine you have a set of actors which are either `Producers` or `Consumers`, yet sometimes it makes sense to
 have an actor share both behaviors. This can be achieved without having to duplicate code by extracting the behaviors to
-traits and implementing the actor's `receive` as combination of these partial functions.
+traits and implementing the actor's `receive` as a combination of these partial functions.
 
 @@snip [ActorDocSpec.scala](/akka-docs/src/test/scala/docs/actor/ActorDocSpec.scala) { #receive-orElse }
 
@@ -1204,7 +1198,7 @@ The rich lifecycle hooks of Actors provide a useful toolkit to implement various
 lifetime of an `ActorRef`, an actor can potentially go through several restarts, where the old instance is replaced by
 a fresh one, invisibly to the outside observer who only sees the `ActorRef`.
 
-Initialization might be necessary every time an actor is instantiated, 
+Initialization might be necessary every time an actor is instantiated,
 but sometimes one needs initialization to happen only at the birth of the first instance when the
 `ActorRef` is created. The following sections provide patterns for different initialization needs.
 
@@ -1220,7 +1214,7 @@ restarts. The following section provides a pattern for this case.
 ### Initialization via preStart
 
 The method `preStart()` of an actor is only called once directly during the initialization of the first instance, that
-is, at creation of its `ActorRef`. In the case of restarts, `preStart()` is called from `postRestart()`, therefore
+is, at the creation of its `ActorRef`. In the case of restarts, `preStart()` is called from `postRestart()`, therefore
 if not overridden, `preStart()` is called on every restart. However, by overriding `postRestart()` one can disable
 this behavior, and ensure that there is only one call to `preStart()`.
 
@@ -1243,7 +1237,7 @@ For more information see @ref:[What Restarting Means](general/supervision.md#sup
 ### Initialization via message passing
 
 There are cases when it is impossible to pass all the information needed for actor initialization in the constructor,
-for example in the presence of circular dependencies. In this case the actor should listen for an initialization message,
+for example in the presence of circular dependencies. In this case, the actor should listen for an initialization message,
 and use `become()` or a finite state-machine state transition to encode the initialized and uninitialized states
 of the actor.
 
diff --git a/akka-docs/src/main/paradox/cluster-client.md b/akka-docs/src/main/paradox/cluster-client.md
index 42701deebe..99daeeeb1a 100644
--- a/akka-docs/src/main/paradox/cluster-client.md
+++ b/akka-docs/src/main/paradox/cluster-client.md
@@ -14,12 +14,12 @@ It is not advised to build new applications with Cluster Client, and existing us
 To use Cluster Client, you must add the following dependency in your project:
 
 @@dependency[sbt,Maven,Gradle] {
-  bomGroup=com.typesafe.akka bomArtifact=akka-bom_$scala.binary.version$ bomVersionSymbols=AkkaVersion
-  symbol1=AkkaVersion
-  value1="$akka.version$"
-  group=com.typesafe.akka
-  artifact=akka-cluster-tools_$scala.binary.version$
-  version=AkkaVersion
+bomGroup=com.typesafe.akka bomArtifact=akka-bom_$scala.binary.version$ bomVersionSymbols=AkkaVersion
+symbol1=AkkaVersion
+value1="$akka.version$"
+group=com.typesafe.akka
+artifact=akka-cluster-tools_$scala.binary.version$
+version=AkkaVersion
 }
 
 @@project-info{ projectId="akka-cluster-tools" }
@@ -32,29 +32,28 @@ another cluster. It only needs to know the location of one (or more) nodes to us
 contact points. It will establish a connection to a @apidoc[akka.cluster.client.ClusterReceptionist] somewhere in
 the cluster. It will monitor the connection to the receptionist and establish a new
 connection if the link goes down. When looking for a new receptionist it uses fresh
-contact points retrieved from previous establishment, or periodically refreshed contacts,
+contact points retrieved from the previous establishment, or periodically refreshed contacts,
 i.e. not necessarily the initial contact points.
 
 Using the @apidoc[ClusterClient] for communicating with a cluster from the outside requires that the system with the client
-can both connect and be connected to with Akka Remoting from all the nodes in the cluster with a receptionist.
-This creates a tight coupling in that the client and cluster systems may need to have the same version of 
-both Akka, libraries, message classes, serializers and potentially even the JVM. In many cases it is a better solution 
-to use a more explicit and decoupling protocol such as [HTTP](https://doc.akka.io/docs/akka-http/current/index.html) or 
+can both connect and be connected with Akka Remoting from all the nodes in the cluster with a receptionist.
+This creates a tight coupling in that the client and cluster systems may need to have the same version of both Akka, libraries, message classes, serializers and potentially even the JVM. In many cases it is a better solution
+to use a more explicit and decoupling protocol such as [HTTP](https://doc.akka.io/docs/akka-http/current/index.html) or
 [gRPC](https://doc.akka.io/docs/akka-grpc/current/).
 
-Additionally since Akka Remoting is primarily designed as a protocol for Akka Cluster there is no explicit resource
-management, when a @apidoc[ClusterClient] has been used it will cause connections with the cluster until the ActorSystem is 
-stopped (unlike other kinds of network clients). 
+Additionally, since Akka Remoting is primarily designed as a protocol for Akka Cluster there is no explicit resource
+management, when a @apidoc[ClusterClient] has been used it will cause connections with the cluster until the ActorSystem is
+stopped (unlike other kinds of network clients).
 
 @apidoc[ClusterClient] should not be used when sending messages to actors that run
 within the same cluster. Similar functionality as the @apidoc[ClusterClient] is
-provided in a more efficient way by @ref:[Distributed Publish Subscribe in Cluster](distributed-pub-sub.md) for actors that
+provided more efficiently by @ref:[Distributed Publish Subscribe in Cluster](distributed-pub-sub.md) for actors that
 belong to the same cluster.
 
-It is necessary that the connecting system has its `akka.actor.provider` set  to `remote` or `cluster` when using
+The connecting system must have its `akka.actor.provider` set  to `remote` or `cluster` when using
 the cluster client.
 
-The receptionist is supposed to be started on all nodes, or all nodes with specified role,
+The receptionist is supposed to be started on all nodes, or all nodes with a specified role,
 in the cluster. The receptionist can be started with the @apidoc[akka.cluster.client.ClusterReceptionist] extension
 or as an ordinary actor.
 
@@ -65,32 +64,31 @@ should be reachable from the client. Messages are wrapped in `ClusterClient.Send
 @scala[@scaladoc[`ClusterClient.SendToAll`](akka.cluster.client.ClusterClient$)]@java[`ClusterClient.SendToAll`] or @scala[@scaladoc[`ClusterClient.Publish`](akka.cluster.client.ClusterClient$)]@java[`ClusterClient.Publish`].
 
 Both the @apidoc[ClusterClient] and the @apidoc[ClusterClientReceptionist] emit events that can be subscribed to.
-The @apidoc[ClusterClient] sends out notifications in relation to having received a list of contact points
+The @apidoc[ClusterClient] sends out notifications about the list of contact points received
 from the @apidoc[ClusterClientReceptionist]. One use of this list might be for the client to record its
 contact points. A client that is restarted could then use this information to supersede any previously
 configured contact points.
 
 The @apidoc[ClusterClientReceptionist] sends out notifications in relation to having received a contact
 from a @apidoc[ClusterClient]. This notification enables the server containing the receptionist to become aware of
-what clients are connected.
+what clients are connected to.
 
 1. **ClusterClient.Send**
 
-    The message will be delivered to one recipient with a matching path, if any such
-    exists. If several entries match the path the message will be delivered
-    to one random destination. The sender of the message can specify that local
-    affinity is preferred, i.e. the message is sent to an actor in the same local actor
-    system as the used receptionist actor, if any such exists, otherwise random to any other
-    matching entry.
+   The message will be delivered to one recipient with a matching path if any such exists. If several entries match the path the message will be delivered
+   to one random destination. The sender of the message can specify that local
+   affinity is preferred, i.e. the message is sent to an actor in the same local actor
+   system as the used receptionist actor, if any such exists, otherwise random to any other
+   matching entry.
 
 2. **ClusterClient.SendToAll**
 
-    The message will be delivered to all recipients with a matching path.
+   The message will be delivered to all recipients with a matching path.
 
 3. **ClusterClient.Publish**
 
-    The message will be delivered to all recipients Actors that have been registered as subscribers
-    to the named topic.
+   The message will be delivered to all recipients Actors that have been registered as subscribers
+   to the named topic.
 
 Response messages from the destination actor are tunneled via the receptionist
 to avoid inbound connections from other cluster nodes to the client:
@@ -99,7 +97,7 @@ to avoid inbound connections from other cluster nodes to the client:
   but the receptionist
 * @scala[@scaladoc[`sender()`](akka.actor.Actor)] @java[@javadoc[`getSender()`](akka.actor.Actor)] of the response messages, sent back from the destination and seen by the client,
   is `deadLetters`
-  
+
 since the client should normally send subsequent messages via the @apidoc[ClusterClient].
 It is possible to pass the original sender inside the reply messages if
 the client is supposed to communicate directly to the actor in the cluster.
@@ -115,7 +113,7 @@ of these actors. As always, additional logic should be implemented in the destin
 
 ## An Example
 
-On the cluster nodes first start the receptionist. Note, it is recommended to load the extension
+On the cluster nodes, first start the receptionist. Note, it is recommended to load the extension
 when the actor system is started by defining it in the `akka.extensions` configuration property:
 
 ```
@@ -130,7 +128,7 @@ Scala
 Java
 :  @@snip [ClusterClientTest.java](/akka-cluster-tools/src/test/java/akka/cluster/client/ClusterClientTest.java) { #server }
 
-On the client you create the @apidoc[ClusterClient] actor and use it as a gateway for sending
+On the client, you create the @apidoc[ClusterClient] actor and use it as a gateway for sending
 messages to the actors identified by their path (without address information) somewhere
 in the cluster.
 
@@ -214,9 +212,9 @@ with different settings if needed.
 When the cluster client is started it must be provided with a list of initial contacts which are cluster
 nodes where receptionists are running. It will then repeatedly (with an interval configurable
 by `establishing-get-contacts-interval`) try to contact those until it gets in contact with one of them.
-While running, the list of contacts are continuously updated with data from the receptionists (again, with an
+While running, the list of contacts is continuously updated with data from the receptionists (again, with an
 interval configurable with `refresh-contacts-interval`), so that if there are more receptionists in the cluster
-than the initial contacts provided to the client the client will learn about them.
+than the initial contacts provided to the client will learn about them.
 
 While the client is running it will detect failures in its connection to the receptionist by heartbeats
 if more than a configurable amount of heartbeats are missed the client will try to reconnect to its known
@@ -234,7 +232,7 @@ contacts can be fetched and a new cluster client started.
 ## Migration to Akka gRPC
 
 Cluster Client is deprecated and it is not advised to build new applications with it.
-As a replacement we recommend using [Akka gRPC](https://doc.akka.io/docs/akka-grpc/current/)
+As a replacement, we recommend using [Akka gRPC](https://doc.akka.io/docs/akka-grpc/current/)
 with an application-specific protocol. The benefits of this approach are:
 
 * Improved security by using TLS for gRPC (HTTP/2) versus exposing Akka Remoting outside the Akka Cluster
@@ -262,13 +260,13 @@ It will not be provided as a published artifact.
 * [akka-samples/akka-sample-cluster-cluster-client-grpc-scala](https://github.com/akka/akka-samples/tree/2.6/akka-sample-cluster-client-grpc-scala) implemented in Scala
 * [akka-samples/akka-sample-cluster-cluster-client-grpc-java](https://github.com/akka/akka-samples/tree/2.6/akka-sample-cluster-client-grpc-java) implemented in Java
 
-The example is still using an actor on the client side to have an API that is very close
+The example is still using an actor on the client-side to have an API that is very close
 to the original Cluster Client. The messages this actor can handle correspond to the
-@ref:[Distributed Pub Sub](distributed-pub-sub.md) messages on the server side, such as
+@ref:[Distributed Pub Sub](distributed-pub-sub.md) messages on the server-side, such as
 `ClusterClient.Send` and `ClusterClient.Publish`.
 
 The `ClusterClient` actor delegates those messages to the gRPC client, and on the
-server side those are translated and delegated to the destination actors that
+server-side those are translated and delegated to the destination actors that
 are registered via the `ClusterClientReceptionist` in the same way as in the original.
 
 Akka gRPC is used as the transport for the messages between client and server, instead of Akka Remoting.
@@ -276,7 +274,7 @@ Akka gRPC is used as the transport for the messages between client and server, i
 The application specific messages are wrapped and serialized with Akka Serialization,
 which means that care must be taken to keep wire compatibility when changing any messages used
 between the client and server. The Akka configuration of Akka serializers must be the same (or
-being compatible) on client and server.
+being compatible) on the client and the server.
 
 #### Next steps