Jetty Founder Proposes Asynchronous Servlet API

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:

class DefaultCoordinator implements ServletCoordinator
{
   void doRequest(ServletRequest request)
   {
       request.continue();
       request.service();
   }

   void doResponse(Response response)
   {
       response.complete();
   }
}

According to Greg:

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.

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.

Greg is gathering feedback to incorporate back into Jetty and then to push into the Servlet spec itself if possible.

Hello stranger!

You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

Back to top

Login with:

Don't have an InfoQ account?

Jetty Founder Proposes Asynchronous Servlet API

Write for InfoQ

Inspired by this content? Write for InfoQ.

Rate this Article

This content is in the Architecture topic

Related Topics:

Related Editorial

Related Sponsored Content

Related Sponsor

The InfoQ Newsletter

Hello stranger!

Tell us what you think

Community comments

Great Idea ...

Your Reply

Your Reply