Merge pull request #19211 from akka/wip-19201-max-pools-size-patriknw

=act #19201 improve configuration of thread-pool-executor

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

@@ -350,11 +350,11 @@ Inspecting cluster sharding state
 ---------------------------------
 Two requests to inspect the cluster state are available:
 
-`ClusterShard.GetShardRegionState` which will return a `ClusterShard.ShardRegionState` that contains
-the `ShardId`s running in a Region and what `EntityId`s are alive for each of them.
+``ClusterShard.GetShardRegionState`` which will return a ``ClusterShard.ShardRegionState`` that contains
+the identifiers of the shards running in a Region and what entities are alive for each of them.
 
-`ClusterShard.GetClusterShardingStats` which will query all the regions in the cluster and return
-a `ClusterShard.ClusterShardingStats` containing the `ShardId`s running in each region and a count
+``ClusterShard.GetClusterShardingStats`` which will query all the regions in the cluster and return
+a ``ClusterShard.ClusterShardingStats`` containing the identifiers of the shards running in each region and a count
 of entities that are alive in each shard.
 
 The purpose of these messages is testing and monitoring, they are not provided to give access to

akka-docs/rst/scala/code/docs/dispatcher/DispatcherDocSpec.scala

@@ -93,6 +93,17 @@ object DispatcherDocSpec {
     }
     //#my-thread-pool-dispatcher-config
 
+    //#fixed-pool-size-dispatcher-config
+    blocking-io-dispatcher {
+      type = Dispatcher
+      executor = "thread-pool-executor"
+      thread-pool-executor {
+        fixed-pool-size = 32
+      }
+      throughput = 1
+    }
+    //#fixed-pool-size-dispatcher-config
+
     //#my-pinned-dispatcher-config
     my-pinned-dispatcher {
       executor = "thread-pool-executor"
@@ -268,11 +279,19 @@ class DispatcherDocSpec extends AkkaSpec(DispatcherDocSpec.config) {
     val dispatcher = system.dispatchers.lookup("my-dispatcher-bounded-queue")
   }
 
+  "defining fixed-pool-size dispatcher" in {
+    val context = system
+    //#defining-fixed-pool-size-dispatcher
+    val myActor =
+      context.actorOf(Props[MyActor].withDispatcher("blocking-io-dispatcher"), "myactor2")
+    //#defining-fixed-pool-size-dispatcher
+  }
+
   "defining pinned dispatcher" in {
     val context = system
     //#defining-pinned-dispatcher
     val myActor =
-      context.actorOf(Props[MyActor].withDispatcher("my-pinned-dispatcher"), "myactor2")
+      context.actorOf(Props[MyActor].withDispatcher("my-pinned-dispatcher"), "myactor3")
     //#defining-pinned-dispatcher
   }
 

akka-docs/rst/scala/dispatchers.rst

@@ -139,6 +139,15 @@ There are 3 different types of message dispatchers:
 More dispatcher configuration examples
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
+
+Configuring a dispatcher with fixed thread pool size, e.g. for actors that perform blocking IO:
+
+.. includecode:: ../scala/code/docs/dispatcher/DispatcherDocSpec.scala#fixed-pool-size-dispatcher-config
+
+And then using it:
+
+.. includecode:: ../scala/code/docs/dispatcher/DispatcherDocSpec.scala#defining-fixed-pool-size-dispatcher
+
 Configuring a ``PinnedDispatcher``:
 
 .. includecode:: ../scala/code/docs/dispatcher/DispatcherDocSpec.scala#my-pinned-dispatcher-config

akka-docs/rst/scala/persistence.rst

@@ -260,7 +260,7 @@ When sending two commands to this ``PersistentActor``, the persist handlers will
 .. includecode:: code/docs/persistence/PersistenceDocSpec.scala#nested-persist-persist-caller
 
 First the "outer layer" of persist calls is issued and their callbacks are applied. After these have successfully completed,
- the inner callbacks will be invoked (once the events they are persisting have been confirmed to be persisted by the journal).
+the inner callbacks will be invoked (once the events they are persisting have been confirmed to be persisted by the journal).
 Only after all these handlers have been successfully invoked will the next command be delivered to the persistent Actor.
 In other words, the stashing of incoming commands that is guaranteed by initially calling ``persist()`` on the outer layer
 is extended until all nested ``persist`` callbacks have been handled.
@@ -577,9 +577,9 @@ received.
 
 .. note::
 
-At-least-once delivery implies that original message sending order is not always preserved,
-and the destination may receive duplicate messages.
-Semantics do not match those of a normal :class:`ActorRef` send operation:
+  At-least-once delivery implies that original message sending order is not always preserved,
+  and the destination may receive duplicate messages.
+  Semantics do not match those of a normal :class:`ActorRef` send operation:
 
   * it is not at-most-once delivery