1 实验了简单的comet例子，基于nio connector。
tomcat的comet突破了传统的web请求处理流程，使用长连接，把客户端和服务端的交互抽象为一个连接，多次事件处理过程。
2 放翁博客
http://so.csdn.net/search?q=blog%3Acenwenchu79+comet&t=blog
http://blog.csdn.net/cenwenchu79/article/details/5505310
放翁web请求异步化处理的核心在于分离容器线程池和业务线程池，隔离不同的业务处理，防止服务质量差的业务影响了系统的稳定性。同时异步化处理引入了事件驱动机制。整个过程还是比传统的模式复杂很多。
3 tomcat nio connector是典型的反应器模式实现，基于java nio的特性实现。
在这个connector里面同样有acceptor，和jio类似，都是单线程无限循环接收用户连接。他们的不同点在于，nioconnector还多了一个poller（org.apache.tomcat.util.net.NioEndpoint.Poller），也就是反应器，基于selector实现，单线程轮询io就绪读写事件，事件就绪时，封装请求任务派发到线程池中（org.apache.tomcat.util.net.NioEndpoint.SocketProcessor---》org.apache.coyote.AbstractProtocol.AbstractConnectionHandler.process(SocketWrapper<S>, SocketStatus)-----》org.apache.coyote.http11.AbstractHttp11Processor.process(SocketWrapper<S>)————》org.apache.coyote.Adapter.service(Request, Response)）。而jio connector则是acceptor接收到连接后，马上封装请求派发到线程池中。进入线程池后的处理逻辑，基本雷同。
在一般的场景下面，web请求一旦连接创建，数据马上会过来，所以nio的优势并不大。
关于servlet容器的阻塞io和非阻塞io的区别，此文中有类似的论述http://www.ibm.com/developerworks/cn/java/j-lo-jetty/：
“这里需要注意的地方时，很多人认为监听 SelectionKey.OP_ACCEPT 事件就已经是非阻塞方式了，其实 Jetty 仍然是用一个线程来监听客户端的连接请求，当接受到请求后，把这个请求再注册到 Selector 上，然后才是非阻塞方式执行。这个地方还有一个容易引起误解的地方是：认为 Jetty 以 NIO 方式工作只会有一个线程来处理所有的请求，甚至会认为不同用户会在服务端共享一个线程从而会导致基于 ThreadLocal 的程序会出现问题，其实从 Jetty 的源码中能够发现，真正共享一个线程的处理只是在监听不同连接的数据传送事件上，比如有多个连接已经建立，传统方式是当没有数据传输时，线程是阻塞的也就是一直在等待下一个数据的到来，而 NIO 的处理方式是只有一个线程在等待所有连接的数据的到来，而当某个连接数据到来时 Jetty 会把它分配给这个连接对应的处理线程去处理，所以不同连接的处理线程仍然是独立的。”
也可参考http://blog.csdn.net/lxlzhn/article/details/7599536
nio的使用场景
http://www.oschina.net/question/53294_3870
http://www.iteye.com/problems/13017
http://my.oschina.net/jsan/blog/49697
nio connector较适用于长连接场景，例如comet是基于nio的。
或者是当针对每个连接，服务端都会有大量的线程阻塞在read上面的通信场景都适合，这样就可以充分发挥多路复用的功能