Jetty 与 Direct Web Remotin.docVIP

Jetty 和 Direct Web Remotin 简介：受异步服务器端事件驱动的Ajax应用程序实现较为困难，并且难于扩展。Philip McCarthy在其广受欢迎的系列文章中介绍了一种行之有效的方法：结合使用Comet模式(将数据推到客户机)和Jetty 6的Continuations API(将Comet应用程序扩展到大量客户机中)。您可以方便地在Direct Web Remoting(DWR)2中将Comet和Continuations与Reverse Ajax技术结合使用。 查看本系列更多内容 标记本文！ 原文地址：发布日期：2007年8月02日 级别：中级 访问情况69次浏览 建议：0(添加评论) 平均分(共1个评分)作为一种广泛使用的Web应用程序开发技术，Ajax牢固确立了自己的地位，随之而来的是一些通用Ajax使用模式。例如，Ajax经常用于对用户输入作出响应，然后使用从服务器获得的新数据修改页面的部分内容。但是，有时Web应用程序的用户界面需要进行更新以响应服务器端发生的异步事件，而不需要用户操作--例如，显示到达Ajax聊天应用程序的新消息，或者在文本编辑器中显示来自另一个用户的改变。由于只能由浏览器建立Web浏览器和服务器之间的HTTP连接，服务器无法在改动发生时将变化推送给浏览器。 Ajax应用程序可以使用两种基本的方法解决这一问题：一种方法是浏览器每隔若干秒时间向服务器发出轮询以进行更新，另一种方法是服务器始终打开与浏览器的连接并在数据可用时发送给浏览器。长期连接技术被称为Comet(请参阅参考资料)。本文将展示如何结合使用Jetty servlet引擎和DWR简捷有效地实现一个Comet Web应用程序。 为什么使用Comet? 轮询方法的主要缺点是：当扩展到更多客户机时，将生成大量的通信量。每个客户机必须定期访问服务器以检查更新，这为服务器资源添加了更多负荷。最坏的一种情况是对不频繁发生更新的应用程序使用轮询，例如一种Ajax邮件Inbox。在这种情况下，相当数量的客户机轮询是没有必要的，服务器对这些轮询的回答只会是没有产生新数据。虽然可以通过增加轮询的时间间隔来减轻服务器负荷，但是这种方法会产生不良后果，即延迟客户机对服务器事件的感知。当然，很多应用程序可以实现某种权衡，从而获得可接受的轮询方法。 尽管如此，吸引人们使用Comet策略的其中一个优点是其显而易见的高效性。客户机不会像使用轮询方法那样生成烦人的通信量，并且事件发生后可立即发布给客户机。但是保持长期连接处于打开状态也会消耗服务器资源。当等待状态的servlet持有一个持久性请求时，该servlet会独占一个线程。这将限制Comet对传统servlet引擎的可伸缩性，因为客户机的数量会很快超过服务器栈能有效处理的线程数量。 回页首 Jetty 6有何不同 Jetty 6的目的是扩展大量同步连接，使用Java语言的非阻塞I/O(java.nio)库并使用一个经过优化的输出缓冲架构(参阅参考资料)。Jetty还为处理长期连接提供了一些技巧：该特性称为Continuations。我将使用一个简单的servlet对Continuations进行演示，这个servlet将接受请求，等待处理，然后发送响应。接下来，我将展示当客户机数量超过服务器提供的处理线程后发生的状况。最后，我将使用Continuations重新实现servlet，您将了解Continuations在其中扮演的角色。 为了便于理解下面的示例，我将把Jetty servlet引擎限制在一个单请求处理线程。清单1展示了jetty.xml中的相关配置。我实际上需要在ThreadPool使用三个线程：Jetty服务器本身使用一个线程，另一线程运行HTTP连接器，侦听到来的请求。第三个线程执行servlet代码。 清单1.单个servlet线程的Jetty配置 ?xml version=1.0? ！DOCTYPE Configure PUBLIC-//Mort Bay Consulting//DTD Configure//EN Configure id=Serverclass=org.mortbay.jetty.Server Set name=ThreadPool New class=org.mortbay.thread.BoundedThreadPool Set name=minThreads3/Set Set name=lowThreads0/Set Set name=maxThreads3/Set /New /Set /Configure 接下来，为了模拟对异步事件的等待，清单2展示了BlockingServlet的service()方法，该方法将使用Thread.sleep