One of the most important traits of Web 2.0 applications is low user-perceived latency in UI update, which usually requires low latency event notification from server to client. However due to the limitations of the HTTP protocol, a server cannot initiate communication with a client as events occur.
The enables server push by using client asynchronous polling. A client polling request is kept open by the server until suitable events occur. This way the server can timely push event notifications to clients as long as there are open polling requests. The Comet pattern uses the HTTP protocol in a novel yet compliant way. It is currently in the process of being standardized as the Bayeux protocol (draft spec). An HTTP server or server module that supports the Comet pattern is a Cometd.
One of the challenges that many HTTP servers face when adding support for Comet is open-request scalability. Traditionally HTTP servers bind one worker thread to each request until processing is complete and the HTTP response is sent. This model ties up threads even when the requests are blocked on waiting for other resources. Comet requires client polling requests be kept open, often for a long time, which makes the one-request-one-thread model not scalable.
The Jetty server is one of the early adopters of Comet. In fact the principal contributor of the Jetty server, Greg Wilkins, is also an author of the Bayeux spec. Jetty achieves Comet scalability by disassociating the worker thread from a polling request when it becomes blocked on waiting for new events. This way the worker thread can return to the pool and be reassigned to service an active request.
Jetty uses the Continuation pattern to suspend a blocked polling request and free the worker thread. By using Continuation, Jetty keeps impact on existing Web applications and Servlet related technologies to a minimum. Applications written according to the current Servlet specs can take advantage of Comet with trivial changes, and the Continuation mechanism for suspending and resuming of a request is most straightforward. Although Continuation is hardly the only way to implement Comet support, it’s worth noting that other approaches typically will require writing asynchronous code at the application level which carries a signification application development cost.
In summary, we chose Jetty not only because it supports Comet in a scalable manner, but also because the Continuation implementation of Comet is least disruptive to existing Servlet based technologies.
We recommend Jetty because of the great success we’ve had with it, specifically for Zimbra 5.0. They’ve got great developer support, and the code is clean and simple to look at.Take a look at http://webtide.com/ for more information on webtide’s products, including Jetty.
Jetty Links:
Jetty
Jetty Wiki
Webtide
AJAX Jetty/Comet whitepaper
Written by JJ Zhuang
Comments are closed.