I think Richard's suggestion is a good one. a simple implementation
might be:
class SomeActor extends Actor with Stash {
def doThing: Future[Result] = ???
def waiting = {
case Start =>
doThing pipeTo self // execute doThing, and send the result
back to the actor
become(running)
}
def running = {
case result: Result =>
// do something with the result
unstashAll()
become(waiting)
case _ =>
try { stash() }
catch {
case ex: StashOverflowException => sender() ! Error // too
much work queued up! let the sender know.
}
}
def receive = waiting
}
note the check for stash overflow. as you brought up earlier, messages
could be received by your actor at a faster rate than your actor can
process them. we can queue these messages up for orderly processing,
but eventually we will run out of memory if we just blindly accept
messages forever. to guard against this scenario, we signal to the
sender if we have too many queued messages. signaling to the sender in
this way is called backpressure. the sender will then need to make a
decision whether to retry or give up.
Richard also discussed using FSM. for a single purpose actor (that is,
an actor that only exists to execute doThing method and then process the
result) i think the above is a good solution. If your actor is more
complicated, then you might want to learn about FSM. The decision
between become() and FSM is a bit of a personal taste, but my thought
process is:
1) does the actor only need to process messages as a linear sequence of
steps? use become() and stash(), or simply keep state manually using
actor-local variables.
2) does the actor have branching behavior (in other words, multiple
states)? maybe use FSM, but if there are only two states, then become()
is probably easier.
3) does the behavior have 3 or more states? almost always use FSM.
-Michael
On 10/13/14 07:47, Richard Rodseth wrote:
Let's see what the experts say, but you could put the actor in a
"suspended" state using become(). Take a look at the link I provided
and see if that makes any sense.
On Mon, Oct 13, 2014 at 7:39 AM, Joheinz <[email protected]
<mailto:[email protected]>> wrote:
What I had been trying to express (non-native speaker), is that
when the actor processes/creates a future in the receive method,
it will very quickly proceed the next message, without a guarantee
that the future is completed. What I somehow would like to
achieve: avoid Await.result due to its blocking characteristics,
but also prevent the actor from creating to much noise. I do not
know it is possible, but I imagine that I could somehow tell the
mailbox of the actor to proceed only when the future the actor had
created is completed.
Hopefully that makes more sense,
Markus
2014-10-13 16:28 GMT+02:00 Richard Rodseth <[email protected]
<mailto:[email protected]>>:
I don't follow your snippet. Receive is a partial function
from Any to Unit, so it doesn't return anything.
def receive = {
case Start => {
val futureResult = someFuture
someFuture pipeTo sender
}
}
You don't need to add an ask- you can just pipe someFuture to
self or the sender. The result will be queued in the sender's
mailbox when the future completes.
If you're careful about "closing over self" you can also
implement future.onComplete within the receive block.
If the sender is sensitive to the order of messages received,
it can use become() to change states or use the FSM trait.
http://letitcrash.com/post/54507231889/2-2-spotlight-simpler-use-of-stash
Hope this helps.
On Mon, Oct 13, 2014 at 6:47 AM, Joheinz
<[email protected] <mailto:[email protected]>> wrote:
Hi *,
Let's say I have an actor which receives a message Start
and is processing this message asynchrounously.
someActor ! start
class SomeActor {
def receive = {
case Start =>
for {
_ <- someFuture
} yield ()
}
Because processing of Start happens asynchronous it could
be that SomeActor receives more messages before the
processing of start is completed.
What would be my options to improve this behaviour?
- I could use Await.result - which does not seem to be a
reasonable option
- I could use the ask pattern and pipe the response back
to the sender. In that case what would happen if other
actors send me messages?
Are there any other ways to deal with this situation? I am
concerned that messages arrive when the actor is not in a
stable state yet, and I would like to prevent this.
Thanks,
Markus
--
>>>>>>>>>> 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
[email protected]
<mailto:[email protected]>.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
>>>>>>>>>> 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 [email protected]
<mailto:[email protected]>.
To post to this group, send email to
[email protected] <mailto:[email protected]>.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
>>>>>>>>>> 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 [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
>>>>>>>>>> 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 [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
