title: Basics | Threaded vs Reactive concurrency model
body: <p>I'm a complete newbie to the world of reactive programming. I'm looking into Akka Actors as a beginning step to play with.</p>
  
  <p>My understanding of the Thread Based concurrency model is (eg of a Vanilla Servlet based model):</p>
  
  <ol>
  <li>For every request from the client, a new thread is spawned.</li>
  <li>This means the execution of all the underlying code is attached to this thread and occur serially. Apparently even if one section of the code has a bottleneck (remote Webservice calls etc), the Thread will will be blocked and wait and remain idle.</li>
  <li>The servers (containers) has a fixed threadpool to accommodate max number of concurrent threads and apparently, they will quickly run of of threads because of bottleneck.</li>
  </ol>
  
  <p>My understanding of the Reactive concurrency model is (eg of a Akka based model):</p>
  
  <ol>
  <li>All the logic is no longer attached to a single thread and executed serially.</li>
  <li>The execution flow is reactive (ie on message, an actor gets triggered).</li>
  </ol>
  
  <p>Now my question:</p>
  
  <p>Assume the bottleneck of the remote webservice call exists in both the models.
  How is the actor model helps in better CPU / Core utilization? Won't we have the same problem of the execution threads within the actor getting blocked?
  For ex: If there are 200 actors concurrently blocked by this webservice call? Doesn't it mean there are 200 threads currently blocked?
  I understand that there will still be other actors reacting to other upstream events. Is this what we refer to as better utilization of the CPU?</p>
  
  <p>In a Threaded model, is only the small size of the Threadpool the cause of the problem?</p>
  
  <p>Doesn't the Actor Subsystem have a threadpool to spawn off a new actor and react to a specific event? If yes, then don't we have the same problem?</p>
  
  <p>Pardon me if this question is completely stupid.</p>