Java Reference
In-Depth Information
requests has finished and you need to perform another task after
all
the asynchronous re-
quests are complete. For example, maybe you are gathering information from a bunch of dif-
ferent web services to build a larger aggregated document (a mashup).
Use callbacks when each invocation is its own distinct unit and you do not have to do any
coordination or mashing up.
Server Asynchronous Response Processing
For a typical HTTP server, when a request comes in, one thread is dedicated to the process-
ing of that request and its HTTP response to the client. This is fine for the vast majority of
HTTP traffic both on the Internet and on your company's internal networks. Most HTTP re-
quests are short-lived, so a few hundred threads can easily handle a few thousand concurrent
users and have relatively decent response times.
The nature of HTTP traffic started to change somewhat as JavaScript clients started to be-
come more prevalent. One problem that popped up often was the need for the server to push
events to the client. A typical example is a stock quote application where you need to update
a string of clients with the latest stock price. These clients would make an HTTP GET or
POST request and just block indefinitely until the server was ready to send back a response.
This resulted in a large amount of open, long-running requests that were doing nothing other
than idling. Not only were there a lot of open, idle sockets, but there were also a lot of dedic-
ated threads doing nothing at all. Most HTTP servers were designed for short-lived requests
with the assumption that one thread could process requests from multiple concurrent users.
When you have a very large number of threads, you start to consume a lot of operating sys-
tem resources. Each thread consumes memory, and context switching between threads starts
to get quite expensive when the OS has to deal with a large number of threads. It became
really hard to scale these types of server-push applications since the Servlet API, and by as-
sociation JAX-RS, was a “one thread per connection” model.
In 2009, the Servlet 3.0 specification introduced asynchronous HTTP. With the Servlet 3.0
API, you can suspend the current server-side request and have a separate thread, other than
the calling thread, handle sending back a response to the client. For a server-push app, you
could then have a small handful of threads manage sending responses back to polling clients
and avoid all the overhead of the “one thread per connection” model. JAX-RS 2.0 introduced
a similar API that we'll discuss in this section.
