Fix spelling errors.
This commit is contained in:
parent
c316cd4e0b
commit
3d90f480d0
15 changed files with 26 additions and 26 deletions
|
|
@ -93,7 +93,7 @@ class ResizerSpec extends AkkaSpec(ResizerSpec.config) with DefaultTimeout with
|
|||
resizer.backoff(pressure = 0, capacity = 9) must be(-1)
|
||||
}
|
||||
|
||||
"be possible to define programatically" in {
|
||||
"be possible to define programmatically" in {
|
||||
|
||||
val latch = new TestLatch(3)
|
||||
|
||||
|
|
|
|||
|
|
@ -228,7 +228,7 @@ abstract class ActorSystem extends ActorRefFactory {
|
|||
/**
|
||||
* Register a block of code (callback) to run after all actors in this actor system have
|
||||
* been stopped. Multiple code blocks may be registered by calling this method multiple times.
|
||||
* The callbacks will be run sequentilly in reverse order of registration, i.e.
|
||||
* The callbacks will be run sequentially in reverse order of registration, i.e.
|
||||
* last registration is run first.
|
||||
*
|
||||
* @throws a RejectedExecutionException if the System has already shut down or if shutdown has been initiated.
|
||||
|
|
@ -240,7 +240,7 @@ abstract class ActorSystem extends ActorRefFactory {
|
|||
/**
|
||||
* Register a block of code (callback) to run after all actors in this actor system have
|
||||
* been stopped. Multiple code blocks may be registered by calling this method multiple times.
|
||||
* The callbacks will be run sequentilly in reverse order of registration, i.e.
|
||||
* The callbacks will be run sequentially in reverse order of registration, i.e.
|
||||
* last registration is run first.
|
||||
*
|
||||
* @throws a RejectedExecutionException if the System has already shut down or if shutdown has been initiated.
|
||||
|
|
|
|||
|
|
@ -774,7 +774,7 @@ final class IOManagerActor extends Actor {
|
|||
/** Buffer used for all reads */
|
||||
private val buffer = ByteBuffer.allocate(bufferSize)
|
||||
|
||||
/** a counter that is incremented each time a message is retreived */
|
||||
/** a counter that is incremented each time a message is retrieved */
|
||||
private var lastSelect = 0
|
||||
|
||||
/** force a select when lastSelect reaches this amount */
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ trait TypedActorFactory {
|
|||
def getActorRefFor(proxy: AnyRef): ActorRef
|
||||
|
||||
/**
|
||||
* Creates a new TypedActor with the specified properies
|
||||
* Creates a new TypedActor with the specified properties
|
||||
*/
|
||||
def typedActorOf[R <: AnyRef, T <: R](props: TypedProps[T]): R = {
|
||||
val proxyVar = new AtomVar[R] //Chicken'n'egg-resolver
|
||||
|
|
@ -60,7 +60,7 @@ trait TypedActorFactory {
|
|||
}
|
||||
|
||||
/**
|
||||
* Creates a new TypedActor with the specified properies
|
||||
* Creates a new TypedActor with the specified properties
|
||||
*/
|
||||
def typedActorOf[R <: AnyRef, T <: R](props: TypedProps[T], name: String): R = {
|
||||
val proxyVar = new AtomVar[R] //Chicken'n'egg-resolver
|
||||
|
|
@ -382,7 +382,7 @@ object TypedProps {
|
|||
val defaultLoader: Option[ClassLoader] = None
|
||||
|
||||
/**
|
||||
* @return a sequence of interfaces that the speicified class implements,
|
||||
* @return a sequence of interfaces that the specified class implements,
|
||||
* or a sequence containing only itself, if itself is an interface.
|
||||
*/
|
||||
def extractInterfaces(clazz: Class[_]): Seq[Class[_]] =
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ trait ConnectionManager {
|
|||
def shutdown()
|
||||
|
||||
/**
|
||||
* Returns a VersionedIterator containing all connectected ActorRefs at some moment in time. Since there is
|
||||
* Returns a VersionedIterator containing all connected ActorRefs at some moment in time. Since there is
|
||||
* the time element, also the version is included to be able to read the data (the connections) and the version
|
||||
* in an atomic manner.
|
||||
*
|
||||
|
|
|
|||
|
|
@ -346,7 +346,7 @@ case class Destination(sender: ActorRef, recipient: ActorRef)
|
|||
/**
|
||||
* Routing configuration that indicates no routing; this is also the default
|
||||
* value which hence overrides the merge strategy in order to accept values
|
||||
* from lower-precendence sources. The decision whether or not to create a
|
||||
* from lower-precedence sources. The decision whether or not to create a
|
||||
* router is taken in the LocalActorRefProvider based on Props.
|
||||
*/
|
||||
//TODO add @SerialVersionUID(1L) when SI-4804 is fixed
|
||||
|
|
|
|||
|
|
@ -579,7 +579,7 @@ have a dependency on message ordering from any given source.
|
|||
approach can be used (with no forwarding or buffering needed).
|
||||
|
||||
- If an actor is a singleton (only one instance possible throughout the cluster)
|
||||
and state is transfered during the migration initialization, then options 2b
|
||||
and state is transferred during the migration initialization, then options 2b
|
||||
and 3b would be required.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Actor Systems
|
|||
|
||||
Actors are objects which encapsulate state and behavior, they communicate
|
||||
exclusively by exchanging messages which are placed into the recipient’s
|
||||
mailbox. In a sense, actors are the most strigent form of object-oriented
|
||||
mailbox. In a sense, actors are the most stringent form of object-oriented
|
||||
programming, but it serves better to view them as persons: while modeling a
|
||||
solution with actors, envision a group of people and assign sub-tasks to them,
|
||||
arrange their functions into an organizational structure and think about how to
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ This is an example of how to create a router that is defined in configuration:
|
|||
|
||||
.. includecode:: code/akka/docs/jrouting/RouterViaConfigExample.java#configurableRouting
|
||||
|
||||
This is an example of how to programatically create a router and set the number of routees it should create:
|
||||
This is an example of how to programmatically create a router and set the number of routees it should create:
|
||||
|
||||
.. includecode:: code/akka/docs/jrouting/RouterViaProgramExample.java#programmaticRoutingNrOfInstances
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ You can also give the router already created routees as in:
|
|||
|
||||
.. includecode:: code/akka/docs/jrouting/RouterViaProgramExample.java#programmaticRoutingRoutees
|
||||
|
||||
When you create a router programatically you define the number of routees *or* you pass already created routees to it.
|
||||
When you create a router programmatically you define the number of routees *or* you pass already created routees to it.
|
||||
If you send both parameters to the router *only* the latter will be used, i.e. ``nrOfInstances`` is disregarded.
|
||||
|
||||
*It is also worth pointing out that if you define the ``router`` in the
|
||||
|
|
@ -234,10 +234,10 @@ This is an example of how to create a resizable router that is defined in config
|
|||
|
||||
.. includecode:: code/akka/docs/jrouting/RouterViaConfigExample.java#configurableRoutingWithResizer
|
||||
|
||||
Several more configuration options are availble and described in ``akka.actor.deployment.default.resizer``
|
||||
Several more configuration options are available and described in ``akka.actor.deployment.default.resizer``
|
||||
section of the reference :ref:`configuration`.
|
||||
|
||||
This is an example of how to programatically create a resizable router:
|
||||
This is an example of how to programmatically create a resizable router:
|
||||
|
||||
.. includecode:: code/akka/docs/jrouting/RouterViaProgramExample.java#programmaticRoutingWithResizer
|
||||
|
||||
|
|
@ -327,7 +327,7 @@ routing is not so important (i.e. no consistent hashing or round-robin is
|
|||
required); this enables newly created routees to pick up work immediately by
|
||||
stealing it from their siblings.
|
||||
|
||||
The “head” router, of couse, cannot run on the same balancing dispatcher,
|
||||
The “head” router, of course, cannot run on the same balancing dispatcher,
|
||||
because it does not process the same messages, hence this special actor does
|
||||
not use the dispatcher configured in :class:`Props`, but takes the
|
||||
``routerDispatcher`` from the :class:`RouterConfig` instead, which defaults to
|
||||
|
|
|
|||
|
|
@ -141,7 +141,7 @@ This mailbox is backed by `ZooKeeper <http://zookeeper.apache.org/>`_. ZooKeeper
|
|||
is a centralized service for maintaining configuration information, naming,
|
||||
providing distributed synchronization, and providing group services This means
|
||||
that you have to start up a ZooKeeper server (for production a ZooKeeper server
|
||||
ensamble) that can host these durable mailboxes. Read more in the ZooKeeper
|
||||
ensemble) that can host these durable mailboxes. Read more in the ZooKeeper
|
||||
documentation on how to do that.
|
||||
|
||||
You configure durable mailboxes through the dispatcher, as described in
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Now let’s take a look at the skeleton for our FSM actor:
|
|||
:exclude: transition-elided,unhandled-elided
|
||||
|
||||
The basic strategy is to declare the actor, mixing in the :class:`FSM` trait
|
||||
and specifying the possible states and data values as type paramters. Within
|
||||
and specifying the possible states and data values as type parameters. Within
|
||||
the body of the actor a DSL is used for declaring the state machine:
|
||||
|
||||
* :meth:`startsWith` defines the initial state and initial data
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ IO.Handle
|
|||
IOManager
|
||||
^^^^^^^^^
|
||||
|
||||
The ``IOManager`` takes care of the low level IO details. Each ``ActorSystem`` has it's own ``IOManager``, which can be accessed calling ``IOManager(system: ActorSystem)``. ``Actor``\s communicate with the ``IOManager`` with specific messages. The messages sent from an ``Actor`` to the ``IOManager`` are handled automatically when using certain methods and the messagegs sent from an ``IOManager`` are handled within an ``Actor``\'s ``receive`` method.
|
||||
The ``IOManager`` takes care of the low level IO details. Each ``ActorSystem`` has it's own ``IOManager``, which can be accessed calling ``IOManager(system: ActorSystem)``. ``Actor``\s communicate with the ``IOManager`` with specific messages. The messages sent from an ``Actor`` to the ``IOManager`` are handled automatically when using certain methods and the messages sent from an ``IOManager`` are handled within an ``Actor``\'s ``receive`` method.
|
||||
|
||||
Connecting to a remote host:
|
||||
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ purposes as it contains exactly the default behavior.
|
|||
|
||||
The SLF4J event listener treats this case specially (using the actual string
|
||||
to look up the logger instance to use instead of the class’ name), and you
|
||||
might want to do this also in case you implement your own loggin adapter.
|
||||
might want to do this also in case you implement your own logging adapter.
|
||||
|
||||
Event Handler
|
||||
=============
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ This is an example of how to create a router that is defined in configuration:
|
|||
|
||||
.. includecode:: code/akka/docs/routing/RouterViaConfigExample.scala#configurableRouting
|
||||
|
||||
This is an example of how to programatically create a router and set the number of routees it should create:
|
||||
This is an example of how to programmatically create a router and set the number of routees it should create:
|
||||
|
||||
.. includecode:: code/akka/docs/routing/RouterViaProgramExample.scala#programmaticRoutingNrOfInstances
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ You can also give the router already created routees as in:
|
|||
|
||||
.. includecode:: code/akka/docs/routing/RouterViaProgramExample.scala#programmaticRoutingRoutees
|
||||
|
||||
When you create a router programatically you define the number of routees *or* you pass already created routees to it.
|
||||
When you create a router programmatically you define the number of routees *or* you pass already created routees to it.
|
||||
If you send both parameters to the router *only* the latter will be used, i.e. ``nrOfInstances`` is disregarded.
|
||||
|
||||
*It is also worth pointing out that if you define the ``router`` in the
|
||||
|
|
@ -235,10 +235,10 @@ This is an example of how to create a resizable router that is defined in config
|
|||
|
||||
.. includecode:: code/akka/docs/routing/RouterViaConfigExample.scala#configurableRoutingWithResizer
|
||||
|
||||
Several more configuration options are availble and described in ``akka.actor.deployment.default.resizer``
|
||||
Several more configuration options are available and described in ``akka.actor.deployment.default.resizer``
|
||||
section of the reference :ref:`configuration`.
|
||||
|
||||
This is an example of how to programatically create a resizable router:
|
||||
This is an example of how to programmatically create a resizable router:
|
||||
|
||||
.. includecode:: code/akka/docs/routing/RouterViaProgramExample.scala#programmaticRoutingWithResizer
|
||||
|
||||
|
|
@ -326,7 +326,7 @@ routing is not so important (i.e. no consistent hashing or round-robin is
|
|||
required); this enables newly created routees to pick up work immediately by
|
||||
stealing it from their siblings.
|
||||
|
||||
The “head” router, of couse, cannot run on the same balancing dispatcher,
|
||||
The “head” router, of course, cannot run on the same balancing dispatcher,
|
||||
because it does not process the same messages, hence this special actor does
|
||||
not use the dispatcher configured in :class:`Props`, but takes the
|
||||
``routerDispatcher`` from the :class:`RouterConfig` instead, which defaults to
|
||||
|
|
|
|||
|
|
@ -204,7 +204,7 @@ of failure) so that all actors—including the test actor—are stopped.
|
|||
Built-In Assertions
|
||||
-------------------
|
||||
|
||||
The abovementioned :meth:`expectMsg` is not the only method for formulating
|
||||
The above mentioned :meth:`expectMsg` is not the only method for formulating
|
||||
assertions concerning received messages. Here is the full list:
|
||||
|
||||
* :meth:`expectMsg[T](d: Duration, msg: T): T`
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue