Pattern for responding to a sharded actor (#27077)

This commit is contained in:
Christopher Batey 2019-07-05 09:29:23 +01:00 committed by Patrik Nordwall
parent 1dfe55fcc3
commit 7c151a4279
4 changed files with 106 additions and 1 deletions

View file

@ -122,3 +122,5 @@ time to keep the actor alive. Note that only messages sent through sharding are
to the `ActorRef` or messages that the actor sends to itself are not counted in this activity.
Passivation can be disabled by setting `akka.cluster.sharding.passivate-idle-entity-after = off`.
It is always disabled if @ref:[Remembering Entities](../cluster-sharding.md#remembering-entities) is enabled.

View file

@ -245,6 +245,24 @@ This can be used with any type of `Behavior`, including `receive`, `receiveMessa
* The `TimerScheduler` is bound to the lifecycle of the actor that owns it and it's cancelled automatically when the actor is stopped.
* `Behaviors.withTimers` can also be used inside `Behaviors.supervise` and it will automatically cancel the started timers correctly when the actor is restarted, so that the new incarnation will not receive scheduled messages from previous incarnation.
## Responding to a sharded actor
The normal pattern for expecting a reply is to include an @apidoc[akka.actor.typed.ActorRef] in the message, typically a message adapter. This can be used
for a sharded actor but if @scala[`ctx.self`]@java[`ctx.getSelf()`] is sent and the sharded actor is moved or passivated then the reply
will sent to dead letters.
An alternative is to send the `entityId` in the message and have the reply sent via sharding:
Scala
: @@snip [sharded.response](/akka-cluster-sharding-typed/src/test/scala/docs/akka/cluster/sharding/typed/ShardingCompileOnlySpec.scala) { #sharded-response }
Java
: @@snip [sharded.response](/akka-cluster-sharding-typed/src/test/java/jdocs/akka/cluster/sharding/typed/ShardingReplyCompileOnlyTest.java) { #sharded-response }
A disadvantage is that a message adapter can't be used so the response has to be in the protocol of the actor being responded to. Additionally the `EntityTypeKey`
could be included in the message if it is not known statically.
### Schedule periodically
Scheduling of recurring messages can have two different characteristics: