diff --git a/akka-docs-new/src/main/paradox/guide/actors-intro.md b/akka-docs-new/src/main/paradox/guide/actors-intro.md index 20a57a9701..ad3023d2b3 100644 --- a/akka-docs-new/src/main/paradox/guide/actors-intro.md +++ b/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: diff --git a/akka-docs-new/src/main/paradox/guide/tutorial_1.md b/akka-docs-new/src/main/paradox/guide/tutorial_1.md index 8d8c7eba0f..8d870941ea 100644 --- a/akka-docs-new/src/main/paradox/guide/tutorial_1.md +++ b/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 \ No newline at end of file + 4. We add the dashboard component diff --git a/akka-docs-new/src/main/paradox/guide/tutorial_2.md b/akka-docs-new/src/main/paradox/guide/tutorial_2.md index d9f804d5d5..240d02ddd8 100644 --- a/akka-docs-new/src/main/paradox/guide/tutorial_2.md +++ b/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 diff --git a/akka-docs-new/src/main/paradox/guide/tutorial_3.md b/akka-docs-new/src/main/paradox/guide/tutorial_3.md index 45a8eca039..467ad0fb5b 100644 --- a/akka-docs-new/src/main/paradox/guide/tutorial_3.md +++ b/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) diff --git a/akka-docs-new/src/main/paradox/guide/tutorial_4.md b/akka-docs-new/src/main/paradox/guide/tutorial_4.md index f913fc222a..438a751cdb 100644 --- a/akka-docs-new/src/main/paradox/guide/tutorial_4.md +++ b/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 }