Asynchronous Programming

 

Purpose of Asynchronous Programming:

Asynchronous Programming JEE-5 and Servlet API have been designed with Asynchronous programming to address the scalability issues of the applications.

By looking at the Asynchronous Programming in JEE the JAX-RS also provided API to work with Asynchronous Programming in RESTful services.

The main purpose of Asynchronous JAX-RS Resources is to address or to solve the scalability issues and performance issues which results in improved scalability of the REST Resources.

Differences between the Synchronous/Asynchronous Communication and Asynchronous Programming:

Synchronous and Asynchronous Communication:

Synchronous Communication means if the Consumer sends the req to a Provider then Provider will send the response immediately and Consumer will wait to get the response. If the Provider takes more time to process then until the Provider sends the response the consumer will not close the network connection which means the Consumer will wait to get the response. That means the Consumer and Provider will be blocked to build and to get the response.

Asynchronous Communication means if the Consumer sends the req to a Provider then Provider will/may not send the response immediately bcz of more processing time, So the consumer will not wait to get the response from the provider rather once he sends the req he will close the connection and it is the responsibility of the Provider to open the network connection with which port the req has come (with the help of req header details) and gives the response back. That means the provider will hold the req port number and etc details that have been sent in the req to open the connection with Consumer to send the response. That means here the consumer and Provider will not be blocked to build the response and to get the response from the Provider.

Basically, HTTP protocol is Synchronous Commination protocol only but not supported for the Synchronous Commination. 

The HTTP protocol is Synchronous Commination protocol only but if we use HTTP for the SOAP-Based (Web services) then also we can achieve the Asynchronous Communication using HTTP. But HTTP will always send the response which means we may think that we cannot achieve the Asynchronous if we use HTTP but it is wrong bcz HTTP is Synchronous only but we are achieving the Asynchronous Communication even though we use HTTP bcz once the Consumer will send the req to the Provider gives the dummy response 200 OK will be given back to the provider side Web service Runtime that means HTTP is giving the response back but that with dummy response there is no use hence Web service Runtime will suppress/discords that dummy response so as no response is delegated/given back to the Consumer so now the Consumer will closes/terminates the Connection automatically.

Asynchronous Programming:

|-JEE-3 Container/Servlet Container Architecture

  |-Problem with JEE-3 Servlet Container Architecture

|-JEE-5 Container/Servlet Container Architecture

JEE-3 Container/Servlet Container Architecture:

Initial HTTP processors or Servlet Container has been designed to address the req is going to complete within a shorter time that means by predicting that processing lifetime of the req is going to be less so based on this Servlet Container has been designed.

 The HTTP Transport-Handler will receive the req and forward the req to the Servlet Container.

Once the req has been identified by the Servlet Container it creates the obj of the corresponding Servlet and assigns one of the threads from the thread pool which will take the responsibility in processing that particular req so now this thread will call the service() of our Servlet within the run() method now our servlet service() methods will process business logic till that time thread will be in waiting for (Idle) state only but Thread scheduler will always monitor the thread to take one more req but the thread will not accept and says I am in the process and it will not releases the computational/memory resources or CPU time and then after completion gives response back to the thread so now this thread will take the response and gives back to the Servlet Container then this thread will perform the clean-up logic by realizing conn from the socket MUX so that thread will be return back to the pool so that it can be available for one more req. Now Servlet Container (which is the main thread) now it will dispatch the response back to the client. If one more req comes to the same application servlet then Servlet Container will not create one more obj rather uses the same obj and assigns one more thread from the thread pool it will perform the req processing.

