I have an actor that represent worker for heavy long time job:
class Worker extends Actor{
override def receive: Receive = {
case "doJob" =>
Thread.sleep(999999)
sender ! "JobResult"
}
}
I would have limit job queue and explicitly reject user, if queue is full. What is best practice to implement this logic. Should I use bounding mailboxes or some dispatcher, that monitoring job queue? Something like this:
class Dispatcher(worker:ActorRef) extends Actor{
val MAX_JOBS = 10
var jobs = 0
override def receive: Receive = {
case "newJob" =>
if (jobs >= MAX_JOBS) sender ! "Try later"
jobs+=1
worker ! "doJob"
case "JobResult" =>
jobs-=1
}
}
Also I not sure how to properly handle failures in that case...
I think the best practice is to use a bounded mailbox for the worker actor.
Then you can configure the bounded in a configuration like this:
bounded-mailbox { mailbox-type = "akka.dispatch.BoundedMailbox"
mailbox-capacity = 1000 mailbox-push-timeout-time = 10s }
akka.actor.mailbox.requirements {
"akka.dispatch.BoundedMessageQueueSemantics" = bounded-mailbox
}
You can also specify the type of mailbox you want (from the built-in types) or create your own custom mailbox with its own traits and specification. (which messages are treated first etc..)
I think that in your scenario it is best:
1. To create your own mailbox with its own error mechanism and custom cleanup/bounding limitations. (based on bounded mailbox traits)
3. Attach your dispatcher to the custom mailbox you created through configuration.
Related
I hope it is ok to ask this. I am using akka and have two actors, where one is initiated/created fast and the other much slower. The rapidly created one asks the other for something (ask-pattern), and the message is sent to dead letters since the other is not initiated yet. What is the preferred way of making an actor waiting with sending it´s message? I am not so eager to make an actor sleep or something without knowing there is no other way.
I would use the functionality become()/unbecome() Akka provides for Actors. I am assuming in the following code that the slowActor gets created by the fastActor. The trick here is that the fastActor will have two behaviors: one for when the slowActor is getting initiated and the other for when it's ready to do some work. When slowActor is ready, it will send a message to the fastActor to advertise that is able to receive messages. fastActor will be watching slowActor and if it gets terminated, it will change its behavior again. What to do next would be up to your solution.
Here is a mock code as a guide (I have not compiled the code and it might contain some errors):
case object Ready
case object DoWork
case object WorkDone
class FastActor extends Actor with ActorLogging {
val slowActor = context.actorOf(SlowActor.props)
context.watch(slowActor)
def receive = slowActorNotReadyBehavior
def slowActorNotReadyBehavior = {
case DoWork => log.warning("Slow actor in not ready, I am sorry...")
case Ready => context.become(slowActorReadyBehavior)
}
def slowActorReadyBehavior = {
case DoWork => (slowActor ? DoWork).pipeTo(self)
case Terminated(ref) =>
log.error("Slow actor terminated")
context.unbecome()
//... do something with slowActor
}
}
class SlowActor extends Actor {
override def preStart = {
context.parent ! Ready
}
def receive = {
case DoWork =>
//do something
sender ! WorkDone
}
}
Can anyone explain how and when to use ActorIdentity with a good example?
From documents I can find that "There is a built-in Identify message that all Actors will understand and automatically reply to with a ActorIdentity message containing the ActorRef".
Does that statement mean obtained actor say actorSelector have ActorIdentity message wrapped in my actor?
ActorSelection actorSelector = getContext().actorSelection("/A/B/*");
When you send an Identify message to an ActorSelection the actor will respond, if it exists, with an ActorIdentity message.
If the actor exists the ActorIdentity message will contain a Some(actorRef). It is more efficient to send messages to ActorRefs than ActorSelections.
For example (from the manual):
class Follower extends Actor {
val identifyId = 1
context.actorSelection("/user/another") ! Identify(identifyId)
def receive = {
case ActorIdentity(`identifyId`, Some(ref)) =>
context.watch(ref)
context.become(active(ref))
case ActorIdentity(`identifyId`, None) => context.stop(self)
}
def active(another: ActorRef): Actor.Receive = {
case Terminated(`another`) => context.stop(self)
}
}
The section in the manual that covers this is called Identifying Actors via Actor Selection.
I am brand new to Akka but my understanding about the Stop directive is that it is used inside of SupervisorStrategies when the child should be considered permanently out of service, but there is a way to handle the total outage.
If that understanding is correct, then what I would like to do is have some kind of a “backup actor” that should be engaged after the normal/primary child is stopped and used from that point forward as a fallback. For example, say I have a parent actor who has a child actor - Notifier - whose job it is to send emails. If the Notifier truly dies (say, the underlying mail server goes offline), a backup to this actor might be another actor, say, QueueClient, that sends the notification request to a message broker, where the message will be queued up and replayed at a later time.
How can I define such a SupervisorStrategy to have this built in fault tolerance/actor backup inside of it? Please show code examples, its the only way I will learn!
Overriding Supervisor Strategies beyond the default directives is not commonly done, and not really necessary in your case. A solution would be to watch the child actor from the parent, and when the parent finds that the child is stopped, engage the backup actor.
import akka.actor.SupervisorStrategy.Stop
import akka.actor._
class Parent extends Actor {
var child: ActorRef = context.actorOf(Props[DefaultChild])
context.watch(child)
def receive = {
case Terminated(actor) if actor == child =>
child = context.actorOf(Props[BackupChild])
}
override def supervisorStrategy = OneForOneStrategy() {
case ex: IllegalStateException => Stop
}
}
class DefaultChild extends Actor {
def receive = { case _ => throw new IllegalStateException("whatever") }
}
class BackupChild extends Actor {
def receive = { case _ => }
}
I would like to create a minimal example of an actor that sends off a message to an actor and then waits for the response of that actor. The reason for this example is that I want to use it in my thesis in context of disussing the usage other language features (e.g., futures) instead of pure actors. So the point here is that it has to be an actor that waits for a message before processing anything else.
The idea I had was to demonstrate an actor that requests a file to be read from disk, then does some long computation and then waits for the read to finish.
What I have so far is the following:
import akka.actor.Actor
import akka.actor.ActorSystem
import akka.actor.Props
import scala.io.Source
case class FileContents(content: String)
class WorkerActor extends Actor
{
def receive =
{
case "compute" =>
println("Computing!")
// Create actor to read the file
val reader = context.actorOf(Props[ReadFileActor])
reader ! ReadFile("/home/christophe/code/thesis-example/src/main/resources/file.txt")
// Heavy computation
Thread.sleep(5000)
case FileContents(content) =>
println("Got file content:\n" + content)
// Continue computation.
}
}
case class ReadFile(path: String)
class ReadFileActor extends Actor
{
def receive =
{
case ReadFile(path) =>
var contents: String = ""
for (line <- Source.fromFile(path).getLines())
{
contents += line
}
sender ! FileContents(contents)
}
}
object Main extends App
{
val system = ActorSystem("HelloSystem")
val worker = system.actorOf(Props[WorkerActor], name = "worker")
worker ! "compute"
worker ! "compute"
}
But what happens here is that WorkerActor receives the compute message, and then starts a child actor to read in the file. After the heave computation it receives the second compute message instead. And finally receives the two messages from the ReadFile actor.
What I actually want to happen is that WorkerActor receives the compute message, does the heavy computation and then waits until he receives the FileContents message. Only after that it can receive any other message (i.e., the second compute message).
I have read the docs and searched around for examples but i cant seem to find anything on it.
Disclaimer: I am not using Akka except for this small example in context of my thesis.
Just create several (pool of) workers for several compute messages instead of one worker, smthng like:
object Main extends App {
val system = ActorSystem("HelloSystem")
val router = system.actorOf(RoundRobinPool(2).props(Props[Worker]), "router")
router ! "compute"
router ! "compute"
}
If you want second worker to be launched after first:
def receive = {
case "compute" => ...
case FileContents(content) =>
println("Got file content:\n" + content)
// Continue computation.
context.parent ! "compute" //send to the pool
}
...
//Main:
router ! "compute"
Another option is to remember sender of "compute" (it will be your Main) and send the response back to the top-level:
var main = _
def receive = {
case "compute" =>
...
main = sender
case FileContents(content) =>
...
main ! "ack"
}
//Main:
(router ? "compute") foreach (_ => router ! compute)
If you don't like future here - you may rewrite it with actor:
//Main
class MainActor extends Actor {
def receive = {
case "start" => router ! "compute"
case "ack" => router ! "compute"
}
}
P.S. Blocking computations inside actor should be managed properly or they may lead to thread starvation.
Sounds like what you want is to keep processing this message until you get a response. in other words block
class WorkerActor extends Actor {
def receive = {
case "compute" =>
println("Computing!")
// Create actor to read the file
val reader = context.actorOf(Props[ReadFileActor])
val future: Future[FileContents] =
(reader ? ReadFile("file.txt").mapTo[FileContents]
// Heavy computation
Thread.sleep(5000)
// this will block current thread and thus the actor,
// so it will not process any other messages until
// future is completed or time is out
Await.result(future, timeout)
}
}
BUT, this is considered as a very bad thing in actor lands.
When working with Actors, if an Actor needs to co-operate with multiple other Actors to fulfil a request then what's the recommended approach here? To be more precise, if Actor A (through processing message M) needs to retrieve information from Actor B + Actor C, then it can send messages asynchronously to Actor B + C, but how should it correlate the responses from Actor B + C to the original message M ?
I've looked at the Akka framework and can't see how this is done so have had to implement something myself whereby an Actor keeps track of what messages have been sent and attempts to correlate their responses back to the source message. I must be missing something as I would've thought that this type of behaviour would already be built into various Actor frameworks
Generally if you need to send a message and get a correlated response, you end up having to send some kind of nonce in the original message that the responder must return with its reply. This can be explicit or it can be supported in the messaging layer. Not sure about Akka, but that's how Erlang handles RPCs in OTP.
Just create a new actor and use that to preserve the context and stop it after a timeout or when it has performed the "join".
You can also use Future-composition instead of spawning an actor:
class A extends Actor {
def receive = {
case DoX(x) =>
val b = actorB ? DoYourPartOf(x) mapTo manifest[BResult]
val c = actorC ? DoYourPartOf(x) mapTo manifest[CResult]
b zip c map { case (b,c) => merge(b,c) } pipeTo sender
}
}
}
Or Dataflow:
class A extends Actor {
def receive = {
case DoX(x) => flow {
val b = actorB ? DoYourPartOf(x) mapTo manifest[BResult]
val c = actorC ? DoYourPartOf(x) mapTo manifest[CResult]
merge(b(),c())
} pipeTo sender
}
}
}