fix the the typo

akka-docs/rst/java/cluster-client.rst

@@ -56,7 +56,7 @@ to avoid inbound connections from other cluster nodes to the client, i.e.
 the ``sender()``, as seen by the destination actor, is not the client itself.
 The ``sender()`` of the response messages, as seen by the client, is ``deadLetters``
 since the client should normally send subsequent messages via the ``ClusterClient``.
-It is possible to pass the the original sender inside the reply messages if
+It is possible to pass the original sender inside the reply messages if
 the client is supposed to communicate directly to the actor in the cluster.
 
 While establishing a connection to a receptionist the ``ClusterClient`` will buffer

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

@@ -560,7 +560,7 @@ saved snapshot matches the specified ``SnapshotSelectionCriteria`` will replay a
 
   Since it is acceptable for some applications to not use any snapshotting, it is legal to not configure a snapshot store.
   However Akka will log a warning message when this situation is detected and then continue to operate until
-  an actor tries to store a snapshot, at which point the the operation will fail (by replying with an ``SaveSnapshotFailure`` for example).
+  an actor tries to store a snapshot, at which point the operation will fail (by replying with an ``SaveSnapshotFailure`` for example).
 
   Note that :ref:`cluster_sharding_java` is using snapshots, so if you use Cluster Sharding you need to define a snapshot store plugin.
 

akka-docs/rst/java/stream/stream-cookbook.rst

@@ -291,7 +291,7 @@ case: if the very first element is not yet available.
 We introduce a boolean variable ``waitingFirstValue`` to denote whether the first element has been provided or not
 (alternatively an :class:`Optional` can be used for ``currentValue`` or if the element type is a subclass of Object
 a null can be used with the same purpose). In the downstream ``onPull()`` handler the difference from the previous
-version is that we check if we have received the the first value and only emit if we have. This leads to that when the
+version is that we check if we have received the first value and only emit if we have. This leads to that when the
 first element comes in we must check if there possibly already was demand from downstream so that we in that case can
 push the element directly.
 

akka-docs/rst/project/migration-guide-2.3.x-2.4.x.rst

@@ -373,7 +373,7 @@ actor in cluster.
 
 In 2.4 the ``sender()`` of the response messages, as seen by the client, is ``deadLetters``
 since the client should normally send subsequent messages via the ``ClusterClient``.
-It is possible to pass the the original sender inside the reply messages if
+It is possible to pass the original sender inside the reply messages if
 the client is supposed to communicate directly to the actor in the cluster.
 
 Akka Persistence

akka-docs/rst/scala/cluster-client.rst

@@ -56,7 +56,7 @@ to avoid inbound connections from other cluster nodes to the client, i.e.
 the ``sender()``, as seen by the destination actor, is not the client itself.
 The ``sender()`` of the response messages, as seen by the client, is ``deadLetters``
 since the client should normally send subsequent messages via the ``ClusterClient``.
-It is possible to pass the the original sender inside the reply messages if
+It is possible to pass the original sender inside the reply messages if
 the client is supposed to communicate directly to the actor in the cluster.
 
 While establishing a connection to a receptionist the ``ClusterClient`` will buffer

akka-docs/rst/scala/stream/stream-cookbook.rst

@@ -284,7 +284,7 @@ case: if the very first element is not yet available.
 We introduce a boolean variable ``waitingFirstValue`` to denote whether the first element has been provided or not
 (alternatively an :class:`Option` can be used for ``currentValue`` or if the element type is a subclass of AnyRef
 a null can be used with the same purpose). In the downstream ``onPull()`` handler the difference from the previous
-version is that we check if we have received the the first value and only emit if we have. This leads to that when the
+version is that we check if we have received the first value and only emit if we have. This leads to that when the
 first element comes in we must check if there possibly already was demand from downstream so that we in that case can
 push the element directly.