内容摘要：结合使用 Comet 模式（将数据推到客户机）和 Jetty 6 的 Continuations API（将 Comet 应用程序扩展到大量客户机中）。您可以方便地在 Direct Web Remoting (DWR) 2 中将 Comet 和 Continuations 与 Reverse Ajax 技术结合使用。
清单 5 展示了对 ContinuationServlet 的五个同步请求的输出；请与 清单 3 进行比较。
清单 5. 对 ContinuationServlet 的五个并发请求的输出$ for i in 'seq 1 5' ; do lynx -dump localhost:8080/continuation?id=$i & done
Request: 1 start: Sun Jul 01 13:37:37 BST 2007
Request: 1 start: Sun Jul 01 13:37:39 BST 2007
Request: 1 end: Sun Jul 01 13:37:39 BST 2007
Request: 3 start: Sun Jul 01 13:37:37 BST 2007
Request: 3 start: Sun Jul 01 13:37:39 BST 2007
Request: 3 end: Sun Jul 01 13:37:39 BST 2007
Request: 2 start: Sun Jul 01 13:37:37 BST 2007
Request: 2 start: Sun Jul 01 13:37:39 BST 2007
Request: 2 end: Sun Jul 01 13:37:39 BST 2007
Request: 5 start: Sun Jul 01 13:37:37 BST 2007
Request: 5 start: Sun Jul 01 13:37:39 BST 2007
Request: 5 end: Sun Jul 01 13:37:39 BST 2007
Request: 4 start: Sun Jul 01 13:37:37 BST 2007
Request: 4 start: Sun Jul 01 13:37:39 BST 2007
Request: 4 end: Sun Jul 01 13:37:39 BST 2007
清单 5 中有两处需要重点注意。首先，每个 start 消息出现两次；先不要着急。其次，更重要的一点，请求现在不需排队就能够并发处理，注意所有 start 和 end 消息的时间戳是相同的。因此，每个请求的处理时间不会超过两秒，即使只运行一个 servlet 线程。
Jetty Continuations 机制原理
理解了 Jetty Continuations 机制的实现原理，您就能够解释 清单 5 中的现象。要使用 Continuations，必须对 Jetty 进行配置，以使用其 SelectChannelConnector 处理请求。这个连接器构建在 java.nio API 之上，因此使它能够不用消耗每个连接的线程就可以持有开放的连接。当使用 SelectChannelConnector 时，ContinuationSupport.getContinuation() 将提供一个 SelectChannelConnector.RetryContinuation 实例。（然而，您应该只针对 Continuation 接口进行编码；请参阅 Portability and the Continuations API。）当对 RetryContinuation 调用 suspend() 时，它将抛出一个特殊的运行时异常 —— RetryRequest —— 该异常将传播到 servlet 以外并通过过滤器链传回，并由 SelectChannelConnector 捕获。 但是发生该异常之后并没有将响应发送给客户机，请求被放到处于等待状态的 Continuation 队列中，而 HTTP 连接仍然保持打开状态。此时，为该请求提供服务的线程将返回 ThreadPool，用以为其他请求提供服务。
来源：developerWorks 作者：Philip McCarthy 责编：豆豆技术应用