Trying to understand if the following use of sender are safe.
I saw on some posts that closing over the sender is unsafe but if the call is by value, the sender() is evaluated when the method is called, correct?
are the following patterns safe?
1.
context.system.scheduler.scheduleOnce(1 second, self, "foo")(executor = context.dispatcher, sender = sender())
2.
def receive: Receive = {
case "Process" => context.become(processing(sender())
}
def processing(replyTo: ActorRef): receive = {...}
3.
def receive: Receive = {
case "Process" =>
context.actorOf(Props(new FooActor(replyTo = sender())))
}
When people say "closing" over the sender() function, they mean capturing the "this" reference into a lambda so that sender() will be called at a later time. This is not safe, because the value returned by sender() at a later time will not be the same as the value it currently has. If you capture (or "close over") the value currently returned by sender(), that is fine.
It is not always clear whether you are capturing sender() as a function or sender() as a value, because it will vary depending on whether you pass it to a call-by-value or a call-by-name function, as you have pointed out.
As Viktor points out in his comment:
1 and 2 are fine, because you are capturing the current value of sender().
3 is not safe, because "Props.apply" is a pass-by-name function, so you have inadvertently closed over sender() as a function rather than as a value.
I am not aware of any easy way to distinguish between these two cases, other than checking the docs (or clicking through in your IDE, if it supports it).
Related
I'm a novice to Akka actors, and I did some experiment as below to learn how actors work.
class RequestActor extends Actor with ActorLogging {
import RequestActor._
implicit val timeout = Timeout(15.seconds)
implicit val ec: ExecutionContext = context.dispatcher
override def receive: Receive = {
case Request(name) =>
// self ? TempRequest(TempRequest(name), xxx) pipeTo sender // Q1: if we reference `sender` here, which `sender` will be captured?
self ? TempRequest(name, sender) onComplete {
// val whichSender = sender // Q2: if we reference `sender` here, which `sender` will be captured?
case Success(TempResponse(msg, origin)) => origin ! HelloReply(msg)
case Failure(ex) => ???
}
case TempRequest(name, origin) =>
sender ! TempReply(s"hello, ${name}!", origin)
case _ =>
???
}
}
I understand we should prefer tell to ask. I made up this example trying to clear several confusions:
Q1 - Q2) I know sender is actually context.sender(). As the comment inside the code snippet, which sender will be captured?
My confusion is, will the sender be the right one resulting in the corresponding ask operation? Or could it be the sender of a message coming later?
3) Will actors be able to continue processing new messages while they're waiting for the reply of the ask?
From the experiment, it seems so. Could anyone please confirm this?
Thanks so much!
// self ? TempRequest(TempRequest(name), xxx) pipeTo sender // Q1: if we reference sender here, which sender will be captured?
The sender of message Request. This is not visible in your snippet.
From comment
self ? TempRequest(TempRequest(name), xxx) pipeTo sender. As this is an ask and waiting will occur, before the response is received, another message could be received by the actor, and thus cause the sender to be change. So, isn't it possible that the pipeTo sender causes the response to send to a wrong actor?
pipeTo pattern will register a callback for the future returned by ? or ask pattern. The callback will reference the sender returned by sender() at the time of callback registration, which is done in blocking manner when Request message is processed. Thus the sender() is the sender of Request message.
pipeTo excludes any possibility of actor context leakage and this is one of the reasons it should be used.
// val whichSender = sender // Q2: if we reference sender here, which sender will be captured?
This will actually cause a bug or leakage of actor context outside of an actor and must not be done. It can be done with a local reference like in following code
case Request(name) =>
val requestSender = context.sender()
self ? TempRequest(name) onComplete {
case Success(TempResponse(msg)) => requestSender ! HelloReply(msg)
}
From docs
When using future callbacks, such as onComplete, or map such as thenRun, or thenApply inside actors you need to carefully avoid closing over the containing actor’s reference, i.e. do not call methods or access mutable state on the enclosing actor from within the callback. This would break the actor encapsulation and may introduce synchronization bugs and race conditions because the callback will be scheduled concurrently to the enclosing actor. Unfortunately there is not yet a way to detect these illegal accesses at compile time.
And finally
3) Will actors be able to continue processing new messages while they're waiting for the reply of the ask?
Yes. There is no "waiting" process. It just registers a callback that is executed outside the actor. Thus the problem of possible actor context leakage.
Additionally,
You could use forward that preserves the original messages sender. And your code can be simplified as following
override def receive: Receive = {
case Request(name) =>
self.forward(TempRequest(name))
case TempRequest(name) =>
sender() ! HelloReply(s"hello, ${name}!"))
}
I am creating an actor via:
system.actorOf(Props(....))
or
system.actorOf(SmallestMailboxPool(instances).props(Props(....))).
I usually block the thread calling system.actorOf till actorSelection works.
Await.result(system.actorSelection("/user/" + name).resolveOne(), timeout.duration)
I am wondering if this is at all needed or I can immediately start using the actorRef and send (tell) messages to the actor/actor pool.
So the question boils down to, if I have an actorRef, does that mean the mailbox is already created or it might so happen that the messages I sent immediately after calling system.actorOf might get dropped?
If you drill down the the implementation of system.actorOf, you see a call to a method names makeChild. Internally, this utilizes a lengthy method on the ActorRefProvider trait (internally using LocalActorRefProvider) called actorOf. This rather lengthy method initializes the child actor. Relevant parts are:
val props2 =
// mailbox and dispatcher defined in deploy should override props
(if (lookupDeploy) deployer.lookup(path) else deploy) match {
case Some(d) ⇒
(d.dispatcher, d.mailbox) match {
case (Deploy.NoDispatcherGiven, Deploy.NoMailboxGiven) ⇒ props
case (dsp, Deploy.NoMailboxGiven) ⇒ props.withDispatcher(dsp)
case (Deploy.NoMailboxGiven, mbx) ⇒ props.withMailbox(mbx)
case (dsp, mbx) ⇒ props.withDispatcher(dsp).withMailbox(mbx)
}
case _ ⇒ props // no deployment config found
}
Or if a Router is explicitly provided:
val routerDispatcher = system.dispatchers.lookup(p.routerConfig.routerDispatcher)
val routerMailbox = system.mailboxes.getMailboxType(routerProps, routerDispatcher.configurator.config)
// routers use context.actorOf() to create the routees, which does not allow us to pass
// these through, but obtain them here for early verification
val routeeDispatcher = system.dispatchers.lookup(p.dispatcher)
val routeeMailbox = system.mailboxes.getMailboxType(routeeProps, routeeDispatcher.configurator.config)
new RoutedActorRef(system, routerProps, routerDispatcher, routerMailbox, routeeProps, supervisor, path).initialize(async)
Which means that once you get back an ActorRef, the mailbox has been initialized and you shouldn't be scared of sending it messages.
If you think about the semantics of what an ActorRef stands for, it would be a bit pointless to provide one with an ActorRef which is partly/not initialized. It would make system guarantees weak and would make the programmer think twice before passing messages, which is the opposite desire of the framework.
Hi I have two examples below within the receive method of an actor:
First one does not cache the sender actor for piping
val futureV = //Some function call that returns a Future
futureV.pipeTo(sender)
Second one takes the sender in a val first
val currentS=sender
val futureV = //Some function call that returns a Future
futureV.pipeTo(currentS)
My question is which one is the correct way to code and why?
They are the same. The sender is not going to change. pipeTo takes its argument by value, not by name.
While refactoring actor codes written by some other programmers, I encountered the usage of Future.onComplete callback within actor A, which goes against the best practice of using akka.pattern.pipe. It's a bad idea since it exposes the possibility of race conditions as the Future instance might be executed on a different thread.
Looking at the code, we see that there are neither sender nor any mutable vars being referred within the onComplete block so it seems pretty safe, at least for this specific occasion. However, one grey area that leaves me wondering are the references to url and especially text.
Is it possible that similar to the Closing Over An Akka Actor Sender In The Receive problem, a race condition happens such that at the time when the onComplete callback is invoked, the value of text already refers to a different actor message, causing all hells to break loose?
class B extends akka.actor.Actor {
def receive = {
case urlAndText: (String, String) => // do something
}
}
class A extends akka.actor.Actor {
case class Insert(url: String)
def fileUpload(content: String): String = ??? // returns the url of the uploaded content
val b = context.actorOf(Props(classOf[B]))
def receive = {
case text: String =>
Future {
fileUpload(text)
} onComplete {
case Success(url) =>
b ! Insert(url, text) // will this be
}
}
}
The reference to text should be fine. The difference is that each "instance" of text is a new variable bound to the scope of the current match block (starting at case text ...). Thus the Future created closes over the value of text just fine.
This is different from sender (or sender() when de-sugared) which is actually a method defined on the Actor trait which returns the ActorRef of the sender of the most recent message received by the actor on which it is called, and so can give a different value when called later (when the Future's onComplete is finally called).
You are right to be suspect about the use of onComplete, too. A better option would be:
case text: String =>
Future {
fileUpload(text)
} map { url =>
Insert(url, text)
} pipeTo b
Now failures will also be sent on to b, rather than being quietly swallowed.
In this case you aren't going to run into any race conditions although as you noted it is not a particularly good idea to structure code this way in general.
The references to both url and text are fine. The value for url is simply an extraction of a successfully completed Future and that doesn't change whether you're in an Actor or not. The value for text is an immutable string and closing over that value in a Future shouldn't cause problems because that string instance is immutable.
As you noted closing over sender or a var is a problem and that's because being mutable objects those values could change by the time the Future completes unlike immutable values which will remain constant even when you close over them.
I came across the following SIP:
http://docs.scala-lang.org/sips/pending/spores.html
As I was reading through, I came across this example:
def receive = {
case Request(data) =>
future {
val result = transform(data)
sender ! Response(result)
}
}
There was a description below in that article:
> Capturing sender in the above example is problematic, since it does not return a stable value. It is possible that the future’s body
> is executed at a time when the actor has started processing the next
> Request message which could be originating from a different actor. As
> a result, the Response message of the future might be sent to the
> wrong receiver.
I do not fully understand about this line "Capturing the sender in the above example is problematic...." Isn't that the case where in each request to the Actor (Request(data)) would create a Future block?
The creating of that Future block is synchronous which would mean that the sender reference is known at that time. It is only that the execution of that Future block is somehow scheduled to happen at a later point in time.
Is my understanding correct?
def receive = {
case Request(data) =>
future {
val result = transform(data)
sender ! Response(result)
}
}
Imagine that the line sender ! Response(result) is executed after 300 ms, exactly at the same time as the enclosing actor is handling another message, let's call it M. Because sender is a def, not a val, it's evaluated every time it's used. This means, that inside the future you've got the sender of the M message! You've responded not to the sender of the original message that created the Future, but to some other guy. To mitigate this problem you need to close over the value of the sender() def at the time of creation of the Future. Compare the original code with this:
def receive = {
case Request(data) =>
val client = sender()
future {
val result = transform(data)
client ! Response(result)
}
}
You have remembered the original sender, so everything is correct.
It's of utmost importance to NEVER execute any methods that depend on time (like sender) or change the actor's state in an asynchronous manner. If you need to change the actor's state in response to some asynchronous computation, you should send yourself a message from the future block.