Hi Johan -
Thanks for this helpful reply. I've re-read it a few times.
The following is *my incomplete* understanding, followed by my questions.
>A typical spray web service uses a single actor. It accepts requests (not
sure what the actual Actor Messsage is), and then replies with
`Future[HttpResponse]`.
1. Does blocking occur at _any_ stage? I ask because I'm curious how an
HttpResponse ultimately gets sent to its client. In other words, how does
the Future[HttpResponse] become an HttpResponse to its client?
2. How can a single actor, i.e. the spray web service, running on a single
thread, handle so many requests?
3. If a single-actor spray web service has 25 requests sent to it, will it
process each request one-at-a-time, where it then looks to its Actor
Mailbox to process the remaining 24 messages?
4. Between spray, i.e. actor-based web service, and thread-per-request web
services (e.g. Tomcat, I believe, is one), are there particular scenarios
where Tomcat does better than spray, and vice-versa? Or is there a clear
winner for all use cases?
Thank you.
On Friday, September 4, 2015 at 3:34:10 AM UTC-4, Johan Andrén wrote:
>
> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
