=doc Fixed and normalized spellings

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/extending-akka.rst

@@ -31,7 +31,7 @@ First, we define what our ``Extension`` should do:
 .. includecode:: code/docs/extension/ExtensionDocTest.java
    :include: extension
 
-Then we need to create an ``ExtensionId`` for our extension so we can grab ahold of it.
+Then we need to create an ``ExtensionId`` for our extension so we can grab a hold of it.
 
 .. includecode:: code/docs/extension/ExtensionDocTest.java
    :include: imports

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/typed-actors.rst

@@ -4,7 +4,7 @@ Typed Actors
 Akka Typed Actors is an implementation of the `Active Objects <http://en.wikipedia.org/wiki/Active_object>`_ pattern.
 Essentially turning method invocations into asynchronous dispatch instead of synchronous that has been the default way since Smalltalk came out.
 
-Typed Actors consist of 2 "parts", a public interface and an implementation, and if you've done any work in "enterprise" Java, this will be very familiar to you. As with normal Actors you have an external API (the public interface instance) that will delegate methodcalls asynchronously to
+Typed Actors consist of 2 "parts", a public interface and an implementation, and if you've done any work in "enterprise" Java, this will be very familiar to you. As with normal Actors you have an external API (the public interface instance) that will delegate method calls asynchronously to
 a private instance of the implementation.
 
 The advantage of Typed Actors vs. Actors is that with TypedActors you have a static contract, and don't need to define your own messages, the downside is that it places some limitations on what you can do and what you can't, i.e. you can't use become/unbecome.

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