=doc Fixed and normalized spellings

akka-docs/rst/common/cluster.rst

@@ -54,7 +54,7 @@ actor system instance at that ``hostname:port``. Akka uses the UID to be able to
 reliably trigger remote death watch. This means that the same actor system can never
 join a cluster again once it's been removed from that cluster. To re-join an actor
 system with the same ``hostname:port`` to a cluster you have to stop the actor system
-and start a new one with the same ``hotname:port`` which will then receive a different
+and start a new one with the same ``hostname:port`` which will then receive a different
 UID.
 
 The cluster membership state is a specialized `CRDT`_, which means that it has a monotonic
@@ -345,7 +345,7 @@ Failure Detection and Unreachability
 - unreachable*
     unreachable is not a real member states but more of a flag in addition
     to the state signaling that the cluster is unable to talk to this node,
-    after beeing unreachable the failure detector may detect it as reachable
+    after being unreachable the failure detector may detect it as reachable
     again and thereby remove the flag
 
 

akka-docs/rst/dev/multi-node-testing.rst

@@ -33,7 +33,7 @@ This is a schematic overview of the test conductor.
 
 The test conductor server is responsible for coordinating barriers and sending commands to the test conductor
 clients that act upon them, e.g. throttling network traffic to/from another client. More information on the
-possible operations is availible in the ``akka.remote.testconductor.Conductor`` API documentation.
+possible operations is available in the ``akka.remote.testconductor.Conductor`` API documentation.
 
 The Multi Node Spec
 ===================

akka-docs/rst/general/message-delivery-reliability.rst

@@ -227,7 +227,7 @@ observer.
 Ordering of Local Message Sends
 -------------------------------
 
-Assuming strict FIFO mailboxes the abovementioned caveat of non-transitivity of
+Assuming strict FIFO mailboxes the aforementioned caveat of non-transitivity of
 the message ordering guarantee is eliminated under certain conditions. As you
 will note, these are quite subtle as it stands, and it is even possible that
 future performance optimizations will invalidate this whole paragraph. The

akka-docs/rst/java/cluster-metrics.rst

@@ -61,7 +61,7 @@ Metrics extension periodically publishes current snapshot of the cluster metrics
 
 The publication period is controlled by the ``akka.cluster.metrics.collector.sample-period`` setting.
 
-The payload of the ``akka.cluster.metris.ClusterMetricsChanged`` event will contain
+The payload of the ``akka.cluster.metrics.ClusterMetricsChanged`` event will contain
 latest metrics of the node as well as other cluster member nodes metrics gossip
 which was received during the collector sample period.
 

akka-docs/rst/java/cluster-usage.rst

@@ -88,7 +88,7 @@ seed nodes in the existing cluster.
 If you don't configure seed nodes you need to join the cluster programmatically or manually.
 
 Manual joining can be performed by using ref:`cluster_jmx_java` or :ref:`cluster_command_line_java`.
-Joining programatically can be performed with ``Cluster.get(system).join``. Unsuccessful join attempts are 
+Joining programmatically can be performed with ``Cluster.get(system).join``. Unsuccessful join attempts are
 automatically retried after the time period defined in configuration property ``retry-unsuccessful-join-after``.
 Retries can be disabled by setting the property to ``off``.
 
@@ -127,7 +127,7 @@ status of the unreachable member must be changed to 'Down'. Changing status to '
 can be performed automatically or manually. By default it must be done manually, using 
 :ref:`cluster_jmx_java` or :ref:`cluster_command_line_java`.
 
-It can also be performed programatically with ``Cluster.get(system).down(address)``.
+It can also be performed programmatically with ``Cluster.get(system).down(address)``.
 
 You can enable automatic downing with configuration::
 
@@ -157,7 +157,7 @@ above.
 
 A more graceful exit can be performed if you tell the cluster that a node shall leave.
 This can be performed using :ref:`cluster_jmx_java` or :ref:`cluster_command_line_java`.
-It can also be performed programatically with ``Cluster.get(system).leave(address)``. 
+It can also be performed programmatically with ``Cluster.get(system).leave(address)``.
 
 Note that this command can be issued to any member in the cluster, not necessarily the
 one that is leaving. The cluster extension, but not the actor system or JVM, of the 

akka-docs/rst/java/event-bus.rst

@@ -115,7 +115,7 @@ type :class:`ActorRef`.
 
 This classification requires an :class:`ActorSystem` in order to perform book-keeping
 operations related to the subscribers being Actors, which can terminate without first
