Actor interaction patterns docs for typed (#24404)
* Request response and actor-to-actor-ask * Outside of actor ask * Review feedback plus simplification of tell sample * ask and mention symbolic * Final sample and some proof reading feedback adressed * Tests should pass in InteractionPatternSpec * Incorrect comment removed * Made sure all scala samples execute, to protect from regression, added forward refereces in text * Use context logger * Some minor rewording * Feedback applied * Rebase fix * expectMessageType
This commit is contained in:
Johan Andrén
Patrik Nordwall
parent
7feca6638b
commit
06b36db458
3 changed files with 638 additions and 127 deletions
|
|
@ -1,54 +1,93 @@
|
|||
# Interaction Patterns
|
||||
|
||||
Interacting with an Actor in Akka Typed is done through an @scala[`ActorRef[T]`]@java[`ActorRef<T>`] where `T` is the type of messages the actor accepts, also known as the "protocol". This ensures that only the right kind of messages can be sent to an actor and also ensures no access to the Actor instance internals is available to anyone else but the Actor itself.
|
||||
Interacting with an Actor in Akka Typed is done through an @scala[`ActorRef[T]`]@java[`ActorRef<T>`] where `T` is the type of messages the actor accepts, also known as the "protocol". This ensures that only the right kind of messages can be sent to an actor and also that no one else but the Actor itself can access the Actor instance internals.
|
||||
|
||||
Message exchange with Actors follow a few common patterns, let's go through each one of them.
|
||||
|
||||
## Fire and Forget
|
||||
|
||||
The fundamental way to interact with an actor is through @scala["tell", which is so common that it has a special symbolic method name: `actorRef ! message`]@java[`actorRef.tell(message)`]. Sending a message to an actor like this can be done both from inside another actor and from any logic outside of the `ActorSystem`.
|
||||
The fundamental way to interact with an actor is through @scala["tell", which is so common that it has a special symbolic method name: `actorRef ! message`]@java[`actorRef.tell(message)`]. Sending a message with tell can safely be done from any thread.
|
||||
|
||||
Tell is asynchronous which means that the method returns right away and that when execution of the statement after it in the code is executed there is no guarantee that the message has been processed by the recipient yet. It also means there is no way to way to know if the processing succeeded or failed without additional interaction with the actor in question.
|
||||
Tell is asynchronous which means that the method returns right away, when the statement after it is executed there is no guarantee that the message has been processed by the recipient yet. It also means there is no way to know if the message was received, the processing succeeded or failed.
|
||||
|
||||
With the given protocol and actor behavior:
|
||||
|
||||
Scala
|
||||
: @@snip [InteractionPatternsSpec.scala]($akka$/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #fire-and-forget }
|
||||
: @@snip [InteractionPatternsSpec.scala]($akka$/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #fire-and-forget-definition }
|
||||
|
||||
Java
|
||||
: @@snip [InteractionPatternsTest.java]($akka$/akka-actor-typed-tests/src/test/java/jdocs/akka/typed/InteractionPatternsTest.java) { #fire-and-forget }
|
||||
: @@snip [InteractionPatternsTest.java]($akka$/akka-actor-typed-tests/src/test/java/jdocs/akka/typed/InteractionPatternsTest.java) { #fire-and-forget-definition }
|
||||
|
||||
|
||||
Fire and forget looks like this:
|
||||
|
||||
Scala
|
||||
: @@snip [InteractionPatternsSpec.scala]($akka$/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #fire-and-forget-doit }
|
||||
|
||||
Java
|
||||
: @@snip [InteractionPatternsTest.java]($akka$/akka-actor-typed-tests/src/test/java/jdocs/akka/typed/InteractionPatternsTest.java) { #fire-and-forget-doit }
|
||||
|
||||
|
||||
**Useful when:**
|
||||
|
||||
* When it is not critical to be sure that the message was processed
|
||||
* When there is no way to act on non successful delivery or processing
|
||||
* When we want to minimize the number of messages created to get higher throughput
|
||||
* It is not critical to be sure that the message was processed
|
||||
* There is no way to act on non successful delivery or processing
|
||||
* We want to minimize the number of messages created to get higher throughput (sending a response would require creating twice the number of messages)
|
||||
|
||||
**Problems:**
|
||||
|
||||
* Consistently higher rates of fire and forget to an actor than it process will make the inbox fill up and can in the worst case cause the JVM crash with an `OutOfMemoryError`
|
||||
* If the message got lost, we will not notice
|
||||
* If the inflow of messages is higher than the actor can process the inbox will fill up and can in the worst case cause the JVM crash with an `OutOfMemoryError`
|
||||
* If the message gets lost, the sender will not know
|
||||
|
||||
## Same protocol Request-Response
|
||||
## Request-Response
|
||||
|
||||
In many interactions a request is followed by a response back from the actor. In Akka Typed the recipient of responses has to be encoded as a field in the message itself, which the recipient can then use to send a response back. When the response message is already a part of the sending actor protocol we can simply use @scala[`ActorContext.self`]@java[`ActorContext.getSelf()`] when constructing the message.
|
||||
Many interactions between actors requires one or more response message being sent back from the receiving actor. A response message can be a result of a query, some form of acknowledgment that the message was received and processed or events that the request subscribed to.
|
||||
|
||||
In Akka Typed the recipient of responses has to be encoded as a field in the message itself, which the recipient can then use to send (tell) a response back.
|
||||
|
||||
With the following protocol:
|
||||
|
||||
Scala
|
||||
: @@snip [InteractionPatternsSpec.scala]($akka$/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #request-response-protocol }
|
||||
|
||||
Java
|
||||
: @@snip [InteractionPatternsTest.java]($akka$/akka-actor-typed-tests/src/test/java/jdocs/akka/typed/InteractionPatternsTest.java) { #request-response-protocol }
|
||||
|
||||
|
||||
The sender would use its own @scala[`ActorRef[Response]`]@java[`ActorRef<Response>`], which it can access through @scala[`ActorContext.self`]@java[`ActorContext.getSelf()`], for the `respondTo`.
|
||||
|
||||
Scala
|
||||
: @@snip [InteractionPatternsSpec.scala]($akka$/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #request-response-send }
|
||||
|
||||
Java
|
||||
: @@snip [InteractionPatternsTest.java]($akka$/akka-actor-typed-tests/src/test/java/jdocs/akka/typed/InteractionPatternsTest.java) { #request-response-send }
|
||||
|
||||
|
||||
On the receiving side the @scala[`ActorRef[response]`]@java[`ActorRef<Response>`] can then be used to send one or more responses back:
|
||||
|
||||
Scala
|
||||
: @@snip [InteractionPatternsSpec.scala]($akka$/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #request-response-respond }
|
||||
|
||||
Java
|
||||
: @@snip [InteractionPatternsTest.java]($akka$/akka-actor-typed-tests/src/test/java/jdocs/akka/typed/InteractionPatternsTest.java) { #request-response-respond }
|
||||
|
||||
TODO sample
|
||||
|
||||
**Useful when:**
|
||||
|
||||
* Subscribing to an actor that will send many response messages (of the same protocol) back
|
||||
* When communicating between a parent and its children, where the protocol can be made include the messages for the interaction
|
||||
* ???
|
||||
|
||||
* Subscribing to an actor that will send many response messages back
|
||||
|
||||
**Problems:**
|
||||
|
||||
* Often the response that the other actor wants to send back is not a part of the sending actor's protocol (see adapted request response or ask)
|
||||
* It is hard to detect and that a message request was not delivered or processed (see ask)
|
||||
* Unless the protocol already includes a way to provide context, for example a request id that is also sent in the response, it is not possible to tie an interaction to some specific context without introducing a new, separate, actor
|
||||
* Actors seldom have a response message from another actor as a part of their protocol (see @ref:[adapted response](#adapted-response))
|
||||
* It is hard to detect that a message request was not delivered or processed (see @ref:[ask](#request-response-with-ask-between-two-actors))
|
||||
* Unless the protocol already includes a way to provide context, for example a request id that is also sent in the
|
||||
response, it is not possible to tie an interaction to some specific context without introducing a new,
|
||||
separate, actor (see ask or per session child actor)
|
||||
|
||||
|
||||
## Adapted Response
|
||||
|
||||
Very often the receiving actor does not, and should, know of the protocol of the sending actor, and
|
||||
will respond with one or more messages that the sending actor cannot receive.
|
||||
Most often the sending actor does not, and should not, support receiving the response messages of another actor. In such cases we need to provide an `ActorRef` of the right type and adapt the response message to a type that the sending actor can handle.
|
||||
|
||||
Scala
|
||||
: @@snip [InteractionPatternsSpec.scala]($akka$/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #adapted-response }
|
||||
|
|
@ -71,16 +110,16 @@ the receiving actor. It's recommended to register the adapters in a top level
|
|||
`Behaviors.deferred` or constructor of `MutableBehavior` but it's possible to
|
||||
register them later also if needed.
|
||||
|
||||
The function is running in the receiving actor and can safely access state of it.
|
||||
The adapter function is running in the receiving actor and can safely access state of it, but if it throws an exception the actor is stopped.
|
||||
|
||||
**Useful when:**
|
||||
|
||||
* Subscribing to an actor that will send many response messages back
|
||||
* Translating between different actor message protocols
|
||||
* Subscribing to an actor that will send many response messages back
|
||||
|
||||
**Problems:**
|
||||
|
||||
* It is hard to detect that a message request was not delivered or processed (see ask)
|
||||
* It is hard to detect that a message request was not delivered or processed (see @ref:[ask](#request-response-with-ask-between-two-actors))
|
||||
* Only one adaption can be made per response message type, if a new one is registered the old one is replaced,
|
||||
for example different target actors can't have different adaption if they use the same response types, unless some
|
||||
correlation is encoded in the messages
|
||||
|
|
@ -89,65 +128,87 @@ The function is running in the receiving actor and can safely access state of it
|
|||
separate, actor
|
||||
|
||||
|
||||
## 1:1 Request-Response with ask between two actors
|
||||
## Request-Response with ask between two actors
|
||||
|
||||
In an interaction where there is a 1:1 mapping between a request and a response we can use `ask` on the `ActorContext` to interact with another actor.
|
||||
|
||||
The interaction has two steps, first we need to construct the outgoing message, to do that we need an @scala[`ActorRef[Response]`]@java[`ActorRef<Response>`] to put as recipient in the outgoing message. The second step is to transform the `Response` or the failure to produce a response, into a message that is part of the protocol of the sending actor.
|
||||
The interaction has two steps, first we need to construct the outgoing message, to do that we need an @scala[`ActorRef[Response]`]@java[`ActorRef<Response>`] to put as recipient in the outgoing message. The second step is to transform the successful `Response` or failure into a message that is part of the protocol of the sending actor.
|
||||
|
||||
TODO sample
|
||||
Scala
|
||||
: @@snip [InteractionPatternsSpec.scala]($akka$/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #actor-ask }
|
||||
|
||||
The function is running in the receiving actor and can safely access state of it.
|
||||
Java
|
||||
: @@snip [InteractionPatternsTest.java]($akka$/akka-actor-typed-tests/src/test/java/jdocs/akka/typed/InteractionPatternsTest.java) { #actor-ask }
|
||||
|
||||
|
||||
The response adapting function is running in the receiving actor and can safely access state of it, but if it throws an exception the actor is stopped.
|
||||
|
||||
**Useful when:**
|
||||
|
||||
* Single response queries
|
||||
* When an actor needs to know that the message was processed before continuing
|
||||
* An actor needs to know that the message was processed before continuing
|
||||
* To allow an actor to resend if a timely response is not produced
|
||||
* To keep track of outstanding requests and not overwhelm a recipient with messages (simple backpressure)
|
||||
* When some context should be attached to the interaction but the protocol does not support that (request id, what query the response was for)
|
||||
* To keep track of outstanding requests and not overwhelm a recipient with messages ("backpressure")
|
||||
* Context should be attached to the interaction but the protocol does not support that (request id, what query the response was for)
|
||||
|
||||
**Problems:**
|
||||
|
||||
* There can only be a single response to one `ask`
|
||||
* There can only be a single response to one `ask` (see @ref:[per session child Actor](#per-session-child-actor))
|
||||
* When `ask` times out, the receiving actor does not know and may still process it to completion, or even start processing it after the fact
|
||||
* Finding a good value for the timeout, especially when `ask` is triggers chained `ask`s in the receiving actor. You want a short timeout to be responsive and answer back to the requestor, but at the same time you do not want to have many false positives
|
||||
* Finding a good value for the timeout, especially when `ask` is triggers chained `ask`s in the receiving actor. You want a short timeout to be responsive and answer back to the requester, but at the same time you do not want to have many false positives
|
||||
|
||||
|
||||
## 1:1 Request-Response with ask from outside the ActorSystem
|
||||
## Request-Response with ask from outside the ActorSystem
|
||||
|
||||
In an interaction where there is a 1:1 mapping between a request and a response we can use @scala[`ActorRef.?` implicitly provided by `akka.actor.typed.scaladsl.AskPattern`]@java[`akka.actor.typed.javadsl.AskPattern.ask`] to send a message to an actor and get a @scala[`Future[Response]`]@java[`CompletionState[Response]`] back.
|
||||
Some times you need to interact with actors from outside of the actor system, this can be done with fire-and-forget as described above or through another version of `ask` that returns a @scala[`Future[Response]`]@java[`CompletionStage<Response>`] that is either completed with a succesful response or failed with a `TimeoutException` if there was no response within the specified timeout.
|
||||
|
||||
To do this we use @scala[`ActorRef.ask` (or the symbolic `ActorRef.?`) implicitly provided by `akka.actor.typed.scaladsl.AskPattern`]@java[`akka.actor.typed.javadsl.AskPattern.ask`] to send a message to an actor and get a @scala[`Future[Response]`]@java[`CompletionState[Response]`] back.
|
||||
|
||||
TODO sample
|
||||
Scala
|
||||
: @@snip [InteractionPatternsSpec.scala]($akka$/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #standalone-ask }
|
||||
|
||||
Java
|
||||
: @@snip [InteractionPatternsTest.java]($akka$/akka-actor-typed-tests/src/test/java/jdocs/akka/typed/InteractionPatternsTest.java) { #standalone-ask }
|
||||
|
||||
**Useful when:**
|
||||
|
||||
* Single response queries where the response should be passed on to some other actor
|
||||
* ???
|
||||
* Querying an actor from outside of the actor system
|
||||
|
||||
**Problems:**
|
||||
|
||||
* There can only be a single response to one `ask`
|
||||
* It is easy to accidentally close over and unsafely mutable state with the callbacks on the returned @scala[`Future`]@java[`CompletionStage`] as those will be executed on a different thread
|
||||
* There can only be a single response to one `ask` (see @ref:[per session child Actor](#per-session-child-actor))
|
||||
* When `ask` times out, the receiving actor does not know and may still process it to completion, or even start processing it after the fact
|
||||
|
||||
|
||||
## Per session child Actor
|
||||
|
||||
Keeping context for an interaction, or multiple interactions can be done by moving the work for one "session", into a child actor.
|
||||
In some cases a complete response to a request can only be created and sent back after collecting multiple answers from other actors. For these kinds of interaction it can be good to delegate the work to a per "session" child actor. The child could also contain arbitrary logic to implement retrying, failing on timeout, tail chopping, progress inspection etc.
|
||||
|
||||
TODO
|
||||
Note that this in fact essentially how `ask` is implemented, if all you need is a single response with a timeout it is better to use `ask`.
|
||||
|
||||
The child is created with the context it needs to do the work, including an `ActorRef` that it can respond to. When the complete result is there the child responds with the result and stops itself.
|
||||
|
||||
As the protocol of the session actor is not a public API but rather an implementation detail of the parent actor, it may not always make sense to have an explicit protocol and adapt the messages of the actors that the session actor interacts with. For this use case it is possible to express that the actor can receive any message (@scala[`Any`]@java[`Object`]).
|
||||
|
||||
Scala
|
||||
: @@snip [InteractionPatternsSpec.scala]($akka$/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #per-session-child }
|
||||
|
||||
Java
|
||||
: @@snip [InteractionPatternsTest.java]($akka$/akka-actor-typed-tests/src/test/java/jdocs/akka/typed/InteractionPatternsTest.java) { #per-session-child }
|
||||
|
||||
In an actual session child you would likely want to include some form of timeout as well (see @ref:[scheduling messages to self](#scheduling-messages-to-self)).
|
||||
|
||||
**Useful when:**
|
||||
|
||||
* A single incoming request should result in multiple interactions with other actors before a result can be built,
|
||||
for example aggregation of several results
|
||||
* Handle acknowledgement and retry messages for at-least-once delivery
|
||||
* ???
|
||||
* You need to handle acknowledgement and retry messages for at-least-once delivery
|
||||
|
||||
**Problems:**
|
||||
|
||||
* Children have lifecycles that must be managed to not create a resource leak
|
||||
* ???
|
||||
* Children have life cycles that must be managed to not create a resource leak, it can be easy to miss a scenario where the session actor is not stopped
|
||||
* It increases complexity, since each such child can execute concurrently with other children and the parent
|
||||
|
||||
## Scheduling messages to self
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue