Various spelling errors

akka-docs-new/src/main/paradox/guide/actors-intro.md

@@ -198,7 +198,7 @@ different actors work concurrently with each other so an actor system can proces
 as many processor cores are available on the machine. Since there is always at most one message being processed per actor 
 the invariants of an actor can be kept without synchronization. This happens automatically without using locks:
 
-![messages don't invalidat invarants as they are processed sequentially](diagrams/serialized_timeline_invariants.png)
+![messages don't invalidate invariants as they are processed sequentially](diagrams/serialized_timeline_invariants.png)
 
 In summary, this is what happens when an actor receives a message. It:
 

akka-docs-new/src/main/paradox/guide/tutorial_1.md

@@ -59,7 +59,7 @@ actors in the system:
    you, it has nothing to do with the logged in user, nor user handling in general. This name really means _userspace_
    as this is the place where actors that do not access Akka internals live, i.e. all the actors created by users
    of the Akka library. Every actor you will create will have the constant path `/user/` prepended to it.
- - `/sytem` the _system guardian_. 
+ - `/system` the _system guardian_. 
    
 The names of these built-in actors contain _guardian_ because these are _supervising_ every actor living as a child
 of them (i.e. under their path). We will explain supervision in more detail, all you need to know now that every
@@ -195,7 +195,7 @@ details.
 
 ### The first actor
 
-Actors are organized into a strict tree, where the lifecylce of every child is tied to the parent and where parents
+Actors are organized into a strict tree, where the lifecycle of every child is tied to the parent and where parents
 are responsible to decide on the fate of failed children. At first, it might not be evident how to map our problem
 to such a tree, but in practice, this is easier than it looks. All we need to do is to rewrite our architecture diagram
 that contained nested boxes into a tree:
@@ -232,4 +232,4 @@ In the following chapters we will grow the application step-by-step:
  1. We will create the representation for a device
  2. We create the device management component
  3. We add query capabilities to device groups
- 4. We add the dashboard component
+ 4. We add the dashboard component

akka-docs-new/src/main/paradox/guide/tutorial_2.md

@@ -104,10 +104,10 @@ immediately after the API has been invoked
 The problem is that the **guarantee of delivery** does not translate to the **domain level guarantee**. We only want to
 report success once the order has been actually fully processed and persisted. **The only entity that can report
 success is the application itself, since only it has any understanding of the domain guarantees required. No generalized
-framework can figure out the specifics of a particular domain and what is consisered a success in that domain**. In
+framework can figure out the specifics of a particular domain and what is considered a success in that domain**. In
 this particular example, we only want to signal success after a successful database write, where the database acknowledged
 that the order is now safely stored. **For these reasons Akka lifts the responsibilities of guarantees to the application
-itelf, i.e. you have to implement them yourself. On the other hand, you are in full control of the guarantees that you want
+itself, i.e. you have to implement them yourself. On the other hand, you are in full control of the guarantees that you want
 to provide**.
 
 ### Message ordering

akka-docs-new/src/main/paradox/guide/tutorial_3.md

@@ -77,7 +77,7 @@ is known upfront: groups and device actors are created on-demand. The steps of r
  4. If the group already has an actor for the device ID, it forwards the request to it. Otherwise it first creates
     a new one and then forwards the request.
  5. The device actor receives the request, and acknowledges it to the original sender. Since he is the sender of
-    the acknowledgement, the recevier will be able to learn its `ActorRef` and send direct messages to it in the future.
+    the acknowledgement, the receiver will be able to learn its `ActorRef` and send direct messages to it in the future.
     
 Now that the steps are defined, we only need to define the messages that we will use to communicate requests and
 their acknowledgement:
@@ -201,7 +201,7 @@ actor.
 We have now a hierarchic component for registering and tracking devices and recording measurements. We have seen
 some conversation patterns like
 
- * request-respond (for temperature recorings)
+ * request-respond (for temperature recordings)
  * delegate-respond (for registration of devices)
  * create-watch-terminate (for creating group and device actor as children)
  

akka-docs-new/src/main/paradox/guide/tutorial_4.md

@@ -115,7 +115,7 @@ thing to note is that the function `waitingForReplies` **does not handle the mes
 function that will handle the messages**. This means that if we call `waitingForReplies` again, with different parameters,
 then it returns a brand new `Receive` that will use those new parameters. We have seen how we
 can install the initial `Receive` by simply returning it from `receive`. In order to install a new one, to record a 
-new reply for example, we need some mechanism. This mechanism is the method `context.becdome(newReceive)` which will
+new reply for example, we need some mechanism. This mechanism is the method `context.become(newReceive)` which will
 _change_ the actor's message handling function to the provided `newReceive` function. You can imagine that before
 starting, your actor automatically calls `context.become(receive)`, i.e. installing the `Receive` function that
 is returned from `receive`. This is another important observation: **it is not `receive` that handles the messages,
@@ -144,7 +144,7 @@ just making the `repliesSoFar` and `stillWaiting` structures mutable fields of t
 simple example, not that much. The value of this style of state keeping becomes more evident when you suddenly have
 _more kinds_ of states. For example imagine that the query have multiple phases that come each other. Since each phase
 might have temporary data that is relevant only to that phase, keeping these as fields would pollute the global state
-of the actor where it is not clear which field is used or ignored in which state. Using parametrized `Receive` "factory"
+of the actor where it is not clear which field is used or ignored in which state. Using parameterized `Receive` "factory"
 methods we can keep data that is only relevant to the state private to the state. It is still a good exercise to 
 rewrite the query using `var`s instead of `context.become()`. In general, it is a good practice to get comfortable
 with the solution we have used here as it helps structuring more complex actor in a cleaner and more maintainable way.
@@ -187,7 +187,7 @@ Our query works as expected now, it is time to include this new functionality in
 
 ## Adding the query capability to the group
 
-Including the query feature in the group actor is fairly simple now. We did all the heavylifting in the query actor
+Including the query feature in the group actor is fairly simple now. We did all the heavy lifting in the query actor
 itself, the group actor only needs to create it with the right initial parameters and nothing else. 
 
 @@snip [Hello.scala](../../../test/scala/tutorial_4/DeviceGroup.scala) { #query-added }