-unsubscribing from the EventBus. ManagedActorClassification maitains a system Actor which
+unsubscribing from the EventBus. ManagedActorClassification maintains a system Actor which
 takes care of unsubscribing terminated actors automatically.
 
 The necessary methods to be implemented are illustrated with the following example:
@@ -148,7 +148,7 @@ it can be subscribed like this:
 
 .. includecode:: code/docs/event/LoggingDocTest.java#deadletters
 
-Similarily to `Actor Classification`_, :class:`EventStream` will automatically remove subscibers when they terminate.
+Similarly to `Actor Classification`_, :class:`EventStream` will automatically remove subscribers when they terminate.
 
 .. note::
    The event stream is a *local facility*, meaning that it will *not* distribute events to other nodes in a clustered environment (unless you subscribe a Remote Actor to the stream explicitly).

akka-docs/rst/java/fault-tolerance.rst

@@ -107,7 +107,7 @@ Test Application
 ----------------
 
 The following section shows the effects of the different directives in practice,
-wherefor a test setup is needed. First off, we need a suitable supervisor:
+where a test setup is needed. First off, we need a suitable supervisor:
 
 .. includecode:: code/docs/actor/FaultHandlingTest.java
    :include: supervisor

akka-docs/rst/java/io-tcp.rst

@@ -67,7 +67,7 @@ to listen for TCP connections on a particular :class:`InetSocketAddress`; the
 port may be specified as ``0`` in order to bind to a random port.
 
 The actor sending the :class:`Bind` message will receive a :class:`Bound`
-message signalling that the server is ready to accept incoming connections;
+message signaling that the server is ready to accept incoming connections;
 this message also contains the :class:`InetSocketAddress` to which the socket
 was actually bound (i.e. resolved IP address and correct port number). 
 

akka-docs/rst/java/lambda-actors.rst

@@ -90,7 +90,7 @@ explained below.
 The last line shows a possibility to pass constructor arguments regardless of
 the context it is being used in. The presence of a matching constructor is
 verified during construction of the :class:`Props` object, resulting in an
-:class:`IllegalArgumentEception` if no or multiple matching constructors are
+:class:`IllegalArgumentException` if no or multiple matching constructors are
 found.
 
 Dangerous Variants

akka-docs/rst/java/lambda-fault-tolerance.rst

@@ -107,7 +107,7 @@ Test Application
 ----------------
 
 The following section shows the effects of the different directives in practice,
-wherefor a test setup is needed. First off, we need a suitable supervisor:
+where a test setup is needed. First off, we need a suitable supervisor:
 
 .. includecode:: code/docs/actorlambda/FaultHandlingTest.java
    :include: supervisor

akka-docs/rst/java/lambda-persistence.rst

@@ -184,7 +184,7 @@ In this case, a persistent actor must be recovered explicitly by sending it a ``
 
 .. warning::
 
-  If ``preStart`` is overriden by an empty implementation, incoming commands will not be processed by the
+  If ``preStart`` is overridden by an empty implementation, incoming commands will not be processed by the
   ``PersistentActor`` until it receives a ``Recover`` and finishes recovery.
 
 In order to completely skip recovery, you can signal it with ``Recover.create(0L)``
@@ -253,7 +253,7 @@ Deferring actions until preceding persist handlers have executed
 
 Sometimes when working with ``persistAsync`` you may find that it would be nice to define some actions in terms of
 ''happens-after the previous ``persistAsync`` handlers have been invoked''. ``PersistentActor`` provides an utility method
-called ``defer``, which works similarily to ``persistAsync`` yet does not persist the passed in event. It is recommended to
+called ``defer``, which works similarly to ``persistAsync`` yet does not persist the passed in event. It is recommended to
 use it for *read* operations, and actions which do not have corresponding events in your domain model.
 
 Using this method is very similar to the persist family of methods, yet it does **not** persist the passed in event.
@@ -452,7 +452,7 @@ destinations the destinations will see gaps in the sequence. It is not possible
 However, you can send a custom correlation identifier in the message to the destination. You must then retain 
 a mapping between the internal ``deliveryId`` (passed into the ``deliveryIdToMessage`` function) and your custom 
 correlation id (passed into the message). You can do this by storing such mapping in a ``Map(correlationId -> deliveryId)`` 
-from which you can retrive the ``deliveryId`` to be passed into the ``confirmDelivery`` method once the receiver 
+from which you can retrieve the ``deliveryId`` to be passed into the ``confirmDelivery`` method once the receiver
 of your message has replied with your custom correlation id.
 
 The ``AbstractPersistentActorWithAtLeastOnceDelivery`` class has a state consisting of unconfirmed messages and a
@@ -499,12 +499,12 @@ Plugins can be selected either by "default", for all persistent actors and views
 or "individually", when persistent actor or view defines it's own set of plugins.
 
 When persistent actor or view does NOT override ``journalPluginId`` and ``snapshotPluginId`` methods,
-persistense extension will use "default" journal and snapshot-store plugins configured in the ``reference.conf``::
+persistence extension will use "default" journal and snapshot-store plugins configured in the ``reference.conf``::
 
     akka.persistence.journal.plugin = ""
     akka.persistence.snapshot-store.plugin = ""
 
-However, these entires are provided as empty "", and require explicit user configuration via override in the user ``application.conf``.
+However, these entries are provided as empty "", and require explicit user configuration via override in the user ``application.conf``.
 For an example of journal plugin which writes messages to LevelDB see :ref:`local-leveldb-journal-java-lambda`. 
 For an example of snapshot store plugin which writes snapshots as individual files to the local filesystem see :ref:`local-snapshot-store-java-lambda`. 
 
@@ -663,6 +663,6 @@ the actor or view will be serviced by these specific persistence plugins instead
 .. includecode:: ../java/code/docs/persistence/PersistenceMultiDocTest.java#override-plugins
 
 Note that ``journalPluginId`` and ``snapshotPluginId`` must refer to properly configured ``reference.conf``
-plugin entires with standard ``class`` property as well as settings which are specific for those plugins, i.e.: 
+plugin entries with standard ``class`` property as well as settings which are specific for those plugins, i.e.:
 
 .. includecode:: ../scala/code/docs/persistence/PersistenceMultiDocSpec.scala#override-config

akka-docs/rst/java/persistence.rst

@@ -186,7 +186,7 @@ In this case, a persistent actor must be recovered explicitly by sending it a ``
 
 .. warning::
 
-  If ``preStart`` is overriden by an empty implementation, incoming commands will not be processed by the
+  If ``preStart`` is overridden by an empty implementation, incoming commands will not be processed by the
   ``PersistentActor`` until it receives a ``Recover`` and finishes recovery.
 
 In order to completely skip recovery, you can signal it with ``Recover.create(0L)``
@@ -256,7 +256,7 @@ Deferring actions until preceding persist handlers have executed
 
 Sometimes when working with ``persistAsync`` you may find that it would be nice to define some actions in terms of
 ''happens-after the previous ``persistAsync`` handlers have been invoked''. ``PersistentActor`` provides an utility method
-called ``defer``, which works similarily to ``persistAsync`` yet does not persist the passed in event. It is recommended to
+called ``defer``, which works similarly to ``persistAsync`` yet does not persist the passed in event. It is recommended to
 use it for *read* operations, and actions which do not have corresponding events in your domain model.
 
 Using this method is very similar to the persist family of methods, yet it does **not** persist the passed in event.
@@ -456,7 +456,7 @@ destinations the destinations will see gaps in the sequence. It is not possible
 However, you can send a custom correlation identifier in the message to the destination. You must then retain 
 a mapping between the internal ``deliveryId`` (passed into the ``deliveryIdToMessage`` function) and your custom 
 correlation id (passed into the message). You can do this by storing such mapping in a ``Map(correlationId -> deliveryId)`` 
-from which you can retrive the ``deliveryId`` to be passed into the ``confirmDelivery`` method once the receiver 
+from which you can retrieve the ``deliveryId`` to be passed into the ``confirmDelivery`` method once the receiver
 of your message has replied with your custom correlation id.
 
 The ``UntypedPersistentActorWithAtLeastOnceDelivery`` class has a state consisting of unconfirmed messages and a
@@ -510,12 +510,12 @@ Plugins can be selected either by "default", for all persistent actors and views
 or "individually", when persistent actor or view defines it's own set of plugins.
 
 When persistent actor or view does NOT override ``journalPluginId`` and ``snapshotPluginId`` methods,
-persistense extension will use "default" journal and snapshot-store plugins configured in the ``reference.conf``::
+persistence extension will use "default" journal and snapshot-store plugins configured in the ``reference.conf``::
 
     akka.persistence.journal.plugin = ""
     akka.persistence.snapshot-store.plugin = ""
 
