Fix a few typos in the docs

akka-docs/rst/general/message-delivery-reliability.rst

@@ -319,7 +319,7 @@ Akka Persistence.
 Mailbox with Explicit Acknowledgement
 -------------------------------------
 
-By implementing a custom mailbox type it is possible retry message processing
+By implementing a custom mailbox type it is possible to retry message processing
 at the receiving actor’s end in order to handle temporary failures. This
 pattern is mostly useful in the local communication context where delivery
 guarantees are otherwise sufficient to fulfill the application’s requirements.

akka-docs/rst/java/persistence-query.rst

@@ -161,22 +161,22 @@ specialised query object, as demonstrated in the sample below:
 
 Performance and denormalization
 ===============================
-When building systems using :ref:`event-sourcing-java` and CQRS (`Command & Query Responsibility Segragation`_) techniques
+When building systems using :ref:`event-sourcing-java` and CQRS (`Command & Query Responsibility Segregation`_) techniques
 it is tremendously important to realise that the write-side has completely different needs from the read-side,
 and separating those concerns into datastores that are optimised for either side makes it possible to offer the best
-expirience for the write and read sides independently.
+experience for the write and read sides independently.
 
 For example, in a bidding system it is important to "take the write" and respond to the bidder that we have accepted
 the bid as soon as possible, which means that write-throughput is of highest importance for the write-side – often this
-means that data stores which are able to scale to accomodate these requirements have a less expressive query side.
+means that data stores which are able to scale to accommodate these requirements have a less expressive query side.
 
-On the other hand the same application may have some complex statistics view or we may have analists working with the data
+On the other hand the same application may have some complex statistics view or we may have analysts working with the data
 to figure out best bidding strategies and trends – this often requires some kind of expressive query capabilities like
 for example SQL or writing Spark jobs to analyse the data. Therefore the data stored in the write-side needs to be
 projected into the other read-optimised datastore.
 
 .. note::
-  When refering to **Materialized Views** in Akka Persistence think of it as "some persistent storage of the result of a Query".
+  When referring to **Materialized Views** in Akka Persistence think of it as "some persistent storage of the result of a Query".
   In other words, it means that the view is created once, in order to be afterwards queried multiple times, as in this format
   it may be more efficient or interesting to query it (instead of the source events directly).
 
@@ -217,7 +217,7 @@ into the other datastore:
 
 .. includecode:: code/docs/persistence/PersistenceQueryDocTest.java#projection-into-different-store-actor
 
-.. _Command & Query Responsibility Segragation: https://msdn.microsoft.com/en-us/library/jj554200.aspx
+.. _Command & Query Responsibility Segregation: https://msdn.microsoft.com/en-us/library/jj554200.aspx
 
 .. _read-journal-plugin-api-java:
 

akka-docs/rst/java/persistence-schema-evolution.rst

@@ -136,7 +136,7 @@ As you can see, the ``PersistentMessage`` acts as an envelope around the payload
 origin of the event (``persistenceId``, ``sequenceNr`` and more).
 
 More advanced techniques (e.g. :ref:`remove-event-class-java`) will dive into using the manifests for increasing the
-flexibility of the persisted vs. exposed types even more. Hhowever for now we will focus on the simpler evolution techniques,
+flexibility of the persisted vs. exposed types even more. However for now we will focus on the simpler evolution techniques,
 concerning simply configuring the payload serializers.
 
 By default the ``payload`` will be serialized using Java Serialization. This is fine for testing and initial phases

akka-docs/rst/java/persistence.rst

@@ -603,7 +603,7 @@ class instead of ``UntypedPersistentActor`` on the sending side.  It takes care
 have not been confirmed within a configurable timeout.
 
 The state of the sending actor, including which messages have been sent that have not been
-confirmed by the recepient must be persistent so that it can survive a crash of the sending actor
+confirmed by the recipient must be persistent so that it can survive a crash of the sending actor
 or JVM. The ``UntypedPersistentActorWithAtLeastOnceDelivery`` class does not persist anything by itself.
 It is your responsibility to persist the intent that a message is sent and that a confirmation has been
 received.

akka-docs/rst/scala/persistence-query.rst

@@ -157,22 +157,22 @@ specialised query object, as demonstrated in the sample below:
 
 Performance and denormalization
 ===============================
-When building systems using :ref:`event-sourcing-scala` and CQRS (`Command & Query Responsibility Segragation`_) techniques
+When building systems using :ref:`event-sourcing-scala` and CQRS (`Command & Query Responsibility Segregation`_) techniques
 it is tremendously important to realise that the write-side has completely different needs from the read-side,
 and separating those concerns into datastores that are optimised for either side makes it possible to offer the best
-expirience for the write and read sides independently.
+experience for the write and read sides independently.
 
 For example, in a bidding system it is important to "take the write" and respond to the bidder that we have accepted
 the bid as soon as possible, which means that write-throughput is of highest importance for the write-side – often this
-means that data stores which are able to scale to accomodate these requirements have a less expressive query side.
+means that data stores which are able to scale to accommodate these requirements have a less expressive query side.
 
-On the other hand the same application may have some complex statistics view or we may have analists working with the data
+On the other hand the same application may have some complex statistics view or we may have analysts working with the data
 to figure out best bidding strategies and trends – this often requires some kind of expressive query capabilities like
 for example SQL or writing Spark jobs to analyse the data. Therefore the data stored in the write-side needs to be
 projected into the other read-optimised datastore.
 
 .. note::
-  When refering to **Materialized Views** in Akka Persistence think of it as "some persistent storage of the result of a Query".
+  When referring to **Materialized Views** in Akka Persistence think of it as "some persistent storage of the result of a Query".
   In other words, it means that the view is created once, in order to be afterwards queried multiple times, as in this format
   it may be more efficient or interesting to query it (instead of the source events directly).
 
@@ -212,7 +212,7 @@ into the other datastore:
 
 .. includecode:: code/docs/persistence/query/PersistenceQueryDocSpec.scala#projection-into-different-store-actor
 
-.. _Command & Query Responsibility Segragation: https://msdn.microsoft.com/en-us/library/jj554200.aspx
+.. _Command & Query Responsibility Segregation: https://msdn.microsoft.com/en-us/library/jj554200.aspx
 
 .. _read-journal-plugin-api-scala:
 

akka-docs/rst/scala/persistence-schema-evolution.rst

@@ -136,7 +136,7 @@ As you can see, the ``PersistentMessage`` acts as an envelope around the payload
 origin of the event (``persistenceId``, ``sequenceNr`` and more).
 
 More advanced techniques (e.g. :ref:`remove-event-class-scala`) will dive into using the manifests for increasing the
-flexibility of the persisted vs. exposed types even more. Hhowever for now we will focus on the simpler evolution techniques,
+flexibility of the persisted vs. exposed types even more. However for now we will focus on the simpler evolution techniques,
 concerning simply configuring the payload serializers.
 
 By default the ``payload`` will be serialized using Java Serialization. This is fine for testing and initial phases

akka-docs/rst/scala/persistence.rst

@@ -596,7 +596,7 @@ trait to your ``PersistentActor`` on the sending side.  It takes care of re-send
 have not been confirmed within a configurable timeout.
 
 The state of the sending actor, including which messages have been sent that have not been
-confirmed by the recepient must be persistent so that it can survive a crash of the sending actor
+confirmed by the recipient must be persistent so that it can survive a crash of the sending actor
 or JVM. The ``AtLeastOnceDelivery`` trait does not persist anything by itself. It is your
 responsibility to persist the intent that a message is sent and that a confirmation has been
 received.