In classic, you could have actor A ask actor B, B could forward that request to C, and C would respond to A (on B's behalf).
“A” would ask with a timeout, and handle the same, but B would simply forward the request without any timeout management.
In typed, I understand that there would need to be an additional step of translating C's protocol to B's before replying to A.
How can I “forward” a request to another actor in Akka Typed without having a redundant ask/timeout in the communication between B and C in this example? Is this possible?
Forward was just convenience for propagating the sender reference. It’s the same as other.tell(msg, sender()).
In Typed there is no hidden sender, but it is included in the messages. Meaning that the intermediate actor can just other.tell(msg) and the other actor can reply msg.replyTo.tell(responseMsg) directly to the original sender.
Makes sense, and answers the question. But in practice there is a new catch when using Typed Actors, which your answer helped me to verbalise: Actors should only ever receive messages of their own protocol.
Back to the scenario of A -> B -> C -> A.
With Typed, I can no longer forward the message from B to C as-is, I have first have to convert it to the protocol of C. Likewise, C can’t send it back straight to A, because A expects an event message of B's protocol. Again, C first has to send it to B. B has to do the conversion in both directions.
Because B has to be the recipient of C's response, B becomes the replyTo of the “forwarded” message. Once B receives the response, how can B recover who A was? You could have a second replyTo that you pass back and forth, but that doesn’t seem to be a clean solution.
I guess it comes down to a case-by-case design of actors and their state. One of the prices to pay for Typed Actors, which leads to more solid coding principles and better explicit design decisions.
Depends on how isolated you want them to be. A could know about C’s reply type. It’s also possible to share message types between several behaviors if they are tightly coupled anyway.
I had similar impressions initially, but as per Patrik’s comment, there is the valid option of a “shared message protocol” in typed actors, which I think would work well for this type of interaction:
This option had went past me at first, so I do think it’s worth emphasizing. Some of my sample toy code (based on converting classic actors in the “Reactive Application Development” book to a typed actor implementation) is here:
In the code, there is a “protocol” object which defines the message protocol. (This is how it was done in the original classic actors of the book, see “RareBooksProtocol”)
Then 3 additional actors all import the protocol definition, and exchange messages based on the messages in the shared protocol object. It matches the A, B and C actor scenario I think.
My takeaway is that this shared protocol option is possible if the interaction pattern requires it, although prefer the protocol definition in the actor if things can be structured that way.