-However, these entires are provided as empty "", and require explicit user configuration via override in the user ``application.conf``.
+However, these entries are provided as empty "", and require explicit user configuration via override in the user ``application.conf``.
 For an example of journal plugin which writes messages to LevelDB see :ref:`local-leveldb-journal-java`. 
 For an example of snapshot store plugin which writes snapshots as individual files to the local filesystem see :ref:`local-snapshot-store-java`. 
 
@@ -714,6 +714,6 @@ the actor or view will be serviced by these specific persistence plugins instead
 .. includecode:: ../java/code/docs/persistence/PersistenceMultiDocTest.java#override-plugins
 
 Note that ``journalPluginId`` and ``snapshotPluginId`` must refer to properly configured ``reference.conf``
-plugin entires with standard ``class`` property as well as settings which are specific for those plugins, i.e.: 
+plugin entries with standard ``class`` property as well as settings which are specific for those plugins, i.e.:
 
 .. includecode:: ../scala/code/docs/persistence/PersistenceMultiDocSpec.scala#override-config

akka-docs/rst/java/remoting.rst

@@ -444,7 +444,7 @@ SSL can be used as the remote transport by adding ``akka.remote.netty.ssl``
 to the ``enabled-transport`` configuration section. See a description of the settings
 in the :ref:`remote-configuration-java` section.
 
-The SSL support is implemented with Java Secure Socket Extension, please consult the offical
+The SSL support is implemented with Java Secure Socket Extension, please consult the official
 `Java Secure Socket Extension documentation <http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html>`_
 and related resources for troubleshooting.
 

akka-docs/rst/java/routing.rst

@@ -652,7 +652,7 @@ Start with the routing logic:
 
 ``select`` will be called for each message and in this example pick a few destinations by round-robin,
 by reusing the existing ``RoundRobinRoutingLogic`` and wrap the result in a ``SeveralRoutees``
-instance.  ``SeveralRoutees`` will send the message to all of the supplied routues.
+instance.  ``SeveralRoutees`` will send the message to all of the supplied routes.
 
 The implementation of the routing logic must be thread safe, since it might be used outside of actors.
 

akka-docs/rst/java/untyped-actors.rst

@@ -54,7 +54,7 @@ dispatcher to use, see more below). Here are some examples of how to create a
 The second line shows how to pass constructor arguments to the :class:`Actor`
 being created. The presence of a matching constructor is verified during
 construction of the :class:`Props` object, resulting in an
-:class:`IllegalArgumentEception` if no or multiple matching constructors are
+:class:`IllegalArgumentException` if no or multiple matching constructors are
 found.
 
 The third line demonstrates the use of a :class:`Creator<T extends Actor>`. The

akka-docs/rst/project/migration-guide-2.3.x-2.4.x.rst

@@ -67,7 +67,7 @@ If you have been creating EventStreams manually, you now have to provide an acto
 
 .. includecode:: ../../../akka-actor-tests/src/test/scala/akka/event/EventStreamSpec.scala#event-bus-start-unsubscriber-scala
 
-Please note that this change affects you only if you have implemented your own busses, Akka's own ``context.eventStream``
+Please note that this change affects you only if you have implemented your own buses, Akka's own ``context.eventStream``
 is still there and does not require any attention from you concerning this change.
 
 FSM notifies on same state transitions
@@ -169,7 +169,7 @@ and ``AbstractPersistentId``.
 The rationale behind this change being stricter de-coupling of your Actor hierarchy and the logical
 "which persistent entity this actor represents".
 
-In case you want to perserve the old behavior of providing the actor's path as the default ``persistenceId``, you can easily
+In case you want to preserve the old behavior of providing the actor's path as the default ``persistenceId``, you can easily
 implement it yourself either as a helper trait or simply by overriding ``persistenceId`` as follows::
 
     override def persistenceId = self.path.toStringWithoutAddress

akka-docs/rst/project/migration-guide-persistence-experimental-2.3.x-2.4.x.rst

@@ -39,11 +39,11 @@ This concept remains the same in Akka ``2.3.4``, yet we rename ``processorId`` t
 and persistent messages can be used from different classes not only ``PersistentActor`` (Views, directly from Journals etc).
 
 Please note that ``persistenceId`` is **abstract** in the new API classes (``PersistentActor`` and ``PersistentView``),
-and we do **not** provide a default (actor-path derrived) value for it like we did for ``processorId``.
+and we do **not** provide a default (actor-path derived) value for it like we did for ``processorId``.
 The rationale behind this change being stricter de-coupling of your Actor hierarchy and the logical "which persistent entity this actor represents".
 A longer discussion on this subject can be found on `issue #15436 <https://github.com/akka/akka/issues/15436>`_ on github.
 
