diff --git a/akka-docs/rst/general/jmm.rst b/akka-docs/rst/general/jmm.rst index 085a347451..dc0c87e2a4 100644 --- a/akka-docs/rst/general/jmm.rst +++ b/akka-docs/rst/general/jmm.rst @@ -13,9 +13,9 @@ Prior to Java 5, the Java Memory Model (JMM) was ill defined. It was possible to shared memory was accessed by multiple threads, such as: * a thread not seeing values written by other threads: a visibility problem -* a thread observing 'impossible' behavior of other threads, caused by instructions not being executed in the order - -expected: an instruction reordering problem. +* a thread observing 'impossible' behavior of other threads, caused by + instructions not being executed in the order expected: an instruction + reordering problem. With the implementation of JSR 133 in Java 5, a lot of these issues have been resolved. The JMM is a set of rules based on the "happens-before" relation, which constrain when one memory access must happen before another, and conversely, @@ -120,4 +120,4 @@ Since Akka runs on the JVM there are still some rules to be followed. } } -* Messages **should** be immutable, this is to avoid the shared mutable state trap. \ No newline at end of file +* Messages **should** be immutable, this is to avoid the shared mutable state trap. diff --git a/akka-docs/rst/intro/why-akka.rst b/akka-docs/rst/intro/why-akka.rst index 85789fdf19..e11cfee187 100644 --- a/akka-docs/rst/intro/why-akka.rst +++ b/akka-docs/rst/intro/why-akka.rst @@ -24,7 +24,7 @@ and then there's the whole package, the Akka Microkernel, which is a standalone container to deploy your Akka application in. With CPUs growing more and more cores every cycle, Akka is the alternative that provides outstanding performance even if you're only running it on one machine. Akka also supplies a wide array -of concurrency-paradigms, allowing for users to choose the right tool for the +of concurrency-paradigms, allowing users to choose the right tool for the job. diff --git a/akka-docs/rst/java/event-bus.rst b/akka-docs/rst/java/event-bus.rst index faecd1d209..fa71e356d8 100644 --- a/akka-docs/rst/java/event-bus.rst +++ b/akka-docs/rst/java/event-bus.rst @@ -185,7 +185,7 @@ at runtime:: system.eventStream.setLogLevel(Logging.DebugLevel()); -This means that log events for a level which will not be logged are not +This means that log events for a level which will not be logged are typically not dispatched at all (unless manual subscriptions to the respective event class have been done) diff --git a/akka-docs/rst/java/fault-tolerance.rst b/akka-docs/rst/java/fault-tolerance.rst index 3794ebd3fe..9cb9d234fd 100644 --- a/akka-docs/rst/java/fault-tolerance.rst +++ b/akka-docs/rst/java/fault-tolerance.rst @@ -24,9 +24,6 @@ sample as it is easy to follow the log output to understand what is happening in fault-tolerance-sample -.. includecode:: code/docs/actor/japi/FaultHandlingDocSample.java#all - :exclude: imports,messages,dummydb - Creating a Supervisor Strategy ------------------------------ diff --git a/akka-docs/rst/java/routing.rst b/akka-docs/rst/java/routing.rst index 4d21bdd187..9f74e6d902 100644 --- a/akka-docs/rst/java/routing.rst +++ b/akka-docs/rst/java/routing.rst @@ -66,7 +66,7 @@ In addition to being able to supply looked-up remote actors as routees, you can make the router deploy its created children on a set of remote hosts; this will be done in round-robin fashion. In order to do that, wrap the router configuration in a :class:`RemoteRouterConfig`, attaching the remote addresses of -the nodes to deploy to. Naturally, this requires your to include the +the nodes to deploy to. Naturally, this requires you to include the ``akka-remote`` module on your classpath: .. includecode:: code/docs/jrouting/RouterViaProgramExample.java#remoteRoutees @@ -114,7 +114,7 @@ Routers vs. Supervision ^^^^^^^^^^^^^^^^^^^^^^^ As explained in the previous section, routers create new actor instances as -children of the “head” router, who therefor also is their supervisor. The +children of the “head” router, who therefore also is their supervisor. The supervisor strategy of this actor can be configured by means of the :meth:`RouterConfig.supervisorStrategy` property, which is supported for all built-in router types. It defaults to “always escalate”, which leads to the @@ -434,7 +434,7 @@ Configured Custom Router It is possible to define configuration properties for custom routers. In the ``router`` property of the deployment configuration you define the fully qualified class name of the router class. The router class must extend -``akka.routing.CustomRouterConfig`` and and have constructor with ``com.typesafe.config.Config`` parameter. +``akka.routing.CustomRouterConfig`` and have constructor with one ``com.typesafe.config.Config`` parameter. The deployment section of the configuration is passed to the constructor. Custom Resizer diff --git a/akka-docs/rst/scala/fault-tolerance.rst b/akka-docs/rst/scala/fault-tolerance.rst index f0e3952c99..6b6559e647 100644 --- a/akka-docs/rst/scala/fault-tolerance.rst +++ b/akka-docs/rst/scala/fault-tolerance.rst @@ -24,9 +24,6 @@ sample as it is easy to follow the log output to understand what is happening in fault-tolerance-sample -.. includecode:: code/docs/actor/FaultHandlingDocSample.scala#all - :exclude: imports,messages,dummydb - Creating a Supervisor Strategy ------------------------------ diff --git a/akka-docs/rst/scala/routing.rst b/akka-docs/rst/scala/routing.rst index 9dc356c98c..f04223b5d3 100644 --- a/akka-docs/rst/scala/routing.rst +++ b/akka-docs/rst/scala/routing.rst @@ -66,7 +66,7 @@ In addition to being able to supply looked-up remote actors as routees, you can make the router deploy its created children on a set of remote hosts; this will be done in round-robin fashion. In order to do that, wrap the router configuration in a :class:`RemoteRouterConfig`, attaching the remote addresses of -the nodes to deploy to. Naturally, this requires your to include the +the nodes to deploy to. Naturally, this requires you to include the ``akka-remote`` module on your classpath: .. includecode:: code/docs/routing/RouterViaProgramExample.scala#remoteRoutees @@ -430,7 +430,7 @@ Configured Custom Router It is possible to define configuration properties for custom routers. In the ``router`` property of the deployment configuration you define the fully qualified class name of the router class. The router class must extend -``akka.routing.RouterConfig`` and and have constructor with ``com.typesafe.config.Config`` parameter. +``akka.routing.RouterConfig`` and have constructor with one ``com.typesafe.config.Config`` parameter. The deployment section of the configuration is passed to the constructor. Custom Resizer