Jetty Founder Proposes Asynchronous Servlet API
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)
void doResponse(Response response)
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.
Great Idea ...
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.
How Can We Use Our Creative Power and Technological Opportunity to Address the Challenges of the 21st Century?
Gyorgyi Galik Feb 26, 2015