-In case you want to perserve the old behavior of providing the actor's path as the default ``persistenceId``, you can easily
+In case you want to preserve the old behavior of providing the actor's path as the default ``persistenceId``, you can easily
 implement it yourself either as a helper trait or simply by overriding ``persistenceId`` as follows::
 
     override def persistenceId = self.path.toStringWithoutAddress
@@ -57,9 +57,9 @@ Removed Processor in favour of extending PersistentActor with persistAsync
 The ``Processor`` is now deprecated since ``2.3.4`` and will be removed in ``2.4.x``.
 It's semantics replicated in ``PersistentActor`` in the form of an additional ``persist`` method: ``persistAsync``.
 
-In essence, the difference betwen ``persist`` and ``persistAsync`` is that the former will stash all incomming commands
+In essence, the difference between ``persist`` and ``persistAsync`` is that the former will stash all incoming commands
 until all persist callbacks have been processed, whereas the latter does not stash any commands. The new ``persistAsync``
-should be used in cases of low consistency yet high responsiveness requirements, the Actor can keep processing incomming
+should be used in cases of low consistency yet high responsiveness requirements, the Actor can keep processing incoming
 commands, even though not all previous events have been handled.
 
 When these ``persist`` and ``persistAsync`` are used together in the same ``PersistentActor``, the ``persist``
@@ -126,7 +126,7 @@ should always be valid for replay.
 Renamed View to PersistentView, which receives plain messages (Persistent() wrapper is gone)
 ============================================================================================
 Views used to receive messages wrapped as ``Persistent(payload, seqNr)``, this is no longer the case and views receive
-the ``payload`` as message from the ``Journal`` directly. The rationale here is that the wrapper aproach was inconsistent
+the ``payload`` as message from the ``Journal`` directly. The rationale here is that the wrapper approach was inconsistent
 with the other Akka Persistence APIs and also is not easily "discoverable" (you have to *know* you will be getting this Persistent wrapper).
 
 Instead, since ``2.3.4``, views get plain messages, and can use additional methods provided by the ``View`` to identify if a message

akka-docs/rst/scala/actors.rst

@@ -78,7 +78,7 @@ explained below.
 The last line shows a possibility to pass constructor arguments regardless of
 the context it is being used in. The presence of a matching constructor is
 verified during construction of the :class:`Props` object, resulting in an
-:class:`IllegalArgumentEception` if no or multiple matching constructors are
+:class:`IllegalArgumentException` if no or multiple matching constructors are
 found.
 
 Dangerous Variants

akka-docs/rst/scala/cluster-metrics.rst

@@ -57,7 +57,7 @@ Metrics extension periodically publishes current snapshot of the cluster metrics
 
 The publication period is controlled by the ``akka.cluster.metrics.collector.sample-period`` setting.
 
-The payload of the ``akka.cluster.metris.ClusterMetricsChanged`` event will contain
+The payload of the ``akka.cluster.metrics.ClusterMetricsChanged`` event will contain
 latest metrics of the node as well as other cluster member nodes metrics gossip
 which was received during the collector sample period.
 

akka-docs/rst/scala/cluster-sharding.rst

@@ -58,13 +58,13 @@ if needed.
 
 A shard is a group of entries that will be managed together. The grouping is defined by the
 ``shardResolver`` function shown above. For a specific entry identifier the shard identifier must always 
-be the same. Otherwise the entry actor might accidentily be started in several places at the same time.
+be the same. Otherwise the entry actor might accidentally be started in several places at the same time.
 
 Creating a good sharding algorithm is an interesting challenge in itself. Try to produce a uniform distribution, 
 i.e. same amount of entries in each shard. As a rule of thumb, the number of shards should be a factor ten greater 
 than the planned maximum number of cluster nodes. Less shards than number of nodes will result in that some nodes 
 will not host any shards. Too many shards will result in less efficient management of the shards, e.g. rebalancing
-overhead, and increased latency because the corrdinator is involved in the routing of the first message for each
+overhead, and increased latency because the coordinator is involved in the routing of the first message for each
 shard. The sharding algorithm must be the same on all nodes in a running cluster. It can be changed after stopping
 all nodes in the cluster.
 
