title: Why is non-blocking web request efficient as we are holding a server thread in both cases
body: <p>The question is about Play framework specifically although concept is generic.</p>
  <p>Quoting from:</p>
  <p><a href="https://www.playframework.com/documentation/2.6.18/ScalaAsync" rel="nofollow noreferrer">https://www.playframework.com/documentation/2.6.18/ScalaAsync</a></p>
  <blockquote>
  <p>The web client will be blocked while waiting for the response, but
  nothing will be blocked on the server, and server resources can be
  used to serve other clients.</p>
  <p>Using a Future is only half of the picture though! If you are calling
  out to a blocking API such as JDBC, then you still will need to have
  your ExecutionStage run with a different executor, to move it off
  Play’s rendering thread poo</p>
  </blockquote>
  <p>I understand the part that the original web application threads will be freed however another thread will still be needed to actually perform the cpu intensive action and then calculate the result, which will be propagated to the client (which is blocked meanwhile).</p>
  <p>How is better than synchronously performing the execution in the play's action code? We would have to increase the number of threads (as the blocking request will consume threads), however total number of active threads on the server will remain the same.</p>
  <p>Can someone also throw light on how does Play track the blocked client thread and returns the response in the non-blocking action scenario?</p>