Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "how to expand Future Response Servlet". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

The emergence of AJAX, as a Web application model, has greatly changed the face of the server. The typical Web usage pattern in which a user fills out a form to a Web page and clicks the submit button to go to the next link is now being transformed into a more advanced client-side JavaScript and a more feature-rich user interface that constantly interacts with the server as long as the form is manipulated, such as clicking a check box, pressing a button, or moving the mouse over a tab.

Consider the amount of data transferred from the client to the server. From a usability perspective, users get a rich user interface on a thin client browser without having to install anything. However, there is a price to pay when extending these applications on the server side. The number of typical capacity plans for AJAX applications may be three to four times that of standard Web applications.

One might ask: how does this affect WebLogic Server? Each HTTP request sent to WebLogic uses a thread of execution. Depending on the nature of AJAX programming and the fact that many short-term requests are constantly sent in the form of polling, the behavior pattern may cause a large number of client requests to keep hitting the server. Over the years, WebLogic has taken this issue into account and built a great feature, Future Response Servlet. This paradigm is based on the concept of asynchronous servlet. Starting with version 6.1, this feature allows developers to provide truly asynchronous notifications from the server without the need for client-side rotational training of events and the use of execution threads on the server side. Before 9.x, BEA was in no hurry to expose the class.

How to make use of this kind in reality? Let's look at an example. Suppose the business requirement is to build an Web-based application that sends data to the server in near real time without refreshing the browser. Such an application can submit a request to the server that takes a long time to process, while still receiving asynchronous events about its state and listening for events. From a technical point of view, there are many ways to achieve this. One way to do this is to use a Java Applet that communicates with Java Servlet to get asynchronous information. This is a good method, but it is a bit inconvenient for users because they have to download a JVM and also download an applet to the browser. In addition, a persistent socket connection from the client to the server must be maintained to receive asynchronous messages. Imagine that if 1000 users used the applet, there would be 1000 threads of execution almost empty waiting to send event notifications to the client. Of course, there are other ways, such as building a polling mechanism from applet or AJAX applications to check for new data on a regular basis. If you don't receive data often, polling is useless, and it wastes server resources and consumes execution threads. Instead, the server can poll periodically, propagate events back to the client, and maintain socket threads without using persistent execution threads. This is very similar to the way Java NIO works. Ideally, we all want to build an application that receives event notifications "asynchronously" from the server without using persistent threads of execution on the server side, whether it's an applet or a thin AJAX-based 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 Future Response Servlet class and registers itself as a listener in another thread. Whenever an event is received on the server side, the thread notifies the client of the event. The server remains asynchronous with the client, eliminating the need for persistent execution threads. The model can be extended for the case of multiple concurrent users.

This article is not intended to cover how to build AJAX applications. There are already a lot of articles in this area. The focus of this article is on the importance of asynchronous processing in the 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

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.