@@ -121,7 +121,7 @@ Creating a good sharding algorithm is an interesting challenge in itself. Try to
 i.e. same amount of entries in each shard. As a rule of thumb, the number of shards should be a factor ten greater 
 than the planned maximum number of cluster nodes. Less shards than number of nodes will result in that some nodes 
 will not host any shards. Too many shards will result in less efficient management of the shards, e.g. rebalancing
-overhead, and increased latency because the corrdinator is involved in the routing of the first message for each
+overhead, and increased latency because the coordinator is involved in the routing of the first message for each
 shard. The sharding algorithm must be the same on all nodes in a running cluster. It can be changed after stopping
 all nodes in the cluster.
 

akka-docs/rst/scala/cluster-singleton.rst

@@ -88,7 +88,7 @@ In Scala:
 Here we limit the singleton to nodes tagged with the ``"worker"`` role, but all nodes, independent of
 role, can be used by specifying ``None`` as ``role`` parameter.
 
-The corresponding Java API for the ``singeltonProps`` function is ``akka.cluster.singleton.ClusterSingletonPropsFactory``.
+The corresponding Java API for the ``singletonProps`` function is ``akka.cluster.singleton.ClusterSingletonPropsFactory``.
 The Java API takes a plain String for the role parameter and ``null`` means that all nodes, independent of
 role, are used.
 

akka-docs/rst/scala/cluster-usage.rst

@@ -82,7 +82,7 @@ seed nodes in the existing cluster.
 If you don't configure seed nodes you need to join the cluster programmatically or manually.
 
 Manual joining can be performed by using ref:`cluster_jmx_scala` or :ref:`cluster_command_line_scala`.
-Joining programatically can be performed with ``Cluster(system).join``. Unsuccessful join attempts are 
+Joining programmatically can be performed with ``Cluster(system).join``. Unsuccessful join attempts are
 automatically retried after the time period defined in configuration property ``retry-unsuccessful-join-after``.
 Retries can be disabled by setting the property to ``off``.
 
@@ -121,7 +121,7 @@ status of the unreachable member must be changed to 'Down'. Changing status to '
 can be performed automatically or manually. By default it must be done manually, using
 :ref:`cluster_jmx_scala` or :ref:`cluster_command_line_scala`.
 
-It can also be performed programatically with ``Cluster(system).down(address)``.
+It can also be performed programmatically with ``Cluster(system).down(address)``.
 
 You can enable automatic downing with configuration::
 
@@ -151,7 +151,7 @@ above.
 
 A more graceful exit can be performed if you tell the cluster that a node shall leave.
 This can be performed using :ref:`cluster_jmx_scala` or :ref:`cluster_command_line_scala`.
-It can also be performed programatically with ``Cluster(system).leave(address)``. 
+It can also be performed programmatically with ``Cluster(system).leave(address)``.
 
 Note that this command can be issued to any member in the cluster, not necessarily the
 one that is leaving. The cluster extension, but not the actor system or JVM, of the 
@@ -598,7 +598,7 @@ of code should only run for a specific role.
 .. includecode:: ../../../akka-samples/akka-sample-cluster-scala/src/multi-jvm/scala/sample/cluster/stats/StatsSampleSpec.scala#test-statsService
 
 Once again we take advantage of the facilities in :ref:`testkit <akka-testkit>` to verify expected behavior.
-Here using ``testActor`` as sender (via ``ImplicitSender``) and verifing the reply with ``expectMsgPF``.
+Here using ``testActor`` as sender (via ``ImplicitSender``) and verifying the reply with ``expectMsgPF``.
 
 In the above code you can see ``node(third)``, which is useful facility to get the root actor reference of
 the actor system for a specific role. This can also be used to grab the ``akka.actor.Address`` of that node.

akka-docs/rst/scala/event-bus.rst

@@ -115,7 +115,7 @@ type :class:`ActorRef`.
 
 This classification requires an :class:`ActorSystem` in order to perform book-keeping
 operations related to the subscribers being Actors, which can terminate without first
-unsubscribing from the EventBus. ManagedActorClassification maitains a system Actor which
+unsubscribing from the EventBus. ManagedActorClassification maintains a system Actor which
 takes care of unsubscribing terminated actors automatically.
 
 The necessary methods to be implemented are illustrated with the following example:
@@ -143,7 +143,7 @@ how a simple subscription works:
 
 .. includecode:: code/docs/event/LoggingDocSpec.scala#deadletters
 
