Comet con Tomcat 6, Jetty y Grizzly

Hace unas semanas comentaba que estaba evaluando proyectos comerciales y Open Source para implementar un sistema basado en Comet. Parte de ese trabajo fue evaluar las implementaciones de Tomcat 6 y Jetty. De esa evaluación extraje algunas ideas que paso a resumir por aquí, por si a alguien le hace falta.

Jetty

Jetty se basa en el soporte de continuations (ver Continuation en general), que simplemente (o no tan simplemente) consiste en aparcar el procesado de una request en concreto para poder hacer disponible el Thread que la estaba tratando para otras requests.

La principal característica de la implementación de Jetty es que se sigue construyendo sobre el modelo tradicional de Servlets, con la única diferencia de que existe un API adicional que te permite aparcar una request en concreto. Para eso creas un objeto Continuation sobre la request. También se puede asociar estado con esa Continuation:

protected void doGet(HttpServletRequestt request, 
HttpServletResponse response) ... {
....
Continuation continuation = 
ContinuationSupport.getContinuation(request,this);
continuation.setObject(new CometRateSender());
}

Una vez que has trabajado con la Continuation puedes aparcarla por un rato:

protected void doGet(HttpServletRequestt request, 
HttpServletResponse response) ... {

.... code above ....
continuation.suspend(100).
}

¿Cuál es el truco? Pues bien, resulta que después de llamar a suspend, Jetty lanza una excepción concreta que el motor de Servlets capturará. Una vez capturada, Jetty almacena esa request y pasa a utilizar el Thread liberado para manejar otras peticiones. Cuando ha pasado el timeout, Jetty recupera la request "suspendida" y vuelve a ejecutar el método doGet/doPost de nuevo.

Como veis se trata de una triquiñuela inteligente que no a todos gustará ya que se basa en lanzar excepciones internamente y rellamara a los métodos get y post continuamente lo que te obliga a realizar un proceso un tanto extraño de las peticiones. El caso es que para ser honestos, el rendimiento es bueno. Con una configuración normalita (Sun Fire V240, 2 Cores y Solaris 8), y ejecutando un test bastante exigente (streaming continuo y constante en tiempo real), fue capaz de mantener de 2000 a 3000 conexiones concurrentes (y aquí concurrente significa enviar continuamente datos al cliente, nada de dormir) manteniendo un 80/90% de la CPU ocupada y rondando unos 500Mb de consumo de memoria.

Tomcat 6

Desde el lanzamiento de la versión 6 (ahora la versión estable de este producto) Tomcat soporta también el modelo Comet, aunque de una forma bastante diferente a Jetty.

El modelo de Tomcat no es un maquillaje sobre la especificación de Servlets, sino que han evitado cualquier tipo de integración y han creado un API propia de gestión de eventos. Esto tiene la desventaja de obligarte a programar de un modo diferente pero por otra parte ofrece un mayor control sobre el modelo de comunicación de tu aplicación web.

En Tomcat 6, un Servlet que quiera realizar Comet tiene que implementar una interfaz concreta, CometProcessor. Cuando Tomcat detecta una llamada a un Servlet que implementa esta interfaz, en lugar de llamar a los métodos doGet y doPost llamará al método especial event:

public void event(CometEvent ce) 
throws IOException, ServletException {

HttpServletRequest request = ce.getHttpServletRequest();
HttpServletResponse response = ce.getHttpServletResponse();
....
}

Tomcat define varios tipos de eventos que se pueden tratar dentro de este método. Así tenemos BEGIN, READ o END, por ejemplo, que marcan el ciclo de vida de la aplicación Comet:

public void event(CometEvent ce) 
throws IOException, ServletException {

... code above ...
if (ce.getEventType() == CometEvent.EventType.BEGIN) {
// store the response somewhere

} else if (ce.getEventType() == CometEvent.EventType.ERROR) {
... get response ...
response.getOutputStream().close();
ce.close();
} else if (ce.getEventType() == CometEvent.EventType.READ) {
.. read bytes and handle them ...
}
}

El método READ se puede utilizar para realizar una implementación basada en polling. De otro modo, la idea es cachear los objetos response y periódicamente utilizarlos para enviar las notificaciones. La mala noticia es que todo el modelo de programación multitarea y la sincronización quedan en manos del desarrollador. Añade algo de complejidad pero tampoco es tan complicado.

Tras los tests realizados, los resultados en cuando a clientes soportados son más o menos los mismos que Jetty, aunque en Tomcat llegué a los 4000 usuarios concurrentes, pero no sería justo decir que soporta más ya que con Tomcat dediqué mucho más tiempo. Todo esto a todo trapo, con la CPU a 80/90%. Sin embargo en Tomcat la memoria utilizada es mucho mayor llegando a 1Gb, es decir el doble. Este consumo de memoria se debe a que yo sí que cacheé los objetos response, pero sinceramente era sólo una prueba, y puede que haya mejores formas de hacerlo.

Grizzly

La verdad es que Grizzly no lo he evaluado. Pero lo he incluido aquí simplemente para enlazar un par de artículos (este y este) que he visto en el blog de lasterra y que seguro que a más de a uno le interesan.

¿Por qué no lo he evaluado? Pues porque es un producto demasiado nuevo, muy difícil de meter en bancos (donde Tomcat está muy enraizado), y porque a uno deja de darle mala espina el ver que toda la documentación de un producto se encuentra únicamente en un blog en concreto, el de su autor. Casi podríamos invertarnos un término nuevo: "Single point of documentation". La falta de referencias importantes (salvo Sun) también le echa a uno atrás la verdad. En fin, además es que lees las mailing lists, foros y eso, y no deja de parecerte un proyecto "inflado", por decirlo de algún modo; porque en las presentaciones no dejan de hablar de sus múltiples hazañas, pero después vas a los foros y listas y nada de nada, ni referencias, ni cientos de mensajes a mayores de los del propio autor.

Personalmente encuentro que Tomcat es una apuesta segura. Fácil de vender, sobradamente probado, con muchas empresas que dan soporte, y conocido en todas partes. Jetty me ha parecido mejor, pero la difernecia no es tan grande como para superar el resto de ventajas de Tomcat.