diff --git a/akka-contrib/docs/cluster-sharding.rst b/akka-contrib/docs/cluster-sharding.rst index 663bb056e7..0841a213e7 100644 --- a/akka-contrib/docs/cluster-sharding.rst +++ b/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 diff --git a/akka-contrib/src/main/scala/akka/contrib/pattern/ClusterSharding.scala b/akka-contrib/src/main/scala/akka/contrib/pattern/ClusterSharding.scala index e563b601fa..d05ae61ec5 100644 --- a/akka-contrib/src/main/scala/akka/contrib/pattern/ClusterSharding.scala +++ b/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`. diff --git a/akka-contrib/src/main/scala/akka/contrib/throttle/TimerBasedThrottler.scala b/akka-contrib/src/main/scala/akka/contrib/throttle/TimerBasedThrottler.scala index 6f65782b6e..28682551ea 100644 --- a/akka-contrib/src/main/scala/akka/contrib/throttle/TimerBasedThrottler.scala +++ b/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)) diff --git a/akka-docs/rst/general/actors.rst b/akka-docs/rst/general/actors.rst index 3e39f54c63..44e6ced415 100644 --- a/akka-docs/rst/general/actors.rst +++ b/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 -------- diff --git a/akka-docs/rst/java/cluster-usage.rst b/akka-docs/rst/java/cluster-usage.rst index f2e94093b9..4d995ac4dc 100644 --- a/akka-docs/rst/java/cluster-usage.rst +++ b/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. diff --git a/akka-docs/rst/java/io-tcp.rst b/akka-docs/rst/java/io-tcp.rst index 2d242c4e51..54590f7189 100644 --- a/akka-docs/rst/java/io-tcp.rst +++ b/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 diff --git a/akka-docs/rst/scala/cluster-usage.rst b/akka-docs/rst/scala/cluster-usage.rst index 0297ae7c54..6c87346534 100644 --- a/akka-docs/rst/scala/cluster-usage.rst +++ b/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. diff --git a/akka-docs/rst/scala/io-tcp.rst b/akka-docs/rst/scala/io-tcp.rst index 284ba84511..a57ee05388 100644 --- a/akka-docs/rst/scala/io-tcp.rst +++ b/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 diff --git a/akka-docs/rst/scala/io.rst b/akka-docs/rst/scala/io.rst index 4569f0f7da..35193035dc 100644 --- a/akka-docs/rst/scala/io.rst +++ b/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 - diff --git a/akka-docs/rst/scala/persistence.rst b/akka-docs/rst/scala/persistence.rst index e7a9edb23f..dd2f5db4d7 100644 --- a/akka-docs/rst/scala/persistence.rst +++ b/akka-docs/rst/scala/persistence.rst @@ -1,4 +1,4 @@ -.. _persistence: +.. _persistence-scala: ########### Persistence diff --git a/akka-docs/rst/scala/serialization.rst b/akka-docs/rst/scala/serialization.rst index 4154cd7e7b..f7cac2dad8 100644 --- a/akka-docs/rst/scala/serialization.rst +++ b/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 ===============================