raboof/pekko
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions 10

Cluster aware routers for typed #26355

Browse source
This commit is contained in:
Johan Andrén 2019-07-15 15:25:00 +02:00 • committed by GitHub
parent d2f5d2daa3
commit f0e42d2b9c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
12 changed files with 447 additions and 57 deletions
Download patch file Download diff file Expand all files Collapse all files

13
akka-docs/src/main/paradox/typed/actor-discovery.md
View file

@ -73,8 +73,15 @@ sends a `Ping` message and when receiving the `Pong` reply it stops.
## Cluster Receptionist
The `Receptionist` also works in a cluster, an actor registered to the receptionist will appear in the receptionist of the other nodes of the cluster.
The `Receptionist` also works in a cluster, an actor registered to the receptionist will appear in the receptionist
of the other nodes of the cluster.
The state for the receptionist is propagated via @ref:[distributed data](../distributed-data.md) which means that each node will eventually reach the same set of actors per `ServiceKey`.
The state for the receptionist is propagated via @ref:[distributed data](../distributed-data.md) which means that each node
will eventually reach the same set of actors per `ServiceKey`.
One important difference from a local only receptions is the serialisation concerns, all messages sent to and back from an actor on another node must be serializable, see @ref:[clustering](cluster.md#serialization).
`Subscription`s and `Find` queries to a clustered receptionist will keep track of cluster reachability and only list
registered actors that are reachable. The full set of actors, including unreachable ones, is available through
@scala[`Listing.allServiceInstances`]@java[`Listing.getAllServiceInstances`].
One important difference from local only receptions are the serialization concerns, all messages sent to and back from
an actor on another node must be serializable, see @ref:[clustering](cluster.md#serialization).

16
akka-docs/src/main/paradox/typed/routers.md
View file

@ -43,12 +43,16 @@ Java
The group router is created with a `ServiceKey` and uses the receptionist (see @ref:[Receptionist](actor-discovery.md#receptionist)) to discover
available actors for that key and routes messages to one of the currently known registered actors for a key.
Since the receptionist is used this means the group router is cluster aware out of the box and will pick up routees
registered on any node in the cluster (there is currently no logic to avoid routing to unreachable nodes, see [#26355](https://github.com/akka/akka/issues/26355)).
Since the receptionist is used this means the group router is cluster aware out of the box. The router route
messages to registered actors on any node in the cluster that is reachable. If no reachable actor exists the router
will fallback and route messages to actors on nodes marked as unreachable.
It also means that the set of routees is eventually consistent, and that immediately when the group router is started
the set of routees it knows about is empty. When the set of routees is empty messages sent to the router is forwarded
to dead letters.
That the receptionist is used also means that the set of routees is eventually consistent, and that immediately when
the group router is started the set of routees it knows about is empty, until it has seen a listing from the receptionist
it stashes incoming messages and forwards them as soon as it gets a listing from the receptionist.
When the router has received a listing from the receptionist and the set of registered actors is empty the router will
drop them (published them to the event stream as `akka.actor.Dropped`).
Scala
: @@snip [RouterSpec.scala](/akka-actor-typed-tests/src/test/scala/docs/akka/typed/RouterSpec.scala) { #group }
@ -88,4 +92,4 @@ it will not give better performance to create more routees than there are thread
Since the router itself is an actor and has a mailbox this means that messages are routed sequentially to the routees
where it can be processed in parallel (depending on the available threads in the dispatcher).
In a high throughput use cases the sequential routing could be a bottle neck. Akka Typed does not provide an optimized tool for this.
In a high throughput use cases the sequential routing could be a bottle neck. Akka Typed does not provide an optimized tool for this.