I don't understand Async support in servlets 3.0 API

In the traditional Servlet model, it's normally the case that 1 request corresponds to 1 thread.

These threads typically come from a pool which is managed by the Servlet container. The Servlet container can only handle new requests as long as it has free threads in this pool. As long as your own code is busy processing the request, the thread is not free.

In some situations it might be worth it to break this model. What happens is that a request arrives at the Servlet via such a Servlet container managed thread, and your code then asks for asynchronous execution. You can then return from the Servlet request and the container thread will be freed.

Contrary to synchronous request processing, this will not commit any response and will not close the connection. Instead, you can hand the async context off to another thread pool, which can pick it up, and when some thread is free to handle it, service it and will be able to write to the response.

An example:

@WebServlet(urlPatterns = "/somepath", asyncSupported = true)public class AsyncServlet extends HttpServlet {    @EJB    private AsyncBean asyncBean;    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {        AsyncContext asyncContext = request.startAsync();        // The following line will not block and return immediately        asyncBean.doAsyncStuff(asyncContext);    } // Shortly after this method has ended, thread will be returned to pool}

With the AsyncBean being implemented as:

@Statelesspublic class AsyncBean {    @Asynchronous    public void doAsyncStuff(AsyncContext asyncContext) throws IOException {        asyncContext.getResponse().getWriter().write("test");    }}

In the code above, somewhere shortly after you return from the AsyncServlet#doGet() method, the Servlet thread will be returned to the pool. A 'request' (task) for executing AsyncBean#doAsyncStuff() will have been put in the queue for the EJB thread pool to pick up.

The answer to WHY and WHEN you would use this is not that straightforward. If you just want to preserve threads then in the above case you would be exchanging one a thread from one thread pool for the other (in this case the Servlet pool vs the EJB async pool) and the net benefit wouldn't be that much. You could just as well have given your Servlet thread pool an extra thread.

In more advanced scenarios, you could however do more fine-grained managing of requests; divide them into multiple tasks and have a thread pool service those tasks. E.g. imagine 100 download requests for a 10MB file handled by 10 threads that round-robin give sends 100KB a time to each request.

Yet another application is a request that needs to wait for data from an external system, and where this external system is capable of sending a message that can be relayed back to the requestor. I.e. a database call would not make sense here, since you would need another thread waiting for the response anyway. Then you would change one thread for another again. But if you need to wait for say an incoming email, then one thread can wait for any email and relay that to any suspended request.