If you use Await.result it will always block the thread that executes it
until the futures are completed. This means the thread cannot be used for
any other processing during this time, even though it's not actually doing
anything. Since threads are a finite resource and relatively expensive
(memory wise with stacks outside of the JVM and performance wise with
context switching to change thread) a very central idea with both Futures
and Actors is to keep threads few and never block them.
This is especially interesting when most of the work is IO based, calling a
database or a web service for example, since that takes orders of magnitude
more time than anything else, we can give the thread back to the thread
pool and let someone else use it until the IO operation completes, and then
schedule work to handle the result.
If your web service route is something in a web framework that isn't
asynchronous, like many of the Java ones, then you probably _must_ block a
thread until you have returned a response, this is because of how the
servlet API was originally designed (there are improvements in newer
versions of it though), you cannot really give it a
Future[webresult-of-some-kind]. This means that to be able to handle 150
concurrent requests you really need 150 threads, even if all of those will
just block and wait to be allowed to talk to the database through one of
the (much fewer) database connections in the connection pool. Any more
requests coming in will have to be queued and cannot be responded to even
if they are accessing paths that do not touch the database at all.
With Akka, Akka-http, Play (and others in the Scala ecosystem) the idea is
instead that the library knows about Future and you can give it a Future
result that it will return when it arrives or that it is message driven and
the result is delivered with a message, without blocking. This way you can
keep the number of threads low in your server but still serve very large
numbers of requests simultaneously.
I hope this helps your understanding.
--
Johan Andrén
Typesafe - Reactive apps on the JVM
Twitter: @apnylle
On Friday, September 4, 2015 at 2:13:44 AM UTC+2, Kevin Meredith wrote:
>
> Encouraged by other team members, I've re-factored my blocking,
> *Await#result* (returning type T) calls with *Future[T]*.
>
> Here's an example for readers who aren't familiar:
>
> scala> import scala.concurrent.{Future, Await}
>
> import scala.concurrent.{Future, Await}
>
>
> scala> import scala.concurrent.ExecutionContext.Implicits.global
>
> import scala.concurrent.ExecutionContext.Implicits.global
>
>
> scala> Future { 42 }
>
> res1: scala.concurrent.Future[Int] =
> scala.concurrent.impl.Promise$DefaultPromise@34cd072c
>
>
> scala> import scala.concurrent.duration._
>
> import scala.concurrent.duration._
>
>
> scala> Await.result(res1, 2.seconds)
>
> res2: Int = 42
>
>
> scala> Future ( 42 )
>
> res3: scala.concurrent.Future[Int] =
> scala.concurrent.impl.Promise$DefaultPromise@333291e3
>
>
> I believe that, reasoning about code using a Future, which provides `map`
> and `flatMap` (I'm not sure if the Functor and Monad Laws are upheld - but
> nevertheless) methods.
>
>
> However, what's the downside of blocking with Await.result versus using
> Future?
>
>
> Also, what if I put the Await.result at the end of the world, i.e. in a
> web service's route?
>
--
>>>>>>>>>> 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.
