Running the futures on the same dispatcher as the actors would be almost the same as running the blocking/computation inside the actor. Of course those futures should be running on a different executioncontext and depending on whether you are doing blocking io or computation you would have different number of threads (for maximizing throughput or for minimizing context switches).
Regards, Saurabh Rawat On Thu, Jul 31, 2014 at 9:56 AM, Ryan Tanner <[email protected]> wrote: > I think that's significantly simplifying the issue. Notably, if you have > long-running, CPU-intensive code and you blindly throw it into futures > within an actor, you can easily overwhelm your system. I've had major > problems with this. Really, this comes down to your specific requirements. > With simply non-blocking network IO, the future within an actor might be > okay. > > On Wednesday, July 30, 2014 12:09:00 PM UTC-6, Saurabh Rawat wrote: > >> Hi Bartłomiej, >> >> One more thing, actors are supposed to execute fast code, for any sort of >> blocking or expensive computation you would make a future anyway. >> >> Regards, >> >> Saurabh Rawat >> >> >> On Wed, Jul 30, 2014 at 8:34 PM, Martynas Mickevičius <martynas.m...@ >> typesafe.com> wrote: >> >>> Hi Bartłomiej, >>> >>> you have laid quite a few arguments for one and the other camp. >>> >>> One more limitation of Future compared with an Actor is that data can >>> flow only one way in the Future. On the contrary data can flow forward, >>> backward or even to some other direction when using an Actor. >>> >>> >>> >>> On Mon, Jul 28, 2014 at 12:42 AM, Bartłomiej Szczepanik < >>> [email protected]> wrote: >>> >>>> I would like ask more experienced people how you choose between futures >>>> and actors when you are about to implement some asynchronous >>>> processing/business logic. I was thinking hard and reading about it and had >>>> a lot of discussion with different people. >>>> >>>> >>>> >>>> The first, quite obvious criterion for me is statefulness or >>>> statelessness. Actors are great for state encapsulation and management. For >>>> example they fit ideally to DDD Aggregate pattern (and akka-persistence >>>> helps here a lot). >>>> >>>> >>>> >>>> So let's say we are about to implement something stateless. I've heard >>>> from some people that in this case Futures are the best option. They >>>> compose nicely what really helps to manage more complicated business logic. >>>> I am not sure the Futures are the way to go because I have seen a lot of >>>> examples in activators, documentation and blog posts with stateless >>>> behavior. >>>> >>>> >>>> >>>> The main point against the stateless actors is that they are >>>> transactional units. Handling of each message is done one by one and it >>>> seems to be very inefficient. Of course we can get rid of it by spawning >>>> multiple actors and setting up routers in front of them. But still it seems >>>> to be unnecessary complicated comparing to simply starting many futures or >>>> executing the same lines of code parallelly (I assume thread safety). >>>> >>>> >>>> >>>> Do you have a good criteria to choose the better option in particular >>>> use case? What disadvantages Futures have which make actors more attractive >>>> in stateless scenario? >>>> >>>> >>>> Best, >>>> >>>> Bartłomiej >>>> >>>> -- >>>> >>>>>>>>>> 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. >>>> >>> >>> >>> >>> -- >>> Martynas Mickevičius >>> Typesafe <http://typesafe.com/> – Reactive >>> <http://www.reactivemanifesto.org/> Apps on the JVM >>> >>> -- >>> >>>>>>>>>> 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. >>> >> >> -- > >>>>>>>>>> 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. > -- >>>>>>>>>> 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.