-Similarily to `Actor Classification`_, :class:`EventStream` will automatically remove subscibers when they terminate.
+Similarly to `Actor Classification`_, :class:`EventStream` will automatically remove subscribers when they terminate.
 
 .. note::
    The event stream is a *local facility*, meaning that it will *not* distribute events to other nodes in a clustered environment (unless you subscribe a Remote Actor to the stream explicitly).

akka-docs/rst/scala/fault-tolerance.rst

@@ -116,7 +116,7 @@ Test Application
 ----------------
 
 The following section shows the effects of the different directives in practice,
-wherefor a test setup is needed. First off, we need a suitable supervisor:
+where a test setup is needed. First off, we need a suitable supervisor:
 
 .. includecode:: code/docs/actor/FaultHandlingDocSpec.scala
    :include: supervisor

akka-docs/rst/scala/io-tcp.rst

@@ -68,7 +68,7 @@ to listen for TCP connections on a particular :class:`InetSocketAddress`; the
 port may be specified as ``0`` in order to bind to a random port.
 
 The actor sending the :class:`Bind` message will receive a :class:`Bound`
-message signalling that the server is ready to accept incoming connections;
+message signaling that the server is ready to accept incoming connections;
 this message also contains the :class:`InetSocketAddress` to which the socket
 was actually bound (i.e. resolved IP address and correct port number). 
 

akka-docs/rst/scala/persistence.rst

@@ -170,7 +170,7 @@ In this case, a persistent actor must be recovered explicitly by sending it a ``
 
 .. warning::
 
-  If ``preStart`` is overriden by an empty implementation, incoming commands will not be processed by the
+  If ``preStart`` is overridden by an empty implementation, incoming commands will not be processed by the
   ``PersistentActor`` until it receives a ``Recover`` and finishes recovery.
 
 In order to completely skip recovery, you can signal it with ``Recover(toSequenceNr = OL)``
