=doc Fix a few typos in docs

akka-contrib/docs/cluster-sharding.rst

@@ -43,7 +43,7 @@ identifier and the shard identifier from incoming messages.
 
 This example illustrates two different ways to define the entry identifier in the messages: 
 
- * The ``Get`` message includes the the identifier itself.
+ * The ``Get`` message includes the identifier itself.
  * The ``EntryEnvelope`` holds the identifier, and the actual message that is
    sent to the entry actor is wrapped in the envelope. 
 
@@ -87,7 +87,7 @@ identifier and the shard identifier from incoming messages.
 
 This example illustrates two different ways to define the entry identifier in the messages: 
 
- * The ``Get`` message includes the the identifier itself.
+ * The ``Get`` message includes the identifier itself.
  * The ``EntryEnvelope`` holds the identifier, and the actual message that is
    sent to the entry actor is wrapped in the envelope. 
 
@@ -219,7 +219,7 @@ in the mailbox will be dropped. To support graceful passivation without loosing
 messages the entry actor can send ``ShardRegion.Passivate`` to its parent ``ShardRegion``.
 The specified wrapped message in ``Passivate`` will be sent back to the entry, which is
 then supposed to stop itself. Incoming messages will be buffered by the ``ShardRegion``
-between reception of ``Passivate`` and termination of the the entry. Such buffered messages
+between reception of ``Passivate`` and termination of the entry. Such buffered messages
 are thereafter delivered to a new incarnation of the entry.
 
 Configuration

akka-contrib/src/main/scala/akka/contrib/pattern/ClusterSharding.scala

@@ -147,7 +147,7 @@ import akka.persistence.SaveSnapshotFailure
  * messages the entry actor can send [[ShardRegion.Passivate]] to its parent `ShardRegion`.
  * The specified wrapped message in `Passivate` will be sent back to the entry, which is
  * then supposed to stop itself. Incoming messages will be buffered by the `ShardRegion`
- * between reception of `Passivate` and termination of the the entry. Such buffered messages
+ * between reception of `Passivate` and termination of the entry. Such buffered messages
  * are thereafter delivered to a new incarnation of the entry.
  *
  */
