The analogy of the JMM for Akka is also very interesting, it is an important aspect of Akka to be aware of http://doc.akka.io/docs/akka/2.4.0/general/jmm.html
On Monday, November 9, 2015 at 9:02:08 PM UTC, Stuart Reynolds wrote: > > 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.
