源地址：http://www.ibm.com/developerworks/cn/web/wa-cometjava/
实现 Servlet 3.0 规范
Michael Galpin, 软件架构师, eBay
简介： 探索 Comet 开发的不同实现。看看 Jetty 和 Tomcat 之类的流行 Java™ Web 服务器如何支持 Comet 应用程序，并了解如何为不同的服务器编程。最后，了解 Java 中有关 Comet 的标准化建议，这些建议是即将到来的 Servlet 3.0 和 JavaEE 6 规范的一部分。
发布日期： 2009 年 7 月 22 日
级别： 中级
其他语言版本： 英文
访问情况 3539 次浏览
建议: 0 (添加评论)
平均分 （共 6 个评分 ）
在本文中，我将展示如何使用各种不同的 Java 技术构建一些简单的 Comet 风格的 Web 应用程序。读者对 Java servlet、Ajax 和 JavaScript 应该有一定的了解。我们将考察 Tomcat 和 Jetty 中一些支持 Comet 的特性，因此需要使用这两个产品的最新版本。本文使用 Tomcat 6.0.14 和 Jetty 6.1.14。另外还需要一个支持 Java 5 或更高版本的 JDK。本文使用 JDK 1.5.0-16。此外还需要看看 Jetty 7 的预发布版，因为它实现了 Servlet 3.0 规范，我们将在本文中研究该规范。请参阅 参考资料，找到下载链接。
您可能已经听说过 Comet，因为它最近受到了一定的关注。Comet 有时也称反向 Ajax 或服务器端推技术（server-side push）。其思想很简单：将数据直接从服务器推到浏览器，而不必等到浏览器请求数据。听起来简单，但是如果熟悉 Web 应用程序，尤其是 HTTP 协议，那么您就会知道，这绝不简单。实现 Comet 风格的 Web 应用程序，同时保证在浏览器和服务器上的可伸缩性，这只是在最近几年才成为可能。在本文的后面，我们将看看一些流行的 Java Web 服务器如何支持可伸缩的 Comet 架构，但首先我们来看看为什么要创建 Comet 应用程序，以及用于实现它们的常见设计模式。
HTTP 协议的成功毋庸置疑。它是 Internet 上大部分信息交换的基础。然而，它也有一些局限性。特别是，它是无状态、单向的协议。请求被发送到 Web 服务器，服务器处理请求并发回一个响应 — 仅此而已。请求必须由客户机发出，而服务器则只能在对请求的响应中发送数据。这至少会影响很多类型的 Web 应用程序的实用性。典型的例子就是聊天程序。另外还有一些例子，例如比赛的比分、股票行情或电子邮件程序。
HTTP 的这些局限性也是它取得一定成功的原因。请求/响应周期使它成为了经典的模型，即每个连接使用一个线程。只要能够快速为请求提供服务，这种方法就有巨大的可伸缩性。每秒钟可以处理大量的请求，只需使用少量的服务器就可以处理很大数量的用户。对于很多经典的 Web 应用程序，例如内容管理系统、搜索应用程序和电子商务站点等等而言，这非常适合。在以上任何一种 Web 应用程序中，服务器提供用户请求的数据，然后关闭连接，并释放那个线程，使之可以为其他请求服务。如果提供初始数据之后仍可能存在交互，那么将连接保持为打开状态，因此线程就不能释放出来，服务器也就不能为很多用户服务。
但是，如果想在对请求做出响应并发送初始数据之后，仍然保持与用户的交互呢？在 Web 早期，这一点常使用 meta 刷新实现。这将自动指示浏览器在指定秒数之后重新装载页面，从而支持简陋的轮询（polling）。这不仅是一种糟糕的用户体验，而且通常效率非常低下。如果没有新的数据要显示在页面上呢？这时不得不重新呈现同样的页面。如果对页面的更改很少，并且页面的大部分没有变化呢？同样，不管是否有必要，都得重新请求和获取页面上的一切内容。
Ajax 的发明和流行改变了上述状况。现在，服务器可以异步通信，因此不必重新请求整个页面。现在可以进行增量式的更新。只需使用 XMLHttpRequest 轮询服务器。这项技术通常被称作 Comet。这项技术存在一些变体，每种变体具有不同的性能和可伸缩性。我们来看看这些不同风格的 Comet。
Ajax 的出现使 Comet 成为可能。HTTP 的单向性质可以有效地加以规避。实际上有一些不同的方法可以绕过这一点。您可能已经猜到，支持 Comet 的最容易的方式是轮询（poll）。使用 XMLHttpRequest 向服务器发出调用，返回后，等待一段固定的时间（通常使用 JavaScript 的 setTimeout 函数），然后再次调用。这是一项非常常见的技术。例如，大多数 webmail 应用程序就是通过这种技术在电子邮件到达时显示电子邮件的。
这项技术有优点也有缺点。在这种情况下，您期望快速返回响应，就像任何其他 Ajax 请求一样。在请求之间必须有一段暂停。否则，连续不断的请求会冲垮服务器，并且这种情况下显然不具有可伸缩性。这段暂停使应用程序产生一个延时。暂停的时间越长，服务器上的新数据就需要越多的时间才能到达客户机。如果缩短暂停时间，又将重新面临冲垮服务器的风险。但是另一方面，这显然是最简单的实现 Comet 的方式。
现在应该指出，很多人认为轮询并不属于 Comet。相反，他们认为 Comet 是对轮询的局限性的一个解决方案。最常见的 “真正的” Comet 技术是轮询的一种变体，即长轮询（long polling）。轮询与长轮询之间的主要区别在于服务器花多长的时间作出响应。长轮询通常将连接保持一段较长的时间 — 通常是数秒钟，但是也可能是一分钟甚至更长。当服务器上发生某个事件时，响应被发送并随即关闭，轮询立即重新开始。
长轮询相对于一般轮询的优点在于，数据一旦可用，便立即从服务器发送到客户机。请求可能等待较长的时间，期间没有任何数据返回，但是一旦有了新的数据，它将立即被发送到客户机。因此没有延时。如果您使用过基于 Web 的聊天程序，或者声称 “实时” 的任何程序，那么它很可能就是使用了这种技术。
长轮询有一种变体，这是第三种风格的 Comet。这通常被称为流（streaming）。按照这种风格，服务器将数据推回客户机，但是不关闭连接。连接将一直保持开启，直到过期，并导致重新发出请求。XMLHttpRequest 规范表明，可以检查 readyState 的值是否为 3 或 Receiving（而不是 4 或 Loaded），并获取正从服务器 “流出” 的数据。和长轮询一样，这种方式也没有延时。当服务器上的数据就绪时，该数据被发送到客户机。这种方式的另一个优点是可以大大减少发送到服务器的请求，从而避免了与设置服务器连接相关的开销和延时。不幸的是，XMLHttpRequest 在不同的浏览器中有很多不同的实现。这项技术只能在较新版本的 Mozilla Firefox 中可靠地使用。对于 Internet Explorer 或 Safari，仍需使用长轮询。
至此，您可能会想，长轮询和流都有一个很大的问题。请求需要在服务器上存在一段较长的时间。这打破了每个请求使用一个线程的模型，因为用于一个请求的线程一直没有被释放。更糟糕的是，除非要发回数据，否则该线程一直处于空闲状态。这显然不具有可伸缩性。幸运的是，现代 Java Web 服务器有很多方式可以解决这个问题。
现在有很多 Web 服务器是用 Java 构建的。一个原因是 Java 有一个丰富的本地线程模型。因此实现典型的每个连接一个线程的模型便非常简单。该模型对于 Comet 不大适用，但是，Java 对此同样有解决的办法。为了有效地处理 Comet，需要非阻塞 IO，Java 通过它的 NIO 库提供非阻塞 IO。两种最流行的开源服务器 Apache Tomcat 和 Jetty 都利用 NIO 增加非阻塞 IO，从而支持 Comet。然而，这两种服务器中的实现却各不相同。我们来看看 Tomcat 和 Jetty 对 Comet 的支持。
对于 Apache Tomcat，要使用 Comet，主要需要做两件事。首先，需要对 Tomcat 的配置文件 server.xml 稍作修改。默认情况下启用的是更典型的同步 IO 连接器。现在只需将它切换成异步版本，如清单 1 所示。
<!-- This is the usual Connector, comment it out and add the NIO one -->
<!-- Connector URIEncoding="utf-8" connectionTimeout="20000" port="8084" protocol="HTTP/1.1" redirectPort="8443"/ -->
<Connector connectionTimeout="20000" port="8080" protocol="org.apache.
coyote.http11.Http11NioProtocol" redirectPort="8443"/>
这使 Tomcat 可以处理更多的并发连接，但需要说明的是，其中大多数连接有很多时间都处于空闲状态。利用这一点的最容易的方式是创建一个实现 org.apache.catalina.CometProcessor 接口的 servlet。这显然是 Tomcat 特有的一个接口。清单 2 显示了一个这样的例子。
public class TomcatWeatherServlet extends HttpServlet implements CometProcessor {
private MessageSender messageSender = null;
private static final Integer TIMEOUT = 60 * 1000;
@Override
public void destroy() {
messageSender.stop();
messageSender = null;
}
@Override
public void init() throws ServletException {
messageSender = new MessageSender();
Thread messageSenderThread =
new Thread(messageSender, "MessageSender[" + getServletContext()
.getContextPath() + "]");
messageSenderThread.setDaemon(true);
messageSenderThread.start();
}
public void event(final CometEvent event) throws IOException, ServletException {
HttpServletRequest request = event.getHttpServletRequest();
HttpServletResponse response = event.getHttpServletResponse();
if (event.getEventType() == CometEvent.EventType.BEGIN) {
request.setAttribute("org.apache.tomcat.comet.timeout", TIMEOUT);
log("Begin for session: " + request.getSession(true).getId());
messageSender.setConnection(response);
Weatherman weatherman = new Weatherman(95118, 32408);
new Thread(weatherman).start();
} else if (event.getEventType() == CometEvent.EventType.ERROR) {
log("Error for session: " + request.getSession(true).getId());
event.close();
} else if (event.getEventType() == CometEvent.EventType.END) {
log("End for session: " + request.getSession(true).getId());
event.close();
} else if (event.getEventType() == CometEvent.EventType.READ) {
throw new UnsupportedOperationException("This servlet does not accept
data");
}
}
}
CometProcessor 接口要求实现 event 方法。这是用于 Comet 交互的一个生命周期方法。Tomcat 将使用不同的 CometEvent 实例调用。通过检查 CometEvent 的 eventType，可以判断正处在生命周期的哪个阶段。当请求第一次传入时，即发生 BEGIN 事件。READ 事件表明数据正在被发送，只有当请求为 POST 时才需要该事件。遇到 END 或 ERROR 事件时，请求终止。
在清单 2 的例子中，servlet 使用一个 MessageSender 类发送数据。这个类的实例是在 servlet 的 init 方法中在其自身的线程中创建，并在 servlet 的 destroy 方法中销毁的。清单 3 显示了 MessageSender。
private class MessageSender implements Runnable {
protected boolean running = true;
protected final ArrayList<String> messages = new ArrayList<String>();
private ServletResponse connection;
private synchronized void setConnection(ServletResponse connection){
this.connection = connection;
notify();
}
public void send(String message) {
synchronized (messages) {
messages.add(message);
log("Message added #messages=" + messages.size());
messages.notify();
}
}
public void run() {
while (running) {
if (messages.size() == 0) {
try {
synchronized (messages) {
messages.wait();
}
} catch (InterruptedException e) {
// Ignore
}
}
String[] pendingMessages = null;
synchronized (messages) {
pendingMessages = messages.toArray(new String[0]);
messages.clear();
}
try {
if (connection == null){
try{
synchronized(this){
wait();
}
} catch (InterruptedException e){
// Ignore
}
}
PrintWriter writer = connection.getWriter();
for (int j = 0; j < pendingMessages.length; j++) {
final String forecast = pendingMessages[j] + "<br>";
writer.println(forecast);
log("Writing:" + forecast);
}
writer.flush();
writer.close();
connection = null;
log("Closing connection");
} catch (IOException e) {
log("IOExeption sending message", e);
}
}
}
}
这个类基本上是样板代码，与 Comet 没有直接的关系。但是，有两点要注意。这个类含有一个 ServletResponse 对象。回头看看清单 2 中的 event 方法，当事件为 BEGIN 时，response 对象被传入到 MessageSender 中。在 MessageSender 的 run 方法中，它使用 ServletResponse 将数据发送回客户机。注意，一旦发送完所有排队等待的消息后，它将关闭连接。这样就实现了长轮询。如果要实现流风格的 Comet，那么需要使连接保持开启，但是仍然刷新数据。
回头看清单 2 可以发现，其中创建了一个 Weatherman 类。正是这个类使用 MessageSender 将数据发送回客户机。这个类使用 Yahoo RSS feed 获得不同地区的天气信息，并将该信息发送到客户机。这是一个特别设计的例子，用于模拟以异步方式发送数据的数据源。清单 4 显示了它的代码。
private class Weatherman implements Runnable{
private final List<URL> zipCodes;
private final String YAHOO_WEATHER = "http://weather.yahooapis.com/forecastrss?p=";
public Weatherman(Integer... zips) {
zipCodes = new ArrayList<URL>(zips.length);
for (Integer zip : zips) {
try {
zipCodes.add(new URL(YAHOO_WEATHER + zip));
} catch (Exception e) {
// dont add it if it sucks
}
}
}
public void run() {
int i = 0;
while (i >= 0) {
int j = i % zipCodes.size();
SyndFeedInput input = new SyndFeedInput();
try {
SyndFeed feed = input.build(new InputStreamReader(zipCodes.get(j)
.openStream()));
SyndEntry entry = (SyndEntry) feed.getEntries().get(0);
messageSender.send(entryToHtml(entry));
Thread.sleep(30000L);
} catch (Exception e) {
// just eat it, eat it
}
i++;
}
}
private String entryToHtml(SyndEntry entry){
StringBuilder html = new StringBuilder("<h2>");
html.append(entry.getTitle());
html.append("</h2>");
html.append(entry.getDescription().getValue());
return html.toString();
}
}
这个类使用 Project Rome 库解析来自 Yahoo Weather 的 RSS feed。如果需要生成或使用 RSS 或 Atom feed，这是一个非常有用的库。此外，这个代码中只有一个地方值得注意，那就是它产生另一个线程，用于每过 30 秒钟发送一次天气数据。最后，我们再看一个地方：使用该 servlet 的客户机代码。在这种情况下，一个简单的 JSP 加上少量的 JavaScript 就足够了。清单 5 显示了该代码。
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Comet Weather</title>
<SCRIPT TYPE="text/javascript">
function go(){
var url = "http://localhost:8484/WeatherServer/Weather"
var request = new XMLHttpRequest();
request.open("GET", url, true);
request.setRequestHeader("Content-Type","application/x-javascript;");
request.onreadystatechange = function() {
if (request.readyState == 4) {
if (request.status == 200){
if (request.responseText) {
document.getElementById("forecasts").innerHTML =
request.responseText;
}
}
go();
/**
做如下修改：
一、JSP页面中客户端多次调用go()，改为一次，把循环调用go()语句注释掉。
二、每次request只有一次write，在MessageSender中注释掉 connection = null; 这样保证每次request有多次response。
Tomcat上说明Comet的模型是“BEGIN -> READ -> READ -> READ -> ERROR/TIMEOUT”，这里使用的get请求，不是post请求，没有使用到Read事件。
*/
}
};
request.send(null);
}
</SCRIPT>
</head>
<body>
<h1>Rapid Fire Weather</h1>
<input type="button" onclick="go()" value="Go!"></input>
<div id="forecasts"></div>
</body>
</html>
该代码只是在用户单击 Go按钮时开始长轮询。注意，它直接使用 XMLHttpRequest 对象，所以这在 Internet Explorer 6 中将不能工作。您可能需要使用一个 Ajax 库解决浏览器差异问题。除此之外，惟一需要注意的是回调函数，或者为请求的 onreadystatechange 函数创建的闭包。该函数粘贴来自服务器的新的数据，然后重新调用 go 函数。
现在，我们看过了一个简单的 Comet 应用程序在 Tomcat 上是什么样的。有两件与 Tomcat 密切相关的事情要做：一是配置它的连接器，二是在 servlet 中实现一个特定于 Tomcat 的接口。您可能想知道，将该代码 “移植” 到 Jetty 有多大难度。接下来我们就来看看这个问题。
Jetty 服务器使用稍微不同的技术来支持 Comet 的可伸缩的实现。Jetty 支持被称作 continuations 的编程结构。其思想很简单。请求先被暂停，然后在将来的某个时间点再继续。规定时间到期，或者某种有意义的事件发生，都可能导致请求继续。当请求被暂停时，它的线程被释放。
可以使用 Jetty 的 org.mortbay.util.ajax.ContinuationSupport 类为任何 HttpServletRequest 创建 org.mortbay.util.ajax.Continuation 的一个实例。这种方法与 Comet 有很大的不同。但是，continuations 可用于实现逻辑上等效的 Comet。清单 6 显示清单 2 中的 weather servlet “移植” 到 Jetty 后的代码。
public class JettyWeatherServlet extends HttpServlet {
private MessageSender messageSender = null;
private static final Integer TIMEOUT = 5 * 1000;
public void begin(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
request.setAttribute("org.apache.tomcat.comet", Boolean.TRUE);
request.setAttribute("org.apache.tomcat.comet.timeout", TIMEOUT);
messageSender.setConnection(response);
Weatherman weatherman = new Weatherman(95118, 32408);
new Thread(weatherman).start();
}
public void end(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
synchronized (request) {
request.removeAttribute("org.apache.tomcat.comet");
Continuation continuation = ContinuationSupport.getContinuation
(request, request);
if (continuation.isPending()) {
continuation.resume();
}
}
}
public void error(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
end(request, response);
}
public boolean read(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
throw new UnsupportedOperationException();
}
@Override
protected void service(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
synchronized (request) {
Continuation continuation = ContinuationSupport.getContinuation
(request, request);
if (!continuation.isPending()) {
begin(request, response);
}
Integer timeout = (Integer) request.getAttribute
("org.apache.tomcat.comet.timeout");
boolean resumed = continuation.suspend(timeout == null ? 10000 :
timeout.intValue());
if (!resumed) {
error(request, response);
}
}
}
public void setTimeout(HttpServletRequest request, HttpServletResponse response,
int timeout) throws IOException, ServletException,
UnsupportedOperationException {
request.setAttribute("org.apache.tomcat.comet.timeout", new Integer(timeout));
}
}
这里最需要注意的是，该结构与 Tomcat 版本的代码非常类似。begin、read、end 和 error 方法都与 Tomcat 中相同的事件匹配。该 servlet 的 service 方法被覆盖为在请求第一次进入时创建一个 continuation 并暂停该请求，直到超时时间已到，或者发生导致它重新开始的事件。上面没有显示 init 和 destroy 方法，因为它们与 Tomcat 版本是一样的。该 servlet 使用与 Tomcat 相同的 MessageSender。因此不需要修改。注意 begin 方法如何创建 Weatherman 实例。对这个类的使用与 Tomcat 版本中也是完全相同的。甚至客户机代码也是一样的。只有 servlet 有更改。虽然 servlet 的变化比较大，但是与 Tomcat 中的事件模型仍是一一对应的。
希望这足以鼓舞人心。虽然完全相同的代码不能同时在 Tomcat 和 Jetty 中运行，但是它是非常相似的。当然，JavaEE 吸引人的一点是可移植性。大多数在 Tomcat 中运行的代码，无需修改就可以在 Jetty 中运行，反之亦然。因此，毫不奇怪，下一个版本的 Java Servlet 规范包括异步请求处理（即 Comet 背后的底层技术）的标准化。 我们来看看这个规范：Servlet 3.0 规范。
在此，我们不深究 Servlet 3.0 规范的全部细节，只看看 Comet servlet 如果在 Servlet 3.0 容器中运行，可能会是什么样子。注意 “可能” 二字。该规范已经发布公共预览版，但在撰写本文之际，还没有最终版。因此，清单 7 显示的是遵从公共预览规范的一个实现。
@WebServlet(asyncSupported=true, asyncTimeout=5000)
public class WeatherServlet extends HttpServlet {
private MessageSender messageSender;
// init and destroy are the same as other
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
AsyncContext async = request.startAsync(request, response);
messageSender.setConnection(async);
Weatherman weatherman = new Weatherman(95118, 32444);
async.start(weatherman);;
}
}
值得高兴的是，这个版本要简单得多。平心而论，如果不遵从 Tomcat 的事件模型，在 Jetty 中可以有类似的实现。这种事件模型似乎比较合理，很容易在 Tomcat 以外的容器（例如 Jetty）中实现，只是没有相关的标准。
回头看看清单 7，注意它的标注声明它支持异步处理，并设置了超时时间。startAsync 方法是 HttpServletRequest 上的一个新方法，它返回新的 javax.servlet.AsyncContext 类的一个实例。注意，MessageSender 现在传递 AsynContext 的引用，而不是 ServletResponse 的引用。在这里，不应该关闭响应，而是调用 AsyncContext 实例上的 complete 方法。还应注意，Weatherman 被直接传递到 AsyncContext 实例的 start 方法。这样将在当前 ServletContext 中开始一个新线程。
而且，尽管与 Tomcat 或 Jetty 相比都有较大的不同，但是修改相同风格的编程来处理 Servlet 3.0 规范提议的 API 并不是太难。还应注意，Jetty 7 是为实现 Servlet 3.0 而设计的，目前处于 beta 状态。但是，在撰写本文之际，它还没有实现该规范的最新版本。
Comet 风格的 Web 应用程序可以为 Web 带来全新的交互性。它为大规模地实现这些特性带来一些复杂的挑战。但是，领先的 Java Web 服务器正在为实现 Comet 提供成熟、稳定的技术。在本文中，您看到了 Tomcat 和 Jetty 上当前风格的 Comet 的不同点和相似点，以及正在进行的 Servlet 3.0 规范的标准化。Tomcat 和 Jetty 使如今构建可伸缩的 Comet 应用程序成为可能，并且明确了未来面向 Servlet 3.0 标准化的升级路线。
代码
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.URL;
import java.util.ArrayList;
import java.util.List;
import javax.servlet.ServletException;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.catalina.CometEvent;
import org.apache.catalina.CometProcessor;
import com.sun.syndication.feed.synd.SyndEntry;
import com.sun.syndication.feed.synd.SyndFeed;
import com.sun.syndication.io.SyndFeedInput;
public class TomcatWeatherServlet extends HttpServlet implements CometProcessor {
private MessageSender messageSender = null;
private static final Integer TIMEOUT = 60 * 1000;
@Override
public void destroy() {
log("destroy()!!!");
messageSender.stop();
messageSender = null;
}
@Override
public void init() throws ServletException {
log("init()!!!");
messageSender = new MessageSender();
Thread messageSenderThread =
new Thread(messageSender, "MessageSender[" + getServletContext().getContextPath() + "]");
messageSenderThread.setDaemon(true);
messageSenderThread.start();
}
public void event(final CometEvent event) throws IOException, ServletException {
HttpServletRequest request = event.getHttpServletRequest();
HttpServletResponse response = event.getHttpServletResponse();
if (event.getEventType() == CometEvent.EventType.BEGIN) {
request.setAttribute("org.apache.tomcat.comet.timeout", TIMEOUT);
log("Begin for session: " + request.getSession(true).getId());
messageSender.setConnection(response);
Weatherman weatherman = new Weatherman(95118, 32408);
weatherman.start();
} else if (event.getEventType() == CometEvent.EventType.ERROR) {
log("Error for session: " + request.getSession(true).getId());
event.close();
} else if (event.getEventType() == CometEvent.EventType.END) {
log("End for session: " + request.getSession(true).getId());
event.close();
} else if (event.getEventType() == CometEvent.EventType.READ) {
throw new UnsupportedOperationException("This servlet does not accept data");
}
}
private class Weatherman {
private final List<URL> zipCodes;
private final String YAHOO_WEATHER = "http://weather.yahooapis.com/forecastrss?p=";
public Weatherman(Integer... zips) {
zipCodes = new ArrayList<URL>(zips.length);
for (Integer zip : zips) {
try {
zipCodes.add(new URL(YAHOO_WEATHER + zip));
} catch (Exception e) {
// dont add it if it sucks
}
}
}
public void start() {
Runnable r = new Runnable() {
public void run() {
int i = 0;
while (i >= 0) {
int j = i % zipCodes.size();
SyndFeedInput input = new SyndFeedInput();
try {
SyndFeed feed = input.build(new InputStreamReader(zipCodes.get(j).openStream()));
SyndEntry entry = (SyndEntry) feed.getEntries().get(0);
messageSender.send(entryToHtml(entry));
Thread.sleep(30000L);
} catch (Exception e) {
// just eat it, eat it
}
i++;
}
}
};
Thread t = new Thread(r);
t.start();
}
private String entryToHtml(SyndEntry entry){
StringBuilder html = new StringBuilder("<h2>");
html.append(entry.getTitle());
html.append("</h2>");
html.append(entry.getDescription().getValue());
return html.toString();
}
}
private class MessageSender implements Runnable {
protected boolean running = true;
protected final ArrayList<String> messages = new ArrayList<String>();
private ServletResponse connection;
private synchronized void setConnection(ServletResponse connection){
this.connection = connection;
notify();
}
public void stop() {
running = false;
}
/**
* Add message for sending.
*/
public void send(String message) {
synchronized (messages) {
messages.add(message);
log("Message added #messages=" + messages.size());
messages.notify();
}
}
public void run() {
log("start running!!!");
while (running) {
if (messages.size() == 0) {
try {
synchronized (messages) {
log("start waiting!!!");
messages.wait();
}
} catch (InterruptedException e) {
// Ignore
}
}
String[] pendingMessages = null;
synchronized (messages) {
pendingMessages = messages.toArray(new String[0]);
messages.clear();
}
try {
if (connection == null){
try{
synchronized(this){
wait();
}
} catch (InterruptedException e){
// Ignore
}
}
PrintWriter writer = connection.getWriter();
for (int j = 0; j < pendingMessages.length; j++) {
final String forecast = pendingMessages[j] + "<br>";
writer.println(forecast);
log("Writing:" + forecast);
}
writer.flush();
writer.close();
//connection = null;
log("Closing connection");
} catch (IOException e) {
log("IOExeption sending message", e);
}
}
}
}
}
2 Comet：基于 HTTP 长连接的“服务器推”技术
源地址：http://www.ibm.com/developerworks/cn/web/wa-lo-comet/
周婷 ([email protected]), 软件工程师, IBM 中国软件开发技术实验室
简介： 很多应用譬如监控、即时通信、即时报价系统都需要将后台发生的变化实时传送到客户端而无须客户端不停地刷新、发送请求。本文首先介绍、比较了常用的“服务器推”方案，着重介绍了 Comet － 使用 HTTP 长连接、无须浏览器安装插件的两种“服务器推”方案：基于 AJAX 的长轮询方式；基于 iframe 及 htmlfile 的流方式。最后分析了开发 Comet 应用需要注意的一些问题，以及如何借助开源的 Comet 框架－pushlet 构建自己的“服务器推”应用。
本文的标签: ajax, http_(hypertext_transfer_protocol), java_技术, 应用开发
发布日期： 2007 年 8 月 31 日
级别： 中级
访问情况 14703 次浏览
建议: 1 (查看或添加评论)
平均分 （共 32 个评分 ）
请访问 Ajax 技术资源中心，这是有关 Ajax 编程模型信息的一站式中心，包括很多文档、教程、论坛、blog、wiki 和新闻。任何 Ajax 的新信息都能在这里找到。
| |
|
|
| |
|
|
| |
|
|
传统模式的 Web 系统以客户端发出请求、服务器端响应的方式工作。这种方式并不能满足很多现实应用的需求，譬如：
- 监控系统：后台硬件热插拔、LED、温度、电压发生变化；
- 即时通信系统：其它用户登录、发送信息；
- 即时报价系统：后台数据库内容发生变化；
这些应用都需要服务器能实时地将更新的信息传送到客户端，而无须客户端发出请求。“服务器推”技术在现实应用中有一些解决方案，本文将这些解决方案分为两类：一类需要在浏览器端安装插件，基于套接口传送信息，或是使用 RMI、CORBA 进行远程调用；而另一类则无须浏览器安装任何插件、基于 HTTP 长连接。
将“服务器推”应用在 Web 程序中，首先考虑的是如何在功能有限的浏览器端接收、处理信息：
- 客户端如何接收、处理信息，是否需要使用套接口或是使用远程调用。客户端呈现给用户的是 HTML 页面还是 Java applet 或 Flash 窗口。如果使用套接口和远程调用，怎么和 JavaScript 结合修改 HTML 的显示。
- 客户与服务器端通信的信息格式，采取怎样的出错处理机制。
- 客户端是否需要支持不同类型的浏览器如 IE、Firefox，是否需要同时支持 Windows 和 Linux 平台。
如果 Web 应用的用户接受应用只有在安装了 Flash 播放器才能正常运行， 那么使用 Flash 的 XMLSocket 也是一个可行的方案。
这种方案实现的基础是：
- Flash 提供了 XMLSocket 类。
- JavaScript 和 Flash 的紧密结合：在 JavaScript 可以直接调用 Flash 程序提供的接口。
具体实现方法：在 HTML 页面中内嵌入一个使用了 XMLSocket 类的 Flash 程序。JavaScript 通过调用此 Flash 程序提供的套接口接口与服务器端的套接口进行通信。JavaScript 在收到服务器端以 XML 格式传送的信息后可以很容易地控制 HTML 页面的内容显示。
关于如何去构建充当了 JavaScript 与 Flash XMLSocket 桥梁的 Flash 程序，以及如何在 JavaScript 里调用 Flash 提供的接口，我们可以参考 AFLAX（Asynchronous Flash and XML）项目提供的 Socket Demo 以及 SocketJS（请参见 参考资源）。
Javascript 与 Flash 的紧密结合，极大增强了客户端的处理能力。从 Flash 播放器 V7.0.19 开始，已经取消了 XMLSocket 的端口必须大于 1023 的限制。Linux 平台也支持 Flash XMLSocket 方案。但此方案的缺点在于：
- 客户端必须安装 Flash 播放器；
- 因为 XMLSocket 没有 HTTP 隧道功能，XMLSocket 类不能自动穿过防火墙；
- 因为是使用套接口，需要设置一个通信端口，防火墙、代理服务器也可能对非 HTTP 通道端口进行限制；
不过这种方案在一些网络聊天室，网络互动游戏中已得到广泛使用。
在客户端使用 Java Applet，通过 java.net.Socket或 java.net.DatagramSocket或 java.net.MulticastSocket建立与服务器端的套接口连接，从而实现“服务器推”。
这种方案最大的不足在于 Java applet 在收到服务器端返回的信息后，无法通过 JavaScript 去更新 HTML 页面的内容。
浏览器作为 Web 应用的前台，自身的处理功能比较有限。浏览器的发展需要客户端升级软件，同时由于客户端浏览器软件的多样性，在某种意义上，也影响了浏览器新技术的推广。在 Web 应用中，浏览器的主要工作是发送请求、解析服务器返回的信息以不同的风格显示。AJAX 是浏览器技术发展的成果，通过在浏览器端发送异步请求，提高了单用户操作的响应性。但 Web 本质上是一个多用户的系统，对任何用户来说，可以认为服务器是另外一个用户。现有 AJAX 技术的发展并不能解决在一个多用户的 Web 应用中，将更新的信息实时传送给客户端，从而用户可能在“过时”的信息下进行操作。而 AJAX 的应用又使后台数据更新更加频繁成为可能。
图 1. 传统的 Web 应用模型与基于 AJAX 的模型之比较
“服务器推”是一种很早就存在的技术，以前在实现上主要是通过客户端的套接口，或是服务器端的远程调用。因为浏览器技术的发展比较缓慢，没有为“服务器推”的实现提供很好的支持，在纯浏览器的应用中很难有一个完善的方案去实现“服务器推”并用于商业程序。最近几年，因为 AJAX 技术的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 组件中可以解决 IE 的加载显示问题，一些受欢迎的应用如 meebo，gmail+gtalk 在实现中使用了这些新技术；同时“服务器推”在现实应用中确实存在很多需求。因为这些原因，基于纯浏览器的“服务器推”技术开始受到较多关注，Alex Russell（Dojo Toolkit 的项目 Lead）称这种基于 HTTP 长连接、无须在浏览器端安装插件的“服务器推”技术为“Comet”。目前已经出现了一些成熟的 Comet 应用以及各种开源框架；一些 Web 服务器如 Jetty 也在为支持大量并发的长连接进行了很多改进。关于 Comet 技术最新的发展状况请参考关于 Comet 的 wiki。
下面将介绍两种 Comet 应用的实现模型。
如 图 1 所示，AJAX 的出现使得 JavaScript 可以调用 XMLHttpRequest 对象发出 HTTP 请求，JavaScript 响应处理函数根据服务器返回的信息对 HTML 页面的显示进行更新。使用 AJAX 实现“服务器推”与传统的 AJAX 应用不同之处在于：
- 服务器端会阻塞请求直到有数据传递或超时才返回。
- 客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。
- 当客户端处理接收的数据、重新建立连接时，服务器端可能有新的数据到达；这些信息会被服务器端保存直到客户端重新建立连接，客户端会一次把当前服务器端所有的信息取回。
一些应用及示例如 “Meebo”, “Pushlet Chat” 都采用了这种长轮询的方式。相对于“轮询”（poll），这种长轮询方式也可以称为“拉”（pull）。因为这种方案基于 AJAX，具有以下一些优点：请求异步发出；无须安装插件；IE、Mozilla FireFox 都支持 AJAX。
在这种长轮询方式下，客户端是在 XMLHttpRequest 的 readystate 为 4（即数据传输结束）时调用回调函数，进行信息处理。当 readystate 为 4 时，数据传输结束，连接已经关闭。Mozilla Firefox 提供了对 Streaming AJAX 的支持， 即 readystate 为 3 时（数据仍在传输中），客户端可以读取数据，从而无须关闭连接，就能读取处理服务器端返回的信息。IE 在 readystate 为 3 时，不能读取服务器返回的数据，目前 IE 不支持基于 Streaming AJAX。
基于 Iframe 及 htmlfile 的流（streaming）方式
iframe 是很早就存在的一种 HTML 标记， 通过在 HTML 页面里嵌入一个隐蔵帧，然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。
上节提到的 AJAX 方案是在 JavaScript 里处理 XMLHttpRequest 从服务器取回的数据，然后 Javascript 可以很方便的去控制 HTML 页面的显示。同样的思路用在 iframe 方案的客户端，iframe 服务器端并不返回直接显示在页面的数据，而是返回对客户端 Javascript 函数的调用，如“<script type="text/javascript">js_func(“data from server ”)</script>”。服务器端将返回的数据作为客户端 JavaScript 函数的参数传递；客户端浏览器的 Javascript 引擎在收到服务器返回的 JavaScript 调用时就会去执行代码。
从 图 3 可以看到，每次数据传送不会关闭连接，连接只会在通信出现错误时，或是连接重建时关闭（一些防火墙常被设置为丢弃过长的连接， 服务器端可以设置一个超时时间， 超时后通知客户端重新建立连接，并关闭原来的连接）。
使用 iframe 请求一个长连接有一个很明显的不足之处：IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成，而且 IE 上方的图标会不停的转动，表示加载正在进行。Google 的天才们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题，并将这种方法用到了 gmail+gtalk 产品中。Alex Russell 在 “What else is burried down in the depth's of Google's amazing JavaScript?”文章中介绍了这种方法。Zeitoun 网站提供的 comet-iframe.tar.gz，封装了一个基于 iframe 和 htmlfile 的 JavaScript comet 对象，支持 IE、Mozilla Firefox 浏览器，可以作为参考。（请参见 参考资源）
上面介绍了两种基于 HTTP 长连接的“服务器推”架构，更多描述了客户端处理长连接的技术。对于一个实际的应用而言，系统的稳定性和性能是非常重要的。将 HTTP 长连接用于实际应用，很多细节需要考虑。
我们使用 IE 下载文件时会有这样的体验，从同一个 Web 服务器下载文件，最多只能有两个文件同时被下载。第三个文件的下载会被阻塞，直到前面下载的文件下载完毕。这是因为 HTTP 1.1 规范中规定，客户端不应该与服务器端建立超过两个的 HTTP 连接， 新的连接会被阻塞。而 IE 在实现中严格遵守了这种规定。
HTTP 1.1 对两个长连接的限制，会对使用了长连接的 Web 应用带来如下现象：在客户端如果打开超过两个的 IE 窗口去访问同一个使用了长连接的 Web 服务器，第三个 IE 窗口的 HTTP 请求被前两个窗口的长连接阻塞。
所以在开发长连接的应用时， 必须注意在使用了多个 frame 的页面中，不要为每个 frame 的页面都建立一个 HTTP 长连接，这样会阻塞其它的 HTTP 请求，在设计上考虑让多个 frame 的更新共用一个长连接。
一般 Web 服务器会为每个连接创建一个线程，如果在大型的商业应用中使用 Comet，服务器端需要维护大量并发的长连接。在这种应用背景下，服务器端需要考虑负载均衡和集群技术；或是在服务器端为长连接作一些改进。
应用和技术的发展总是带来新的需求，从而推动新技术的发展。HTTP 1.1 与 1.0 规范有一个很大的不同：1.0 规范下服务器在处理完每个 Get/Post 请求后会关闭套接口连接； 而 1.1 规范下服务器会保持这个连接，在处理两个请求的间隔时间里，这个连接处于空闲状态。 Java 1.4 引入了支持异步 IO 的 java.nio 包。当连接处于空闲时，为这个连接分配的线程资源会返还到线程池，可以供新的连接使用；当原来处于空闲的连接的客户发出新的请求，会从线程池里分配一个线程资源处理这个请求。 这种技术在连接处于空闲的机率较高、并发连接数目很多的场景下对于降低服务器的资源负载非常有效。
但是 AJAX 的应用使请求的出现变得频繁，而 Comet 则会长时间占用一个连接，上述的服务器模型在新的应用背景下会变得非常低效，线程池里有限的线程数甚至可能会阻塞新的连接。Jetty 6 Web 服务器针对 AJAX、Comet 应用的特点进行了很多创新的改进，请参考文章“AJAX，Comet and Jetty”（请参见 参考资源）。
使用长连接时，存在一个很常见的场景：客户端网页需要关闭，而服务器端还处在读取数据的堵塞状态，客户端需要及时通知服务器端关闭数据连接。服务器在收到关闭请求后首先要从读取数据的阻塞状态唤醒，然后释放为这个客户端分配的资源，再关闭连接。
所以在设计上，我们需要使客户端的控制请求和数据请求使用不同的 HTTP 连接，才能使控制请求不会被阻塞。
在实现上，如果是基于 iframe 流方式的长连接，客户端页面需要使用两个 iframe，一个是控制帧，用于往服务器端发送控制请求，控制请求能很快收到响应，不会被堵塞；一个是显示帧，用于往服务器端发送长连接请求。如果是基于 AJAX 的长轮询方式，客户端可以异步地发出一个 XMLHttpRequest 请求，通知服务器端关闭数据连接。
在浏览器与服务器之间维持一个长连接会为通信带来一些不确定性：因为数据传输是随机的，客户端不知道何时服务器才有数据传送。服务器端需要确保当客户端不再工作时，释放为这个客户端分配的资源，防止内存泄漏。因此需要一种机制使双方知道大家都在正常运行。在实现上：
- 服务器端在阻塞读时会设置一个时限，超时后阻塞读调用会返回，同时发给客户端没有新数据到达的心跳信息。此时如果客户端已经关闭，服务器往通道写数据会出现异常，服务器端就会及时释放为这个客户端分配的资源。
- 如果客户端使用的是基于 AJAX 的长轮询方式；服务器端返回数据、关闭连接后，经过某个时限没有收到客户端的再次请求，会认为客户端不能正常工作，会释放为这个客户端分配、维护的资源。
- 当服务器处理信息出现异常情况，需要发送错误信息通知客户端，同时释放资源、关闭连接。
Pushlet 是一个开源的 Comet 框架，在设计上有很多值得借鉴的地方，对于开发轻量级的 Comet 应用很有参考价值。
观察者模型
Pushlet 使用了观察者模型：客户端发送请求，订阅感兴趣的事件；服务器端为每个客户端分配一个会话 ID 作为标记，事件源会把新产生的事件以多播的方式发送到订阅者的事件队列里。
客户端 JavaScript 库
pushlet 提供了基于 AJAX 的 JavaScript 库文件用于实现长轮询方式的“服务器推”；还提供了基于 iframe 的 JavaScript 库文件用于实现流方式的“服务器推”。
JavaScript 库做了很多封装工作：
- 定义客户端的通信状态：
STATE_ERROR、STATE_ABORT、STATE_NULL、STATE_READY、STATE_JOINED、STATE_LISTENING； - 保存服务器分配的会话 ID，在建立连接之后的每次请求中会附上会话 ID 表明身份；
- 提供了
join()、leave()、subscribe()、unsubsribe()、listen()等 API 供页面调用； - 提供了处理响应的 JavaScript 函数接口
onData()、onEvent()…
网页可以很方便地使用这两个 JavaScript 库文件封装的 API 与服务器进行通信。
客户端与服务器端通信信息格式
pushlet 定义了一套客户与服务器通信的信息格式，使用 XML 格式。定义了客户端发送请求的类型：join、leave、subscribe、unsubscribe、listen、refresh；以及响应的事件类型：data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。
服务器端事件队列管理
pushlet 在服务器端使用 Java Servlet 实现，其数据结构的设计框架仍可适用于 PHP、C 编写的后台客户端。
Pushlet 支持客户端自己选择使用流、拉（长轮询）、轮询方式。服务器端根据客户选择的方式在读取事件队列（fetchEvents）时进行不同的处理。“轮询”模式下 fetchEvents()会马上返回。”流“和”拉“模式使用阻塞的方式读事件，如果超时，会发给客户端发送一个没有新信息收到的“heartbeat“事件，如果是“拉”模式，会把“heartbeat”与“refresh”事件一起传给客户端，通知客户端重新发出请求、建立连接。
客户服务器之间的会话管理
服务端在客户端发送 join请求时，会为客户端分配一个会话 ID， 并传给客户端，然后客户端就通过此会话 ID 标明身份发出 subscribe和 listen请求。服务器端会为每个会话维护一个订阅的主题集合、事件队列。
服务器端的事件源会把新产生的事件以多播的方式发送到每个会话（即订阅者）的事件队列里。
本文介绍了如何在现有的技术基础上选择合适的方案开发一个“服务器推”的应用，最优的方案还是取决于应用需求的本身。相对于传统的 Web 应用， 目前开发 Comet 应用还是具有一定的挑战性。
“服务器推”存在广泛的应用需求，为了使 Comet 模型适用于大规模的商业应用，以及方便用户构建 Comet 应用，最近几年，无论是服务器还是浏览器都出现了很多新技术，同时也出现了很多开源的 Comet 框架、协议。需求推动技术的发展，相信 Comet 的应用会变得和 AJAX 一样普及。
学习
- developerWorks 文章“ 面向 Java 开发人员的 Ajax: 使用 Jetty 和 Direct Web Remoting 编写可扩展的 Comet 应用程序”：受异步服务器端事件驱动的 Ajax 应用程序实现较为困难，本文介绍了一种结合使用 Comet 模式和 Jetty 6 Continuations API 的解决方法。
- “Comet: Low Latency Data for the Browser”：Alex Russell 是 Dojo Toolkit 的项目主管和 Dojo Foundation 的主_席，他在这篇博客文章中提出了 Comet这个术语。
- “What else is burried down in the depth’s of Google’s amazing JavaScript?”（Alex Russel，2006 年 2 月）：Alex 在这篇文章里介绍了如何使用“htmlfile”ActiveX 控件解决 iframe 请求长连接时 IE 的加载显示问题。
- Comet wiki：提供了很多开源 Comet 框架的链接。
- Jetty：Jetty 是一种开源的基于标准的 Web 服务器，完全使用 Java 语言实现。
- “Ajax, Comet and Jetty”（Greg Wilkins，Webtide，2006 年 1 月）：Wilkins 的这份白皮书讨论了扩展 Ajax 连接的 Jetty 架构方法。
- Continuations：了解更多关于 Jetty 的 Continuations 特性的信息。
- “pushlet”：开源 comet 框架，使用了观察者模型。浏览器端提供了基于 AJAX 和 iframe 的 JavaScript 库，服务器端使用 Java Servlet。
- “How to implement COMET with PHP”：提供的 comet-iframe.tar.gz 使用 iframe/htmlfile 封装了一个 JavaScript comet 对象，支持 IE、Mozilla Firefox 浏览器。
- “AFLAX”：Asynchronous Flash and XML，提供了强大的 Flash、Javascript 库和很多范例。
- developerWorks Ajax 技术资源中心：能找到更多关于 Ajax 技术的文章和教程。
- developerWorks Web 开发技术专区：提供了关于 Web 开发和架构方面的大量文章。
- developerWorks Java 技术专区：提供了关于 Java 编程各个方面的数百篇文章。
- 浏览 技术书店，查阅有关本文所述主题以及其他技术主题的书籍。
3 Cometd & Jetty Continuations
Posted in Java - 7 七月 2010 - 1 comment
Contents
前言：随着web的不断发展，出现了诸如ajax，comet等技术，其实都是为了提高用户体验。在web并发量越来越高的今天，异步成了一个热点。servlet3.0也引入了异步处理的概念。
Comet是一种服务器端推的技术，所谓服务器端推也就是当有事件要通知给某个用户的时候，是由服务器端直接发送到用户的浏览器。
服务器端Push目前一般有两种方式，HTTP streaming和Long polling。详细的介绍可以看这里 http://en.wikipedia.org/wiki/Push_technology
有一个Comet的框架叫做Cometd，使用的方式为Long polling。它是使用了jetty continuations特性，jetty continuations使得异步的request成为可能，这里我们来讨论下为何需要jetty continuations呢？
比如我们的浏览器的一个请求发送到服务器端了，并进行长轮询，保持了连接不结束，直到一次长轮询timeout或者有事件发生，并接收到服务端推来 的消息，所以在一次长轮询的过程中，大部分时间都是在等待，如果使用老式同步的方式进行编程的话，那么有多少个连接就需要多少个线程在那里，而大都数都是 在等待，所以这无疑是系统资源的巨大浪费。
jetty continuations很好的解决了这一问题，当有请求过来之后，将连接的相关信息封装到一个continuation的对象中，通过调用 continuation的suspend方法，然后返回，把当前线程交还到线程池，所以这个时候线程可以返回到线程池等待并处理其他新的请求。
当有事件要发给之前的某个请求的时候，再调用对应的continuation的resume方法，将原来的哪个请求重新发送到servelt进行处理，并将消息发送给客户端，然后客户端会重新进行一次长轮询。
下面我来由上而下详细讲述jetty continuation实现方式
一.Cometd
Cometd是一个Comet的框架，实现方式为基于jetty continuation的长轮询。
Cometd的消息都基于一个叫做Bayeux的消息协议
Bayeux的主要目的是支持使用ajax的客户端与服务器端之间灵敏，快速的信息交互。
Bayeux是一种用来在客户端和服务器端传输低延迟的异步消息（主要通过http）的一种协议。它定义的消息通过命名通道进行路由并且能够进行交 互传 送：server -> client, client -> server 甚至 client -> client （当然还是需要通过server中转）。默认的，此通道已经引用了发布的路由语义，但同时也支持其它路由模块。
从服务器端向客户端异步发送的数据通常被叫做 “服务器推”（server-push）。这种使用ajax的web应用和服务器推技术的结合称作“Comet”。 Cometd是一个提供多种开发语言的Bayeux项目，由Dojo基金会提供支持。
1.Cometd Server
在服务器端推中，一个常见的应用场景便是，消息的生产者可以往一些消息channel中通过bayeux协议发送消息，服务器端对bayeux消息 进行处理解析，发送到所有订阅了这个channel的消息消费者，消费者接收到这个消息之后便可以自己再做自己的处理。在这样的模型中于是出现了几个重要 的概念：
Bayeux
这个在cometd框架中是ContinuationBayeux类，
bayeux对象在cometd运行的上下文中非常重要，可以说是一个核心对象，它管理着所有的clients和channel，并肩负着消息的处理和维护。
channel在cometd中是一个树形的结构，在bayeux对象中，保存着根channel（/），从根channel我们可以找到它的子channel
bayeux存在一个handle方法，对消息进行处理
Client
一个client对应着一个消息的生产者或者消费者，对应的类为ContinuationClient。
client中包含一个contiunation对象，以及对continuation对象进行操作的suspend和resume的方法
subscriptions保存着当前client的所有订阅的频道channel
client由一个clientId唯一标示，每一个client还对应着一个browserId。
client可以通过deliver方法来进行接受消息操作，接受消息无非就是将接收到的消息加入到自己的消息队列中，并将continuation对象进行resume，这样之前冻结的request重新发送到servlet进行处理。
Channel
channel在cometd中对应ChannelImpl类
channel中维护这一个subscribers的列表，用来保存订阅了当前channel的订阅者
channel还维护者自己的子channel
每一个channel都对应这一个channelId 也就是channel的路径字符串
ContinuationCometdServlet
Cometd Server运行时的入口为ContinuationCometdServlet
Handshake
客户端和服务器端建立连接之前需要先握手，在服务器端将客户端标识起来。一个请求过来如果cookie中没有broswer_id那么就生成一个 broswer_id(相当于session_id 因为这些请求并非无状态的，需要在多次长轮询中记住请求是来自同一个客户端),并写到cookie中。握手的时候还会生成一个 ContinuationClient对象，每一个ContinuationClient对象由一个client_id唯一标识。并在握手成功后将这个 clientId作为消息的一部分发给客户端。由于握手的消息是属于元数据消息，所以在Bayeux中提供了所有元消息channel的Handler。 这些handler最终将消息交给各种Transport去发送，Tranport对象 此类对象主要是用来处理消息的发送，比如JSONTransport或者JSONPTransport，这两个对象中都有response的引用，所以可 以用来直接回复客户端。
Subscribe
订阅的主要作用是将订阅某个Channel的客户端所对应的ContinuationClient对象加入到对应的channel的 subscribers列表中，并将所订阅的channel加入到ContinuationClient对象的subscriptions数组中。订阅成 功之后就应该开始了long-pooling了，这个时候，服务器端会将当前的请求封装到一个Continuation中，并将Continuation 对象设到ContinuationClient对象中，然后将ContinuationClient对象suspend，让出当前处理线程。
Publish
当一个客户端往一个channel中publish消息的时候，服务器端接收到这个message，有两种方式处理这个消息，一个是在相应的 channel中广播这个消息，这个时候调用channel的push方法，对每一个订阅了当前channel及其子channel中的 ContinuationClient进行消息分发，将消息复制到每一个ContinuationClient自己的消息队列中，并将 ContinuationClient中的Continuation唤醒resume。这个时候之前暂停的request会被重新发送到servlet， 并且servlet可以知道其状态，并进行消息的处理。还有一种消息的发送是直接调用某个ContinuationClient对象进行消息的发送。
2.Cometd Client
上面讲了服务器端的各种情况的处理，当然光有服务器端的处理是没有用的，还需要客户端的配合。
客户端既可以是后端的java程序，更多的时候是浏览器。
浏览器中采用Ajax的方式和服务器进行交互，cometd提供了基于dojo和jquery两个js框架的cometd-client
二.Jetty NIO & Continuation
在Cometd部分提及到当服务器端接收到来自客户端发来的消息，然后对消息进行处理。当然在web应用中，消息的接受最初都是由web容器来接受，这涉及到了socket的处理，这个时候web容器本身的io性能就非常重要了。
在传统的BIO服务器模型中，一个新的连接来了，就要创建一个线程来接受这个socket连接（一个连接一个线程），进行简单的封装后，分发给web容器的”线程池“，线程池会选择一个线程来处理连接请求并给予响应。
而在NIO的模型中，只需要一个线程便可以处理所有的连接，当有新的连接建立的时候，只需要将连接注册到selector中，直到某次检测到有请求了，便开始对请求进行处理，并将他们都交给”线程池“（所有的连接都是一个线程在处理，直到发现了请求，再将请求分发出去）。
在高效的Comet应用的最底层还需要一个高效的web容器。
1.Jetty Server With NIO
Jetty是一个纯java实现的非常轻量级的web容器，高度组件化，可以很方便的将各种组件进行组装，而且可以非常容易的将jetty嵌入到自己的应用中。
jetty运行时的核心类是Server类，这个类的配置一般在jetty.xml中配置，然后jetty自带的一个简单的ioc容器将server加载初始化。
下图主要描述了Jetty在NIO的模式下工作的情形，这里只说到将任务分配到ThreadPool，后面的ThreadPool的处理没有说，大家可以去看下源码。
在jetty中，web容器启动是从Server开始的，一个Server可以对应多个Connector，从名字就可以知道，Connector是来处 理外部连接的，Connector的实现有多种，即可以是非阻塞的（如SelectChannelConnector），也可以是阻塞的（如 BlockingChannelConnector，当然jetty中这个阻塞的已经使用nio优化过，性能应该比使用java io实现的好），
我们不能直接说谁的性能好，谁的性能不好，关键还是看应用场景，因为NIO实现的非阻塞的话，doSelect的过程是阻塞的。所以当并发量小，且请求可 以快速得到响应的话，用阻塞的就可以很好的满足了，但是当并发量很大，且后端资源紧张，请求需要等待很长一段时间的（比如长轮询），那么NIO的性能肯定 必传统的高很多很多倍。
这里稍微讲一下NIO的概念把，在NIO的Scoket通讯模型中，一个socket连接对应一个 SocketChannel，SocketChannel可以将某个事件注册到某一个Selector上，然后对Selector进行select操作， 当有请求来的时候，并可以通过Selector的selectedKeys()获得所有收到事件的channel，然后便可以对channel进行操作 了。这个其实和linux中的select函数类似，只不过这里是面向对象的，在linux中，我们将需要监听的sockt连接加入到一个文件描述符的集 合中FD_SET中，然后select函数对这个集合进行检测，根据得到的结果来判断某个fd对应的标志位是否为1来判断是否有数据。这样也就是一个线程 可以同事处理多个连接。
换话题了，我们都知道请求最终都是在Servlet中被处理的，而Servlet得到的是request，response，这些对象什么时候出来 的呢？不急，上面不是说到一个EndPoint（实现了Runnable接口）EndPoint对象在被初始化的时候就对其_connection成员进 行了初始化，生成一个HttpConnection对象，newConnection的方法其实在SelectChannelConnector中被覆盖 了。然后这个EndPoint对象不是被分配到ThreadPool了么，ThreadPool将其加入到队列中，当有空闲线程的时候，就对这个 endPoint对象进行处理了，运行EndPoint的run方法,然后会调用自己的connection对象的handle方法，最终将 connection对象交给Server的handler进行处理。Server本身继承自HandlerWrapper，自己的_handler是一 个HandlerCollection的实例，HandlerCollection实例的配置在jetty.xml中有配置，在处理 httpconnection对象的时候所配置的handler会依次被执行。
DefaultHandler中就涉及到上下文处理，然后交给各个项目的servlet进行处理。
2.Jetty Continuation
Jetty Continuation在jetty7的实现中也就8个类，非常的简洁。
ContinuationSupport类是产生Continuation对象的工厂类。它会根据当前服务器容器的类型选择不同类型的 Continuation对象，比如支持jetty6版本的，还有支持servlet3.0版本（对servlet3.0异步处理进行了封装），还有一个 阻塞的Continuation实现FauxContinuation。