On Mon, Apr 28, 2014 at 7:19 PM, Justin du coeur <[email protected]> wrote:
That's plausible for some use cases, but honestly -- it doesn't work for > most of the real code I deal with. The point of Actors is largely to > provide safe asynchronous operations for some state living in memory, and > most of the time a given chunk of state needs to expose a number of > different operations. Indeed, I can't think of any of my Actors that > expose *fewer* than three entry points. > > Moreover, those operations should typically expect to be called in an > interleaved fashion -- indeed, even an Actor that only accepts a single > entry point will get called by various callers at fairly random times. > (Which is why become() is tricky to use properly at the best of times -- > so far, I don't think I've ever actually used it outside of initialization.) > Personally I prefer to block actors waiting on Futures, as the queue of messages, the mailbox itself is non-blocking and so by blocking the actor you’re ensuring that pending messages won’t get dropped, otherwise you have to implement your own queue of sorts that queues messages until the Future you’re waiting on is completed and the type of the underlying mailbox configuration is not relevant anymore - of course, you need this in cases in which you must ensure that the actor’s state only evolves with a successful response. On context.become() it’s extremely awesome to model actors as finite-state machines and only evolve their state in response to messages. It’s easier to reason about things when you can say - the actor is in this state and can process these messages and in response to this particular message it does this or that. I have an actor that does periodic checks for health-monitoring purposes, receiving periodic health-check ticks - and depending on its state (being a FSM) it can evolve to another state (e.g. Fault, after which it can’t do anything anymore, until it’s manually pulled out of Fault). Pretty sweat. I would point out to the availability of akka.actor.FSM, but I don’t really like it and for simple stuff I found it easier to just model FSMs with context.become. -- 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 [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.
