Hi Alexandru,
your thinking seems to be natural, assuming that the Actor’s mailbox is
something that you can use and manage to your heart’s content. What we have
come to realize is that the Mailbox is just an infrastructure piece that has
the sole purpose of getting message to the actor, nothing else. This mechanism
should not depend on the actor’s state or be manageable, it just implements the
Actor Model. Therefore I would suggest that you place your logic in the actor
itself to make it explicit:
val nominal: Receive = {
case Request(x) =>
askSomeone(x) pipeTo self
context.become(blocked())
case x => doThings()
}
def blocked(queue: List[Request] = Nil, stored: Int = 0): Receive = {
case Result(y) =>
saveResult(y)
context.become(nominal)
case Status.Failure(ex) =>
// storing failed, do something appropriate
case x: Request =>
// other requests are either stored for later or denied at this point
// storage should be limited and explicit, e.g.
if (stored == max) sender() ! Denied
else context.become(blocked(x :: queue, stored + 1)
}
Keeping the actor responsive is the main goal here; whether you physically
block it in Await.result or logically by not consuming any messages does not
matter (of course Await.result also has global disadvantages in addition, as
you are aware).
Regards,
Roland
4 sep 2014 kl. 09:47 skrev Alexandru Nedelcu <a...@bionicspirit.com>:
> I wonder if there's any means for pausing the processing of an actor's
> mailbox of messages.
>
> Actually what I have in mind is blocking for the result of a `Future` without
> blocking the underlying thread per-se. It would be pretty cool if I had the
> possibility of doing a non-blocking `Await.result`.
>
> The use-case I have is this - say I want to save something in some database,
> but I don't want the actor to evolve and process new messages until that save
> operation is done. It's not something that happens frequently, so I'm not
> really worried about the latency, but doing `Await.result` just feels wrong.
>
> Of course, the alternative would be to communicate the demand back to the
> sender after the Future completes, as a sort of acknowledgement that it can
> send the next message. But it gets tricky in case the actor receives messages
> from multiple senders and blocking for the result just seems natural.
>
> And short of implementing my own half-backed buffer and state machine for
> incoming messages, how could I block the actor for the result of a Future
> without actually blocking the thread?
>
> --
> Alexandru Nedelcu
> www.bionicspirit.com
>
> PGP Public Key:
> https://bionicspirit.com/key.aexpk
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
