Asynchronous server side may differ depends on the framework is running but more or less is the same.
Summary
This model works perfectly if the request processing doesn’t take so much time. As mentioned before, there is a pool of threads that accepts and processes incoming requests. When there is a huge number of requests and processing is heavy and time-consuming, at some point we would expect to reach a point that all the threads are busy processing and the pool is empty. At this point, there are no more threads available to accept any connection request.
This is the time that asynchronous processing model comes into action. The idea behind asynchronous processing model is to separate connection accepting and request processing operations. Technically speaking it means to allocate two different threads, one to accept the client connection and the other to handle heavy and time-consuming operations. In this model, the container dispatched a thread to accept client connection (acceptor), hand over the request to processing (worker) thread and releases the acceptor one. The result is sent back to the client by the worker thread. In this mechanism client’s connection remains open. May not impact on performance so much, such processing model impacts on server’s THROUGHPUT and SCALABILITY a lot.
by Sam Sepassi in JAX-RS 2.0 Asynchronous Server and Client
In Play Framework
Play framework is asynchronous from the bottom up, each request is served in different threads, but it's possible to increase the number of threads in the default execution context to allow more concurrent requests to be processed by blocking controllers.
We need to go to a different thread as soon as possible but we need to take care of change the context, we can't access to Play Framework request context from a thread, we could but is better for us to force us to work separately of Play framework like Android to not create a spaghetti framework code. For that reason, I decide to not create an async login because Play framework forces you to change the context inside a thread, we have two options, do nothing because Login doesn't need lots of concurrencies or play with CompletionStage deep in our login flow and create an async just in the HTTP network calls.
Asynchronous server side may differ depends on the framework is running but more or less is the same.
Summary
This model works perfectly if the request processing doesn’t take so much time. As mentioned before, there is a pool of threads that accepts and processes incoming requests. When there is a huge number of requests and processing is heavy and time-consuming, at some point we would expect to reach a point that all the threads are busy processing and the pool is empty. At this point, there are no more threads available to accept any connection request.
This is the time that asynchronous processing model comes into action. The idea behind asynchronous processing model is to separate connection accepting and request processing operations. Technically speaking it means to allocate two different threads, one to accept the client connection and the other to handle heavy and time-consuming operations. In this model, the container dispatched a thread to accept client connection (acceptor), hand over the request to processing (worker) thread and releases the acceptor one. The result is sent back to the client by the worker thread. In this mechanism client’s connection remains open. May not impact on performance so much, such processing model impacts on server’s THROUGHPUT and SCALABILITY a lot.
by Sam Sepassi in JAX-RS 2.0 Asynchronous Server and Client
In Play Framework
Play framework is asynchronous from the bottom up, each request is served in different threads, but it's possible to increase the number of threads in the default execution context to allow more concurrent requests to be processed by blocking controllers.
We need to go to a different thread as soon as possible but we need to take care of change the context, we can't access to Play Framework request context from a thread, we could but is better for us to force us to work separately of Play framework like Android to not create a spaghetti framework code. For that reason, I decide to not create an async login because Play framework forces you to change the context inside a thread, we have two options, do nothing because Login doesn't need lots of concurrencies or play with CompletionStage deep in our login flow and create an async just in the HTTP network calls.
Reference
JAX-RS 2.0 Asynchronous Server and Client Play Framework JavaAsync