> On 30 Mar 2016, at 20:04, Kevin Meredith <[email protected]> wrote: > > 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?
Probably by registering a callback (`onComplete`).
> 2. How can a single actor, i.e. the spray web service, running on a single
> thread, handle so many requests?
An actor is not running on a single thread, at least not by default (the
default dispatcher is not pinning actors to threads). But assuming the routing
logic is non-blocking and delegating to business logic in an asynchronous
fashion, that would not matter too much.
> 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?
An actor always processes (at max) one message at a time. If responding to
requests happens asynchronously this should not be an issue.
> 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?
If you want to use libraries that rely on thread-per-request (e.g. by putting
stuff into the thread context), spray (or aka-http) will cause issue. But
otherwise any async and non-blocking library should give you much better
scalability.
Cheers
Heiko
>
> 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/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ:
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> >>>>>>>>>> <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]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/akka-user
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout
> <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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP using GPGMail
