What's new in Jetty6

最近由于工作需要研究了一下Jetty6。发现Jetty6除了支持NIO，更重要的是它在系统架构上为新兴的Ajax提供更好的支持。

这里需要介绍两个新词 一个是Comet， 一个是Continuations。
这里我先卖个关子，在下面的文章中我会给大家详细解释这两个名词和Jetty6的关系。
 
写过Web应用的朋友应该会有这样的一个体会，就是我们常规的Web访问模式就是客户端发送一个请求(Request)，服务器端提供一个响应(Response)。
这样做很简单，服务器端是被动接受请求，并执行相应的处理逻辑，返回处理结果。
这样的模式会带来一个问题就是，在我们的客户端没有任何输入的情况下，而这时产生的一个事件服务器需要主动向客户端(push)发送消息的时候，上面的Request/Response模式就不灵了。

例如我们在Web上实现一个聊天程序，客户端向服务器端发送消息，服务器将客户端发送的消息转发到各个连接到服务器的客户端上。这时有两个客户端A,B连接到服务器S上。A没有发送任何消息到S上，B这时向S发送了一个请求与A通话的消息。S需要将这个消息转发给A，但是由于A没有向S发送请求消息，S就需要主动向A发送消息。

当然我们会有一些变通的方法，就是让我们客户端周期性的发送刷新的请求，这样可以保证客户端能够在刷新周期内接收到客户端发送的消息。但是这样做会话，如果连接到服务器的客户端数目特别多的话，大量客户端的周期请求会给服务器带来的巨大压力，也浪费的很多网络带宽。

于是一个更好的解决方案就这样出场了，服务器在事件发生时发送消息给客户端，而不需要客户端进行询问。这样客户端将不再周期性地检查服务器；它能够继续其它的工作并处理事件发生后被服务器推送过来的数据。这就是Comet所实现的。

Comet：
一种编程技术，使用它可以在Web Server上向client发送数据而无须来自client的请求。使用此技术可以建立定位于浏览器上的“事件驱动Web应用”。

好了，假如我们的服务器端，或者更明确的说在我们的Servlet中实现Comet的功能，我们需要做那些工作。大家知道Servlet是典型的Request/Response工作模式的产物，一旦服务器端接收到了客户端的请求，Web Container 会分配一个线程调用具体的执行模块。但是我们现在需要服务器主动向客户端发送消息，首先我们想到了我们可以为每个客户端分配一个特殊的请求处理线程，在请求线程处理函数中专门用来处理这种需要服务器端主动推送数据的事件，一旦这些事件发生，请求函数将被调用处理事件并完成向客户端发送数据的工作。但是这样做会带来一个异步Servlet API问题，熟悉Servlet API的朋友会知道，doPost(),doGet(),doPoll()定义的API都是同步的，也就是说这些API参数的Request和Response是不能分开调用的，如果我们想让Web Container支持Comet, 我们的Web Container不能采用thread-per-request的方式进行工作了，而需要采用一个连接一个线程的方式进行工作。每个连接一个线程会耗费大量的系统资源，一旦连接客户端增多，我们的服务器很容易就被托跨了。

好了现在该隆重介绍Continuations
Continuation是一种非常古老的程序结构，关于它的理论分析可谓渊源流长，参见http://library.readscheme.org/page6.html

Continuation怎么和Jetty扯上关系了呢? 其实写过Servlet的朋友应该知道，对于一个Web应用功能模块Servlet，我们只需要实现doPost(),或者doGet()中加上我们的处理逻辑就可以了。Continuation在这里起到什么样的作用呢? 最简单的说，比如，你的程序有两行代码，continuation能保证你的程序在执行了第一行之后return，下次你再进入此程序，如果有个类似于“continuationId”的东东相同，程序就会从第二行代码开始执行。也就是说，程序有了自身状态的管理，有了“记忆”。 哈哈，现在知道了把，现在我们可以通过Continuation把Servlet变成有状态的。这样我们就不需要在一个线程中存放那些与请求上下文相关的信息。这样我们可以把Servlet中相应等待处理线程解放出来，来为我们做更多有意义的事情，这样也就减轻了系统的负担。

这里Jetty中有关Continuation的实现。