@@ -226,7 +226,7 @@ The ordering between events is still guaranteed ("evt-b-1" will be sent after "e
 .. includecode:: code/docs/persistence/PersistenceDocSpec.scala#persist-async
 
 .. note::
-  In order to implement the pattern known as "*command sourcing*" simply call ``persistAsync(cmd)(...)`` right away on all incomming
+  In order to implement the pattern known as "*command sourcing*" simply call ``persistAsync(cmd)(...)`` right away on all incoming
   messages, and handle them in the callback.
   
 .. warning::
@@ -240,7 +240,7 @@ Deferring actions until preceding persist handlers have executed
 
 Sometimes when working with ``persistAsync`` you may find that it would be nice to define some actions in terms of
 ''happens-after the previous ``persistAsync`` handlers have been invoked''. ``PersistentActor`` provides an utility method
-called ``defer``, which works similarily to ``persistAsync`` yet does not persist the passed in event. It is recommended to
+called ``defer``, which works similarly to ``persistAsync`` yet does not persist the passed in event. It is recommended to
 use it for *read* operations, and actions which do not have corresponding events in your domain model.
 
 Using this method is very similar to the persist family of methods, yet it does **not** persist the passed in event.
@@ -447,7 +447,7 @@ destinations the destinations will see gaps in the sequence. It is not possible
 However, you can send a custom correlation identifier in the message to the destination. You must then retain 
 a mapping between the internal ``deliveryId`` (passed into the ``deliveryIdToMessage`` function) and your custom 
 correlation id (passed into the message). You can do this by storing such mapping in a ``Map(correlationId -> deliveryId)`` 
-from which you can retrive the ``deliveryId`` to be passed into the ``confirmDelivery`` method once the receiver 
+from which you can retrieve the ``deliveryId`` to be passed into the ``confirmDelivery`` method once the receiver
 of your message has replied with your custom correlation id.
 
 The ``AtLeastOnceDelivery`` trait has a state consisting of unconfirmed messages and a
@@ -503,12 +503,12 @@ Plugins can be selected either by "default", for all persistent actors and views
 or "individually", when persistent actor or view defines it's own set of plugins.
 
 When persistent actor or view does NOT override ``journalPluginId`` and ``snapshotPluginId`` methods,
-persistense extension will use "default" journal and snapshot-store plugins configured in the ``reference.conf``::
+persistence extension will use "default" journal and snapshot-store plugins configured in the ``reference.conf``::
 
     akka.persistence.journal.plugin = ""
     akka.persistence.snapshot-store.plugin = ""
 
-However, these entires are provided as empty "", and require explicit user configuration via override in the user ``application.conf``.
+However, these entries are provided as empty "", and require explicit user configuration via override in the user ``application.conf``.
 For an example of journal plugin which writes messages to LevelDB see :ref:`local-leveldb-journal`. 
 For an example of snapshot store plugin which writes snapshots as individual files to the local filesystem see :ref:`local-snapshot-store`. 
 
@@ -709,6 +709,6 @@ the actor or view will be serviced by these specific persistence plugins instead
 .. includecode:: code/docs/persistence/PersistenceMultiDocSpec.scala#override-plugins
 
 Note that ``journalPluginId`` and ``snapshotPluginId`` must refer to properly configured ``reference.conf``
-plugin entires with standard ``class`` property as well as settings which are specific for those plugins, i.e.: 
+plugin entries with standard ``class`` property as well as settings which are specific for those plugins, i.e.:
 
 .. includecode:: code/docs/persistence/PersistenceMultiDocSpec.scala#override-config

akka-docs/rst/scala/remoting.rst

@@ -448,7 +448,7 @@ SSL can be used as the remote transport by adding ``akka.remote.netty.ssl``
 to the ``enabled-transport`` configuration section. See a description of the settings
 in the :ref:`remote-configuration-scala` section.
 
-The SSL support is implemented with Java Secure Socket Extension, please consult the offical
+The SSL support is implemented with Java Secure Socket Extension, please consult the official
 `Java Secure Socket Extension documentation <http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html>`_
 and related resources for troubleshooting.
 

akka-docs/rst/scala/routing.rst

@@ -651,7 +651,7 @@ Start with the routing logic:
 
 ``select`` will be called for each message and in this example pick a few destinations by round-robin,
 by reusing the existing ``RoundRobinRoutingLogic`` and wrap the result in a ``SeveralRoutees``
-instance.  ``SeveralRoutees`` will send the message to all of the supplied routues.
+instance.  ``SeveralRoutees`` will send the message to all of the supplied routes.
 
 The implementation of the routing logic must be thread safe, since it might be used outside of actors.
 

akka-docs/rst/scala/testing.rst

@@ -411,7 +411,7 @@ Resolving Conflicts with Implicit ActorRef
 ------------------------------------------
 
 If you want the sender of messages inside your TestKit-based tests to be the ``testActor``
-simply mix in ``ÌmplicitSender`` into your test.
+simply mix in ``ImplicitSender`` into your test.
 
 .. includecode:: code/docs/testkit/PlainWordSpec.scala#implicit-sender
 
@@ -736,7 +736,7 @@ options:
 .. includecode:: code/docs/testkit/TestkitDocSpec.scala#logging-receive
 
 .
-  If the abovementioned setting is not given in the :ref:`configuration`, this method will
+  If the aforementioned setting is not given in the :ref:`configuration`, this method will
   pass through the given :class:`Receive` function unmodified, meaning that
   there is no runtime cost unless actually enabled.
 
@@ -815,7 +815,7 @@ Some `Specs2 <http://specs2.org>`_ users have contributed examples of how to wor
   with :class:`org.specs2.specification.Scope`.
 * The Specification traits provide a :class:`Duration` DSL which uses partly
   the same method names as :class:`scala.concurrent.duration.Duration`, resulting in ambiguous
-  implicits if ``scala.concurrent.duration._`` is imported. There are two work-arounds:
+  implicits if ``scala.concurrent.duration._`` is imported. There are two workarounds:
 
   * either use the Specification variant of Duration and supply an implicit
     conversion to the Akka Duration. This conversion is not supplied with the

akka-docs/rst/scala/typed-actors.rst

@@ -143,7 +143,7 @@ This call is asynchronous, and the Future returned can be used for asynchronous
 Stopping Typed Actors
 ---------------------
 
-Since Akkas Typed Actors are backed by Akka Actors they must be stopped when they aren't needed anymore.
+Since Akka's Typed Actors are backed by Akka Actors they must be stopped when they aren't needed anymore.
 
 .. includecode:: code/docs/actor/TypedActorDocSpec.scala
    :include: typed-actor-stop

akka-docs/rst/scala/typed.rst

@@ -305,7 +305,7 @@ reply-to address in the message, which both burdens the user with this task but
 also places this aspect of protocol design where it belongs.
 
 The other prominent difference is the removal of the :class:`Actor` trait. In
-order to avoid closing over instable references from different execution
+order to avoid closing over unstable references from different execution
 contexts (e.g. Future transformations) we turned all remaining methods that
 were on this trait into messages: the behavior receives the
 :class:`ActorContext` as an argument during processing and the lifecycle hooks