Traditional Web applications rely on synchronous calls to an HTTP server: When a user accesses a URL, or submits an HTML form, for instance, the client waits for the server's response before further processing. That pattern works for applications where a page corresponds to the results of a server response.

Applications that require more fine-grained data access from the server, however, need to follow an asynchronous access pattern: Following a request to the server, the client continues processing. When the server's request arrives, the client is notified to process the response.

In a recent JavaWorld article, An introduction to asynchronous, non-blocking HTTP programming, Gregor Roth describes how such an asynchronous message handling pattern can be applied to the server as well, allowing for server-push applications, such as Comet:

Comet itself is based on creating and maintaining long-lived HTTP connections. Handling these connections efficiently requires a new approach to HTTP programming...

At the message level, asynchronous message handling means that an HTTP client performs a request without waiting for the server response. In contrast, when performing a synchronous call, the caller thread is suspended until the server response returns or a timeout is exceeded. At the application level, code execution is stopped, waiting for the response before further actions can be taken.

Roth points out that one advantage of the asynchronous approach is that each request handled asynchronously does not tie up a server thread:

No outstanding threads are required. In contrast to the synchronous call approach, the number of outstanding requests is not restricted to the number of possible threads. The synchronous approach requires a dedicated thread for each concurrent request, which consumes a certain amount of memory. This can become a problem if you have many concurrent calls to be performed on the client side.

Roth also comments that pipelining messages on the server can make message processing more effective:

Pipelining can significantly improve application performance when fetching many objects from the same server. The implicit persistent mode eliminates the overhead of establishing a new connection for each new request, by allowing for the reuse of connections. Pipelining also eliminates the need for additional connection instances to perform concurrent requests.

In the latter part of the article Roth discusses asynchronous message handling in the context of the server 2.5 API:

The downside of the Servlet API 2.5 is that it only allows for handling messages in a synchronous way. The HTTP request and response object have to be accessed within the scope of the request-handling thread. This message-handling approach is sufficient for most classic use cases. When you begin working with event-driven architectures such as Comet or middleware components such as HTTP proxies, however, asynchronous message handling becomes a very important feature...

The current Servlet API 2.5 supports neither non-blocking data streaming nor asynchronous message handling. When you implement a servlet's service method such as doPost() or doGet(), the application-specific servlet code will read the request data, perform the implemented business logic, and return the response...

To simplify writing servlets, the Servlet API uses a single-threaded programming approach. The servlet developer doesn't have to deal with threading issues such as starting or joining threads. Thread management is part of the servlet engine's responsibilities. Upon receiving an HTTP request the servlet engine uses a (pooled) worker thread to call the servlet's service method.

What do you think of Roth's comments on asynchronous HTTP calls?