Extended Future Response Servlet

The emergence of AJAX as a Web application model has greatly changed the appearance of the server. The typical Web usage mode of the user entering a form on the Web page and clicking the submit button to go to the next link is now transforming to a more advanced client JavaScript and a richer user interface, as long as you operate the form, such as clicking a check box, pressing a key, or moving the mouse over a tab, the user interface will continuously interact with the server.

Consider the amount of data transferred from the client to the server. From the perspective of availability, users get a rich user interface on a thin client browser without installing anything. However, you have to pay the price when you expand these applications on the server side. The typical capacity planning of AJAX applications may be three to four times that of standard Web applications.

Some may ask: How does this affect WebLogic Server? Each HTTP request sent to WebLogic must use an execution thread. According to the nature of AJAX programming and the fact that many short-term requests are continuously sent in the form of polling, this behavior pattern may cause a large number of client requests to constantly impact the server. Over the years, WebLogic has taken this issue into consideration and built a very good feature, that is, the Future Response Servlet. This model is built on the basis of the asynchronous servlet concept. Starting from Version 6.1, this feature allows developers to provide notifications from the server asynchronously, without the need to conduct client rotation for events and use execution threads on the server. Before, BEA was not eager to publish the class.

How can this class be used in reality? Let's look at an example. Assume that the business requirement is to build a Web-based application that sends data to the server in near real-time mode without refreshing the browser. Such an application can submit a request that takes a long time to process to the server, but can still receive asynchronous events about its status and listen to events. From a technical point of view, there are many implementation methods. One method is to use a Java Applet that communicates with the Java Servlet to obtain asynchronous information. This is a good method, but it is inconvenient for users because they must download a JVM and an applet to the browser. In addition, you must maintain a persistent socket connection from the client to the server to receive asynchronous messages. Imagine that if 1000 users use this applet, 1000 execution threads are almost empty waiting to send event notifications to the client. Of course, there are other methods, such as building a polling mechanism from an applet or AJAX application to regularly check new data. If the data is not frequently received, polling is useless, and server resources are wasted, occupying the execution thread. On the contrary, the server can periodically round-robin events back to the client and maintain socket threads without using persistent execution threads. This is very similar to the running method of Java NIO. Ideally, we all want to build an application that "asynchronously" receives event notifications from the server without using persistent execution threads on the server, whether it is an applet or a AJAX-Based Thin Web application.

One solution to this problem is to create a Servlet that extends the Future Response servlet class. The browser establishes a single connection to the ure Response Servlet class and registers itself as a listener in another thread. As long as the server receives an event, the thread notifies the client of the event. The server and the client are kept asynchronous and do not need to use persistent execution threads. This model can be extended for multiple concurrent users.

This article does not describe how to build AJAX applications. There are already many articles in this regard. This article focuses on the importance of asynchronous processing of presentation layer (such as AJAX, applet, or any front-end application. Listing 1 shows an example.

 
 

  
  
import java.io.IOException;  
  
  
import java.io.PrintWriter;  
  
  
import java.util.Date;  
  
  
import java.util.Stack;  
  
  
import javax.servlet.ServletException;  
  
  
import javax.servlet.http.HttpServletRequest;  
  
  
import weblogic.servlet.FutureResponseServlet;  
  
  
import weblogic.servlet.FutureServletResponse;  
  
  
// An AsynchronousServlet that handles HTTP requests from a 
"separate" thread and  
  
  
// not the execute thread used to invoke this servlet.  
  
  
 
  
  
public class AsynchronousServerResponseServlet extends 
FutureResponseServlet {  
  
  
private final Notifier notifier;  
  
  
public AsynchronousServerResponseServlet() {  
  
  
this.notifier = new Notifier();  
  
  
this.notifier.start();  
  
  
}  
  
  
public void service(HttpServletRequest request, FutureServletResponse 
response)  
  
  
throws IOException,ServletException {  
  
  
// push this client's request to a buffer and return immediately.  
  
  
// asynchronous processing occurs in the run method of the Notifier Thread  
  
  
 
  
  
notifier.poll(request, response);  
  
  
}  
  
  
class Notifier extends Thread {  
  
  
private static Stack clients = new Stack();  
  
  
void poll (HttpServletRequest request, FutureServletResponse response) {  
  
  
clients.push(new Client(request, response));  
  
  
}  
  
  
public void run() {  
  
  
while (!clients.empty()) {  
  
  
Client client = null;  
  
  
try{  
  
  
client = (Client) clients.pop();  
  
  
PrintWriter pw = client.response.getWriter();  
  
  
for(int j = 0; j < 10; j++) {  
  
  
pw.println("Time is:" + new Date() + "");  
  
  
pw.flush();  
  
  
}  
  
  
pw.close();  
  
  
}  
  
  
catch(Throwable t) {  
  
  
t.printStackTrace();  
  
  
}  
  
  
finally {  
  
  
try {  
  
  
client.response.send();  
  
  
}  
  
  
catch(IOException ioe) {  
  
  
ioe.printStackTrace();  
  
  
}  
  
  
}  
  
  
}  
  
  
}  
  
  
}  
  
  
// inner class that holds o-n to the clients http request and response  
  
  
 
  
  
class Client {  
  
  
private HttpServletRequest request;  
  
  
private FutureServletResponse response;  
  
  
private Client(HttpServletRequest request, FutureServletResponse 
response) {  
  
  
this.request = request;  
  
  
this.response = response;  
  
  
}  
  
  
} 
 
 

It can be seen that this example is very simple. The AsynchronousServerResponseServlet class extends the Future Response Servlet and overwrites the service method. Only one thread (Notifier class) is used to process all client connection responses. For each HTTP request, the servlet registers the socket connection with the Notifier thread and returns the result. Asynchronous events are delivered to the client, while persistent socket connections are maintained.

A single thread can manage multiple client connections! The run () method can be used to call back events to the client based on certain message selection conditions. In this example, only one server push operation is executed, which is too simple. The thread pool can be used for processing certain types of events.

All in all, Future Response Servlet is a good feature when processing long-running tasks. It allows developers to improve performance, process responses in independent threads, and minimize overhead. This method supports scalability when building an asynchronous application.

1. Scala Servlet in Scala Language
2. Servlet API Discussion
3. Introduction to Servlet containers and Context
4. Servlet Source file to Class Process
5. Details about Listener listening to Http sessions