Revisiting the Need for Asynchronous Servlets

As we transition from a page based view of web application development to a Ajax style data based view, a few problem areas have begun to crop up. Ajax applications often desire a dedicated client/server connection supporting things such as server-push data streaming. Techniques such as COMET have been developed to fill this need. However these techniques leverage web servers and JEE constructs such as servlets as building blocks for solutions in ways they were originally not designed to handle. Gregg Wilkins, lead developer on the Jetty web container, has been examining the need for an Asynchronous Servlet API, concluding recently that  continuations are the best solution at the moment:  In May, Gregg examined 5 problem cases:

1. Non-blocking input - The ability to receive data from a client without blocking if the data is slow arriving.
2. Non-blocking output - The ability to send data to a client without blocking if the client or network is slow.
   
3. Delay request handling - The comet style of Ajax web application can require that a request handling is delayed until either a timeout or an event has occurred.
   
4. Delay response close - The comet style of Ajax web application can require that a response is held open to allow additional data to be sent when asynchronous events occur.
   
5. 100 Continue Handling - A client may request a handshake from the server before sending a request body.

Greg proposed 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.  An interesting discussion also emerged on TSS at the time.

Revisiting this topic in July, Gregg has reviewed the current available and proposed solutions:

• BEA WebLogic - BEA added AbstractAsyncServlet in WebLogic 9.2 to support threadless waiting for events (be they Ajax Comet events or otherwise eg. an available JDBC connection from a pool) ... It's not really a servlet - The user cannot implement doGet or service methods to generate content so there is limited benefit from tools or programmer familiarity.
• Tomcat 6.x - After my initial blogging on this issue, the tomcat developers added CometProcessor and CometServlet (unfortunately without engaging in an open discussion as I had encouraged). It is essentially the same solution as BEAs, but with a few extras, a few gotchas and the same major issues.
• Jetty 6 Continuations - The Jetty 6 Continuation mechanism is not an extension to the Servlet API. Instead it as a suspend/resume mechanism that operates within the context of a Servlet container to allow threadless waiting and reaction to asynchronous events by retrying requests.
• ServletCoordinator - My proposed ServletCoordinator suffers from many of these same issues. It does meet one of my main concerns in that responses are generated by normal servlets code using normal techniques and within the scope of the applicable filter chain.

Based on these solutions Gregg concluded that continuations are the best API for supporting the majority of the asynchronous use-cases within the servlet model.