Jetty founder Greg Wilkins thinks it's that it's time for the Servlet spec to evolve into an asynchronous model, in order to, among other things, deal with the new challenges brought on by Ajax. Jetty has been using Continuations for this, BEA has it's own solution and other approahces are being adopted in Glassfish and Tomcat 6.
Greg proposes standardizing a coordinator which could be called by the container in response to asynchronous event and would coordinate the call of the synchronous Servlet service method. The coordinator would handle the async request before a Servlet is invoked. The Coordinator entity can be defined and mapped to URL patterns just like filters and servlets. The default Coordinator would look like:
Greg proposes standardizing a coordinator which could be called by the container in response to asynchronous event and would coordinate the call of the synchronous Servlet service method. The coordinator would handle the async request before a Servlet is invoked. The Coordinator entity can be defined and mapped to URL patterns just like filters and servlets. The default Coordinator would look like:
class DefaultCoordinator implements ServletCoordinatorAccording to Greg:
{
void doRequest(ServletRequest request)
{
request.continue();
request.service();
}
void doResponse(Response response)
{
response.complete();
}
}
The ServletRequest.continue() call would trigger any required 100-Continue response and an alternative Coordinator may not call this method if a request body is not required or should not be sent.Greg is gathering feedback to incorporate back into Jetty and then to push into the Servlet spec itself if possible.
The ServletRequest.service() call will trigger the dispatch of a thread to the the normal Filter chain and and Servlet service methods. An alternative Coordinator may choose not to call service during the call to doRequest. Instead it may register with asynchronous event sources and call service() when an event occurs or after a timeout. This can delay event handling until the required resources are available for that request.
The ServletResponse.complete() call will cleanup a response and close the response streams (if not already closed). An alternative Coordinator may choose not to call complete during the call to doResponse(), thus leaving the response open for asynchronous events to write more content. An subsequent event or timeout may call complete to close the response and return it's connection to the scheduling for new requests.
The coordinator lifecycle would probably be such that an instance would be allocated to a request, so that fields in derived coordinator can be used to communicate between the doRequest and doResponse methods.