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.
Community comments
Great Idea ...
by Alan Williamson /
Great Idea ...
by Alan Williamson /
Your message is awaiting moderation. Thank you for participating in the discussion.
The Servlet API has been one of those beautiful API's that has, by in large, stayed small and nibble. The HTTP protocol while remaining unchanged, has had its usage change, and no longer should a server be optimized on a simple GET request. The AJAX world, while removing demand on the server for large requests, has turned it on its head, and gone for repeated smaller requests.
For the Servlet API to remain relevant in this new dawn, then changes must happen at the API level and not left to individual container implementators. I support Greg's motion for this.