From d332428fac47934a2105760b60e58c49afeaf429 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B6ren=20Brunk?= Date: Mon, 28 Mar 2016 14:41:57 +0200 Subject: [PATCH] Fix a few typos in the docs --- .../rst/general/message-delivery-reliability.rst | 2 +- akka-docs/rst/java/persistence-query.rst | 12 ++++++------ akka-docs/rst/java/persistence-schema-evolution.rst | 2 +- akka-docs/rst/java/persistence.rst | 2 +- akka-docs/rst/scala/persistence-query.rst | 12 ++++++------ akka-docs/rst/scala/persistence-schema-evolution.rst | 2 +- akka-docs/rst/scala/persistence.rst | 2 +- 7 files changed, 17 insertions(+), 17 deletions(-) diff --git a/akka-docs/rst/general/message-delivery-reliability.rst b/akka-docs/rst/general/message-delivery-reliability.rst index 57d48c50ad..2839c495f0 100644 --- a/akka-docs/rst/general/message-delivery-reliability.rst +++ b/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. diff --git a/akka-docs/rst/java/persistence-query.rst b/akka-docs/rst/java/persistence-query.rst index e4f7cdba53..376ea26504 100644 --- a/akka-docs/rst/java/persistence-query.rst +++ b/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: diff --git a/akka-docs/rst/java/persistence-schema-evolution.rst b/akka-docs/rst/java/persistence-schema-evolution.rst index dd258b7780..a3f33f515e 100644 --- a/akka-docs/rst/java/persistence-schema-evolution.rst +++ b/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 diff --git a/akka-docs/rst/java/persistence.rst b/akka-docs/rst/java/persistence.rst index 4c8aace74f..c030e869d5 100644 --- a/akka-docs/rst/java/persistence.rst +++ b/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. diff --git a/akka-docs/rst/scala/persistence-query.rst b/akka-docs/rst/scala/persistence-query.rst index f9723ef487..6026cf38f9 100644 --- a/akka-docs/rst/scala/persistence-query.rst +++ b/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: diff --git a/akka-docs/rst/scala/persistence-schema-evolution.rst b/akka-docs/rst/scala/persistence-schema-evolution.rst index 878e5259d5..0d7e73d84e 100644 --- a/akka-docs/rst/scala/persistence-schema-evolution.rst +++ b/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 diff --git a/akka-docs/rst/scala/persistence.rst b/akka-docs/rst/scala/persistence.rst index 80be112ba5..ef1601c151 100644 --- a/akka-docs/rst/scala/persistence.rst +++ b/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.