Asynchronous Servlets vs. synchronous Servlets

Since Servlet 3.0 asynchronous processing is supported. Would it be better, to use always asynchronous processing? Or in w开发者_运维问答hat cases is synchronous processing better?

The big thing you get with asynchronous servlets is HTTP push, where the server can fire information back to the client when it chooses to, rather than when the client asks for it. Pre-asynch servlets, this would require long-running HTTP connections which each tied up a server thread, which is very inefficient. This new model decouples the server-side processing from the connection handling.

Reading the article, asynchronous processing support in the Servlet 3.0 spec has a very specific use case - it is designed to handle the case where you have an AJAX application that makes requests that trigger potentially long-running processes in the background.

The reason we needed something like this was to respond to a problem in the thread-per-request model, which allocates a thread every time the client requests a page from the server, rather than allocating a single thread for the client's entire session. This worked well prior to AJAX when clients would make requests sporadically, but the benefits were lost when AJAX applications significantly increased the number of requests a client would make.

Specifically, if an AJAX request triggers something potentially slow or blocking, like a database operation, we are back where we started - threads from the server's threadpool are potentially idle.

Asynchronous processing support attempts to mitigate this by putting requests into a centralized queue, such that threads are not always stuck waiting for results of requests that might not have even started being processed yet. In short, we are trying to get the most bang for our buck out of our threads at all times - that is, decreasing the amount of time when they are idle (but could be serving some other connection).

Like any new developments, this is not something to be used as a one-size-fits-all tool. Look for the specific case in your application where it is appropriate.

Asynchronous processing have been introduced for the cases when there is no need to hold a thread during the whole request processing cycle. The typical example of such a case is a comet-like functionality.

Using asynchronous processing in all cases wouldn't worth anything, because usually back-end processing consumes a thread anyways.

I just skimmed over the linked article, this is a server-side improvement, not client-side asynchronous.

Summarising the article:

You would want to use Asynchronous servlets in a situation where you have a load of requests coming in (similar to bashing your server with AJAX requests), and you don't want to serve up one thread per request. TPR can be dangerous in this scenario when the processing time takes a little while, causing you to exhaust your thread pool.

The job will get stuck into a job queue and the thread can be retired until the job completes and the response is finally committed when the resources free up to allow it to complete.

Pretty cool stuff.

Its based on requrirement where any chances a thread get in idle state at that situation u should use Asynchronous Servlet otherwise not beacause of we can't make so many thread

If a servlet or a filter reaches a potentially blocking operation when processing a request, it can assign the operation to an asynchronous execution context and return the thread associated with the request immediately to the container without generating a response. The blocking operation completes in the asynchronous execution context in a different thread, which can generate a response or dispatch the request to another servlet.

To enable asynchronous processing on a servlet, set the parameter asyncSupported to true on the @WebServlet annotation as follows:

@WebServlet(urlPatterns={"/asyncservlet"}, asyncSupported=true) public class AsyncServlet extends HttpServlet { ... }

Synchronous (Classic Web-Application Model) A synchronous request blocks the client until operation completes i.e. browser is not unresponsive. In such case, java script engine of the browser is blocked.

Asynchronous (AJAX Web-Application Model) An asynchronous request doesn’t block the client i.e. browser is responsive. At that time, user can perform another operations also. In such case, java script engine of the browser is not blocked.

In synchronous communication both are active at the same time where as in Asynchronous no need to active at the same time for example Asynchronous refers to the messaging there blocking operation to a new thread and running the thread associated to the container

Web containers in application servers normally use a server thread per client request. Under heavy load conditions, containers need a large amount of threads to serve all the client requests. Scalability limitations include running out of memory or exhausting the pool of container threads. To create scalable web applications, you must ensure that no threads associated with a request are sitting idle, so the container can use them to process new requests.

There are two common scenarios in which a thread associated with a request can be sitting idle.

The thread needs to wait for a resource to become available or process data before building the response. For example, an application may need to query a database or access data from a remote web service before generating the response.

The thread needs to wait for an event before generating the response. For example, an application may have to wait for a JMS message, new information from another client, or new data available in a queue before generating the response.