diff --git a/akka-actor/src/main/scala/akka/routing/OptimalSizeExploringResizer.scala b/akka-actor/src/main/scala/akka/routing/OptimalSizeExploringResizer.scala index a38e00a986..fc3104c45d 100644 --- a/akka-actor/src/main/scala/akka/routing/OptimalSizeExploringResizer.scala +++ b/akka-actor/src/main/scala/akka/routing/OptimalSizeExploringResizer.scala @@ -109,7 +109,7 @@ case object OptimalSizeExploringResizer { * The memory usage is O(n) where n is the number of sizes * you allow, i.e. upperBound - lowerBound. * - * For documentation about the the parameters, see the reference.conf - + * For documentation about the parameters, see the reference.conf - * akka.actor.deployment.default.optimal-size-exploring-resizer * */ diff --git a/akka-cluster-tools/src/main/scala/akka/cluster/client/ClusterClient.scala b/akka-cluster-tools/src/main/scala/akka/cluster/client/ClusterClient.scala index 380c68a102..fa393b7e59 100644 --- a/akka-cluster-tools/src/main/scala/akka/cluster/client/ClusterClient.scala +++ b/akka-cluster-tools/src/main/scala/akka/cluster/client/ClusterClient.scala @@ -592,7 +592,7 @@ object ClusterReceptionist { * 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. * */ diff --git a/akka-docs/rst/java/cluster-client.rst b/akka-docs/rst/java/cluster-client.rst index c8820bf5cf..3676991a9f 100644 --- a/akka-docs/rst/java/cluster-client.rst +++ b/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 diff --git a/akka-docs/rst/java/lambda-persistence.rst b/akka-docs/rst/java/lambda-persistence.rst index 89285a64f7..5cd6c006f1 100644 --- a/akka-docs/rst/java/lambda-persistence.rst +++ b/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. diff --git a/akka-docs/rst/java/stream/stream-cookbook.rst b/akka-docs/rst/java/stream/stream-cookbook.rst index bdd138d62e..8caa817f77 100644 --- a/akka-docs/rst/java/stream/stream-cookbook.rst +++ b/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. diff --git a/akka-docs/rst/project/migration-guide-2.3.x-2.4.x.rst b/akka-docs/rst/project/migration-guide-2.3.x-2.4.x.rst index 550fd5d62b..f3e239b101 100644 --- a/akka-docs/rst/project/migration-guide-2.3.x-2.4.x.rst +++ b/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 diff --git a/akka-docs/rst/scala/cluster-client.rst b/akka-docs/rst/scala/cluster-client.rst index 6192e4271a..9060df2e0f 100644 --- a/akka-docs/rst/scala/cluster-client.rst +++ b/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 diff --git a/akka-docs/rst/scala/stream/stream-cookbook.rst b/akka-docs/rst/scala/stream/stream-cookbook.rst index 30abe02653..ad03155d7a 100644 --- a/akka-docs/rst/scala/stream/stream-cookbook.rst +++ b/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. diff --git a/akka-http-core/src/test/scala/akka/http/impl/engine/server/PrepareRequestsSpec.scala b/akka-http-core/src/test/scala/akka/http/impl/engine/server/PrepareRequestsSpec.scala index a487eb0d31..2ae524a0c4 100644 --- a/akka-http-core/src/test/scala/akka/http/impl/engine/server/PrepareRequestsSpec.scala +++ b/akka-http-core/src/test/scala/akka/http/impl/engine/server/PrepareRequestsSpec.scala @@ -85,7 +85,7 @@ class PrepareRequestsSpec extends AkkaSpec { val entitySub = entityProbe.expectSubscription() // the bug happens when both the client has signalled demand - // and the the streamed entity has + // and the streamed entity has upstreamSub.request(1) entitySub.request(1) diff --git a/akka-http-testkit/src/main/scala/akka/http/javadsl/testkit/TestResponse.scala b/akka-http-testkit/src/main/scala/akka/http/javadsl/testkit/TestResponse.scala index acbc70dbf3..ff256cb49c 100644 --- a/akka-http-testkit/src/main/scala/akka/http/javadsl/testkit/TestResponse.scala +++ b/akka-http-testkit/src/main/scala/akka/http/javadsl/testkit/TestResponse.scala @@ -35,12 +35,12 @@ abstract class TestResponse(_response: HttpResponse, awaitAtMost: FiniteDuration lazy val response: HttpResponse = _response.withEntity(entity) /** - * Returns the media-type of the the response's content-type + * Returns the media-type of the response's content-type */ def mediaType: MediaType = extractFromResponse(_.entity.contentType.mediaType) /** - * Returns a string representation of the media-type of the the response's content-type + * Returns a string representation of the media-type of the response's content-type */ def mediaTypeString: String = mediaType.toString diff --git a/akka-persistence/src/main/scala/akka/persistence/journal/ReplayFilter.scala b/akka-persistence/src/main/scala/akka/persistence/journal/ReplayFilter.scala index 91add5a780..87e6e68467 100644 --- a/akka-persistence/src/main/scala/akka/persistence/journal/ReplayFilter.scala +++ b/akka-persistence/src/main/scala/akka/persistence/journal/ReplayFilter.scala @@ -14,7 +14,7 @@ import scala.collection.mutable.LinkedHashSet /** * INTERNAL API * - * Detect corrupt event stream during replay. It uses the the writerUuid and the + * Detect corrupt event stream during replay. It uses the writerUuid and the * sequenceNr in the replayed events to find events emitted by overlapping writers. */ private[akka] object ReplayFilter { diff --git a/akka-stream/src/main/scala/akka/stream/javadsl/Source.scala b/akka-stream/src/main/scala/akka/stream/javadsl/Source.scala index 09fe8ebd7b..c929f46095 100644 --- a/akka-stream/src/main/scala/akka/stream/javadsl/Source.scala +++ b/akka-stream/src/main/scala/akka/stream/javadsl/Source.scala @@ -111,7 +111,7 @@ object Source { * `ConcurrentModificationException` or other more subtle errors may occur. */ def from[O](iterable: java.lang.Iterable[O]): javadsl.Source[O, NotUsed] = { - // this adapter is not immutable if the the underlying java.lang.Iterable is modified + // this adapter is not immutable if the underlying java.lang.Iterable is modified // but there is not anything we can do to prevent that from happening. // ConcurrentModificationException will be thrown in some cases. val scalaIterable = new immutable.Iterable[O] {