In a highly concurrent system, it seems to me that the major benefit of using Akka is not in allowing concurrent computation (Futures work more simply), but in ensuring correct execution of things that should not happen concurrently (e.g. serializing access to state). (from reading this: Don't use Actors for concurrency <https://www.chrisstucchio.com/blog/2013/actors_vs_futures.html>).
Is this a fair way to think about Akka? Suppose I build a stateless webserver, what benefits (if any) does Akka provide in its implementation? For example, for Spray <http://spray.io/> HTTP servers, spray encourages the use of Actors in routing requests. That is, a single actor exclusively blocks the routing of other requests until either, the request completes or a child actor is created to manage this. Why does Akka help here? It seems to me that it encourages blocking for no benefit -- since routing is typically a stateless operation, what's the rationale in making this operation an actor? Thanks, - Stuart -- >>>>>>>>>> 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.
