cometd: jetty

111

　　http://docs.codehaus.org/display/JETTY/Cometd+%28aka+Bayeux%29
　　Jetty includes a servlet implementation of the Bayuex protocol of cometd from the Dojo Foundation.
　　Cometd is a message bus for Ajax web applications that allows multi channel messaging between client and server - and more importantly - between server and client. The paradigm is publish/subscribe to named channels.
　　http://www.webtide.com/downloads/whitePaperAjaxJetty.html
To deal with the need for servlets to have an efficient waiting mechanism, Jetty 6 introduced a Continuation Mechanism, which allows the current threads handler to be suspended and resumed at a later time in response to a timeout or an asynchronous event. A continuation is obtained by a servlet via a portable API that will work in any Servlet container. In containers other than Jetty, a simple WaitingContinuation is used where suspend is the equivalent to a wait() and resume the equivalent of an notify(), so the application works but does not avoid the problem of thread allocation.
 
When run in Jetty, the continuation instance obtained will be a RetryContinuation, which when suspended actually throws a special RuntimeException that allows the request thread to exit the Filter/RequestDispatcher/Servlet chain and unwind the statck to the container. The thread is returned to the pool while Jetty holds the request until either a timeout occurs or the resume method is called.
 
This mechanisms relies on the stateless nature of HTTP and the ability to retry idempotent requests. It allows requests to wait within the container rather than within the servlet, without the expense of the allocated thread and buffers.
　　http://docs.codehaus.org/display/JETTY/Continuations

　　Continuations will be replaced by standard Servlet-3.0 suspendable requests once the specification is finalized. Early releases of Jetty-7 are now available that implement the proposed standard suspend/resume API
How it works
　　Behind the scenes, Jetty has to be a bit sneaky to work around Java and the Servlet specification as there is no mechanism in Java to suspend a thread and then resume it later. The first time the request handler calls continuation.suspend(timeoutMS) a RetryRequest runtime exception is thrown. This exception propagates out of all the request handling code and is caught by Jetty and handled specially. Instead of producing an error response, Jetty places the request on a timeout queue and returns the thread to the thread pool.
　　When the timeout expires, or if another thread calls continuation.resume(event) then the request is retried. This time, when continuation.suspend(timeoutMS) is called, either the event is returned or null is returned to indicate a timeout. The request handler then produces a response as it normally would.
　　Thus this mechanism uses the stateless nature of HTTP request handling to simulate a suspend and resume. The runtime exception allows the thread to legally exit the request handler and any upstream filters/servlets plus any associated security context. The retry of the request, re-enters the filter/servlet chain and any security context and continues normal handling at the point of continuation.
　　Furthermore, the API of Continuations is portable. If it is run on a non-Jetty6 server it will simply use wait/notify to block the request in getEvent. If Continuations prove to work as well as I hope, I plan to propose them as part of the 3.0 Servlet JSR.