Hi there Maatary! Indeed, blocking in any kind of reactive / event based framework is a big no-no. In order to deal with some blocking operations which you must still perform - like IO or databases, you can isolate them in their own dedicated dispatchers: doc.akka.io/docs/akka/current/scala/dispatchers.html
ThreadPool dispatchers, tuned accordingly to the amount of reserved threads for blocking do a good job at this. These dispatchers can then be used as execution contexts for futures - in order to keep their blocking out of the main dispatcher (fork-join based) which should keep handling actor messaging. On Tue, Feb 17, 2015 at 7:12 AM, Maatary Okouya <[email protected]> wrote: > Just spotted This short presentation Don't Block - How to Mess Up Akka > and Spray <http://www.slideshare.net/zacharycox/dont-block> that happens > to better illustrate the problem that I came with here. > > In any case i would appreciate to have other opinion > > On Tuesday, February 17, 2015 at 12:55:40 AM UTC-5, Maatary Okouya wrote: >> >> Hi, >> >> Everywhere we can read that that when performing long running operation >> or blocking operation it is preferable to use a special Execution context >> for the matter. Blocking operation like accessing the database. I >> understand why. It is to avoid Thread starvation. We do not want to have >> the "8" available threads busy with some blocking code which may eventually >> return or keep blocking. It either seriously slow down the application or >> block it indefinitely. >> >> Meanwhile, I'm wondering how things like Spray or Play are implemented. >> Indeed, let's take the client side. When a request is sent we get a future >> response. In other words, the request is executed asynchronously. This may >> by the way end up being a long running operation. However, there is nothing >> that says launching many request could lead to thread starvation in theses >> case. Hence i'm wondering why in that case it is not a problem. Do they >> have special Thread Pool. >> >> I red in the Book "Learning concurrent programing in Scala" that using >> the "Blocking {}" statement block in a Future helps its scheduler to spawn >> more thread automatically. Could it be the way they handle it? >> >> >> The same thing could be said for receiving request, in play we get to >> execute an Async Action. If one wants to access a database from this >> action, shall one use the "Blocking {}" statement block. How to execute >> that action is a special threadPool/ExecutionContext. >> >> >> > My assumption here is that they rely on the implicit.global >> > ExecutionContext. Maybe i'm wrong. The Bottom line is. Making request >> > is a long operation by default, how using spray for instance in your >> > code, would handle it such that not to create a Thread Starvation in >> > your code ? >> >> Are we using different ExecutionContext ? >> > -- > >>>>>>>>>> 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. > -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> 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.