@@ -537,7 +537,7 @@ object ShardRegion {
    * messages the entry actor can send this `Passivate` message to its parent `ShardRegion`.
    * The specified wrapped `stopMessage` will be sent back to the entry, which is
    * then supposed to stop itself. Incoming messages will be buffered by the `ShardRegion`
-   * between reception of `Passivate` and termination of the the entry. Such buffered messages
+   * between reception of `Passivate` and termination of the entry. Such buffered messages
    * are thereafter delivered to a new incarnation of the entry.
    *
    * [[akka.actor.PoisonPill]] is a perfectly fine `stopMessage`.

akka-contrib/src/main/scala/akka/contrib/throttle/TimerBasedThrottler.scala

@@ -92,7 +92,7 @@ object Throttler {
    * @param target if `target` is `None`, the throttler will stop delivering messages and the messages already received
    *  but not yet delivered, as well as any messages received in the future will be queued
    *  and eventually be delivered when a new target is set. If `target` is not `None`, the currently queued messages
-   *  as well as any messages received in the the future will be delivered to the new target at a rate not exceeding the current throttler's rate.
+   *  as well as any messages received in the future will be delivered to the new target at a rate not exceeding the current throttler's rate.
    */
   case class SetTarget(target: Option[ActorRef]) {
     /**
@@ -100,7 +100,7 @@ object Throttler {
      * @param target if `target` is `null`, the throttler will stop delivering messages and the messages already received
      *  but not yet delivered, as well as any messages received in the future will be queued
      *  and eventually be delivered when a new target is set. If `target` is not `null`, the currently queued messages
-     *  as well as any messages received in the the future will be delivered to the new target at a rate not exceeding
+     *  as well as any messages received in the future will be delivered to the new target at a rate not exceeding
      *  the current throttler's rate.
      */
     def this(target: ActorRef) = this(Option(target))

akka-docs/rst/general/actors.rst

@@ -54,7 +54,7 @@ the actor. This is to enable the ability of self-healing of the system.
 
 Optionally, an actor's state can be automatically recovered to the state
 before a restart by persisting received messages and replaying them after
-restart (see :ref:`persistence`).
+restart (see :ref:`persistence-scala`).
 
 Behavior
 --------

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

@@ -388,7 +388,7 @@ There are two distinct types of routers.
 * **Pool - router that creates routees as child actors and deploys them on remote nodes.** 
   Each router will have its own routee instances. For example, if you start a router
   on 3 nodes in a 10 nodes cluster you will have 30 routee actors in total if the router is
-  configured to use one inctance per node. The routees created by the the different routers
+  configured to use one inctance per node. The routees created by the different routers
   will not be shared between the routers. One example of a use case for this type of router
   is a single master that coordinate jobs and delegates the actual work to routees running 
   on other nodes in the cluster.

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

@@ -319,7 +319,7 @@ encrypt them and send them off to the connection actor while buffering writes.
 This pipeline is driven by a :class:`TcpPipelineHandler` actor which is also
 included in ``akka-actor``. In order to capture the generic command and event
 types consumed and emitted by that actor we need to create a wrapper—the nested
-:class:`Init` class—which also provides the the pipeline context needed by the
+:class:`Init` class—which also provides the pipeline context needed by the
 supplied pipeline; in this case we use the :meth:`withLogger` convenience
 method which supplies a context that implements :class:`HasLogger` and
 :class:`HasActorContext` and should be sufficient for typical pipelines. With

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

@@ -385,7 +385,7 @@ There are two distinct types of routers.
 * **Pool - router that creates routees as child actors and deploys them on remote nodes.** 
   Each router will have its own routee instances. For example, if you start a router
   on 3 nodes in a 10 nodes cluster you will have 30 routee actors in total if the router is
-  configured to use one inctance per node. The routees created by the the different routers
+  configured to use one inctance per node. The routees created by the different routers
   will not be shared between the routers. One example of a use case for this type of router
   is a single master that coordinate jobs and delegates the actual work to routees running 
   on other nodes in the cluster.

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

@@ -313,7 +313,7 @@ encrypt them and send them off to the connection actor while buffering writes.
 This pipeline is driven by a :class:`TcpPipelineHandler` actor which is also
 included in ``akka-actor``. In order to capture the generic command and event
 types consumed and emitted by that actor we need to create a wrapper—the nested
-:class:`Init` class—which also provides the the pipeline context needed by the
+:class:`Init` class—which also provides the pipeline context needed by the
 supplied pipeline; in this case we use the :meth:`withLogger` convenience
 method which supplies a context that implements :class:`HasLogger` and
 :class:`HasActorContext` and should be sufficient for typical pipelines. With

akka-docs/rst/scala/io.rst

@@ -122,13 +122,3 @@ For further details on the design and internal architecture see :ref:`io-layer`.
 
 .. _spray.io: http://spray.io
 
-Link to the old IO documentation
---------------------------------
-
-.. This is only in here to avoid a warning about io-old not being part of any toctree.
-
-.. toctree::
-   :maxdepth: 1
-
-   io-old
-

akka-docs/rst/scala/persistence.rst

@@ -1,4 +1,4 @@
-.. _persistence:
+.. _persistence-scala:
 
 ###########
 Persistence

akka-docs/rst/scala/serialization.rst

@@ -155,7 +155,7 @@ There is also a default remote address which is the one used by cluster support
 Deep serialization of Actors
 ----------------------------
 
-The recommended approach to do deep serialization of internal actor state is to use Akka :ref:`persistence`.
+The recommended approach to do deep serialization of internal actor state is to use Akka :ref:`persistence-scala`.
 
 A Word About Java Serialization
 ===============================