So the Servlet Container Architecture and its processor programs (threads from the pool) have been designed by assuming that the processor (threads from the pool) are going to be short live processes that will take nano-sec of time to complete the req processing. But the HTTP protocol is not only used by the Web applications rather it is widely used by the distributed applications (EJB, Web services, RESTful) as well and those also will get deployed in the JEE-Containers. But generally distributed applications are complex business applications which will take more time to process the req and to dispatch the response so if for the server multiple req came then at some point of time thread starvation will come bcz of all the req are long-running processes and takes more time due to which no thread will get released to the thread pool due to which the new req's will be not be served and due to the new req's the thread scheduler will always do thread swathing to complete previous req's so that it can accommodate new req but no thread is going to be released due to this continuous thread switching no thread will gets finished which leads to dead-lock/thread starvation were no thread is going to complete the req and finally the server crashes or shutdowns.

So bcz of no thread free, the network adapter will not become free so that req will be kept on waiting then the timeout will happen that’s where 404-error will be displayed on the browser.

Problem with JEE-3 Servlet Container Architecture:

Due to the long-living req process Scalability of the application will go down bcz of resource scarcity which means no thread is going to be released hence the memory resources of that particular thread will not be released from the JVM that's where Resource/memory scarcity issues will raise due to this application scalability (accommodating more req's) will go down.

To avoid this kind of long live running process the JEE-5 Architecture has been designed with Asynchronous programming. So now we can turn ON the Asynchronous programming whenever we have the long-living req processing so that we our application will scales-up in accommodating the req's.

JEE-5 Container/Servlet Container Architecture:

JEE-5 or Servlet 3.0 Architecture is different from JEE-3 Architecture which means JEE-5 Architecture has been modified by adding the support for the Asynchronous Programming.

To process the req in JEE-3 container architecture there will be a thread pool. But now the JEE-5 has been designed with 2-pools by keeping in the view or to address the Asynchronous Programming which will scale up the application. That means now the Servlet Container will have 2-thread pools

1. Request Thread Pool

2. Response Thread Pool

Once the req send by the client the HTTP Transport handler will receive the req and hand-overs to the Servlet Container then Servlet Container will take that connection and takes one thread from the Request Pool and assigns now this thread will call the service() by extracting the data from the req and places within the HttpServletRequest obj with that socket connection once it forwards the req to the Servlet then it will terminate so the thread has been released from the Request Pool. So once the execution of the service method has been completed then this service method has to call back the servlet container stating that finishes the execution which is called a Callback. In order to do this, the Servlet Container will provide a way to the callback by providing the Callback handlers which is also a separate thread of execution which is not a Request pool thread, so by using these handlers we need to tell to the container we finished the execution and the response is ready so now the Servlet Container will goes to the Response Thread pool and takes response and dispatches to the Servlet Container and performs the clean-up logic so now the Servlet Container will dispatches the response to the client, Still, client is waiting for the response over the same network connection that means in Asynchronous Programming also the communication is Synchronous Communication only.

 So the Request thread and Responses thread both will not wait for the processing bcz to do process there will be separate threads that are different form the pools. That means the Request Thread pool and Response Thread Pool purpose has been changed, the Request pool Thread will forwards the req to the servlet and terminates and the response pool threads will take the response and forwards to the Servlet Container so no thread will wait hence these thread pools can serve any more no. of req's than usual hence scalability of the application will improve which is called as Asynchronous Programming.

Advantages:

1) The advantage we will get is the scalability of the server will be improved but not the performance bcz still same time required to process the req is still same in case of Synchronous servlets and Asynchronous servlets as well.

2) In addition to this we will lose-coupling between the components.

To achieve this the new set of classes and API has been given by the Servlet Container which is called as Asynchronous programming. That means now we have 2-types of Servlets

1. Synchronous Servlets

2. Asynchronous Servlets 

When we need to go for Asynchronous Servlets:

Whenever we have moderate or more complicated business logic which is going to take more amount of time then we should go for Asynchronous Servlets otherwise we use Synchronous Servlets.

Asynchronous Programming is also a Synchronous communication only bcz the client still waits for the response over the same network connection.

In the case of Asynchronous Servlets, we will have a Call-back handler.

How does communication will happen in Asynchronous Programming?

Ans: In Asynchronous Programming also communication between the client and Resource is Synchronous communication only.