tomcat - websockets - websocket example java

Tomcat 8 JSR 356 WebSocket Threading

Question

Estoy usando el soporte JSR-356 WebSocket en Tomcat 8 para manejar una aplicación en la que estoy trabajando. Hasta ahora, parece que todos los mensajes se manejan en un solo hilo. Si bien entiendo el razonamiento detrás de esto, y por qué los websockets se implementan de esta manera, ¿hay alguna forma de utilizar un ExecutorService para manejar un mensaje que entra (sin crear el ExecutorService en mi código)?

Esto permitiría la escalabilidad de tener 1 (o solo unos pocos) hilos de selección de red (para admitir una gran cantidad de clientes conectados), mientras que permite el procesamiento estándar de un mensaje real (cuando un mensaje necesita ser procesado para un cliente).

No veo nada en particular que permita cambiar esto.

Answer 1

El modelo de subprocesamiento varía según el conector que esté utilizando. Para la escalabilidad, debe usar NIO (valor predeterminado) o APR / nativo (error a partir de 8.0.0-RC3). NIO es realmente la única opción en este momento. Los problemas APR / nativos deberían arreglarse en breve (estaba trabajando en eso cuando vi esta pregunta).

NIO usa un selector y un grupo de subprocesos para manejar los mensajes recibidos. Cuando el selector detecta que hay datos disponibles, pasa el socket a un hilo del grupo de subprocesos (a través de un ejecutor) para procesarlo. Ese procesamiento puede dar como resultado que los datos se almacenen en un buffer interno, notificándose a la aplicación un mensaje parcial, notificándose a la aplicación un mensaje completo o una combinación de estos. La notificación a la aplicación se maneja con el mismo hilo que procesa los datos entrantes.

Si se reciben múltiples mensajes de múltiples clientes, se enviarán múltiples subprocesos para manejar esos mensajes.

No hay funcionalidad en la API JSR 356 que permita que una aplicación opte por mensajes o mensajes parciales que se manejen a través de un ExecutorService, ya que la aplicación ha sido notificada de un nuevo mensaje sin que la aplicación implemente uno. Debería ser relativamente simple para una aplicación que solo maneja mensajes completos para implementar esto. Si las aplicaciones manejan mensajes parciales, será mucho más difícil.

APR / nativo (una vez arreglado) se comportará de la misma manera que NIO. BIO siempre usa bloqueo IO (incluso cuando la API JSR356 indica que no hay bloqueo) y también requiere un hilo por cliente conectado en lugar de un hilo por cliente conectado con datos para procesar.