Last time when we saw Actor messaging, we saw how fire-n-forget messages are sent (Meaning, we just send a message to the Actor but don’t expect a response from the Actor).
Technically, we fire messages to Actors for its side-effects ALL THE TIME. It is by design. Other than not responding, the target Actor could ALSO do the following with that message -
- Send a response back to the sender (in our case, the
TeacherActorwould respond with a quote back to theStudentActorOR - Forward a response back to some other Actor who might be the intended audience which in turn might respond/forward/have a side-effect. Routers and Supervisors are examples of those cases. (we’ll look at them very soon)
Request & Response
In this write-up, we’ll be focussing only on Point 1 - the request-response cycle.

The picture conveys what we are trying to achieve this time. For sake of brevity, I didn’t represent the ActorSystem, Dispatcher or Mailboxes in the picture.
- The
DriverAppsends anInitSignalmessage to theStudentActor. - The
StudentActorreacts to theInitSignalmessage and sends aQuoteRequestmessage to theTeacherActor. - The
TeacherActor, like we saw in the first discussion, responds with aQuoteResponse. - The
StudentActorjust logs theQuoteResponseto the console/logger.
We’ll also cook up a testcase to verify it.
Let’s look at these 4 points in detail now :
The DriverApp sends an InitSignal message to the StudentActor

By now, you would have guessed what would the DriverApp do. Just 4 things :
- Initialize the
ActorSystem
| |
- Create the
TeacherActor
| |
- Create the
StudentActor
| |
You’ll notice that I am passing in the ActorRef of the TeacherActor to the constructor of the StudentActor so that the StudentActor could use the ActorRef for sending messages to the TeacherActor. There are other ways to achieve this (like passing in the Props) but this method would come in handy when we look at Supervisors and Routers in the following write-ups. We’ll also be looking at child actors pretty soon but that wouldn’t semantically be the right approach here - Student creating Teacher doesn’t sound nice. Does it?
Lastly,
- The
DriverAppwould then send anInitSignalto theStudentActor, so that the StudentActor could start sending the QuoteRequest message to the TeacherActor.
| |
That’s pretty much the DriverClass. The Thread.sleep and the ActorSystem.shutdown are just to wait for a couple of seconds for the message sending to finish before we finally shut down the ActorSystem.
DriverApp.scala
| |
The StudentActor reacts to the InitSignal message and sends a QuoteRequest message to the TeacherActor
AND
The StudentActor receives the QuoteResponse from TeacherActor and just logs to the console/logger
Why did I combine Points 2 and 4? Because it is so simple you’ll hate me if I separate them.

So, Point 2 - the StudentActor receives the InitSignal message from the DriverApp and sends QuoteRequest to the TeacherActor.
| |
That’s it !!!
Point 4 - The StudentActor logs the message that it receives from the TeacherActor.

Just, as promised :
| |
I am sure you’d agree that it almost looks like pseudocode now.
So, the entire StudentActor class looks like :
StudentActor.scala
| |
The TeacherActor responds with a QuoteResponse.
This is the exact same code as we saw in the fire-n-forget write-up.
The TeacherActor receives a QuoteRequest message and sends QuoteResponse back.
TeacherActor.scala
| |
Testcases
Now, our testcase would simulate the DriverApp. Since, the StudentActor just logs the message and we won’t be able to assert on the QuoteResponse itself, we’ll just assert the presence of the log message in the EventStream (just like we talked last time)
So, our testcase looks like :
| |
Code
The entire project could be downloaded from github here.
Next up, we’ll see how to use schedulers in Akka and monitoring your Akka app using Kamon