Tomcat 8 JSR 356 WebSocket Threading

Question

I'm using the JSR-356 WebSocket support in Tomcat 8 to drive an application I'm working on. So far, it looks like all messages are handled in a single thread. While I understand the reasoning behind this - and why websockets are implemented this way, is there any way to use an ExecutorService for handling a message that comes in (without creating the ExecutorService in my code)?

This would allow for the scalability of having 1 (or only a few) network selector threads (to support a large number of connected clients), while allowing for standard thread-based processing of an actual message (when a message needs to be processed for a client).

I don't see anything in particular that would allow this to be changed.

Answer 1

The threading model varies depending on which connector you are using. For scalability you want to use NIO (the default) or APR/native (buggy as of 8.0.0-RC3). NIO is really the only choice at the moment. The APR/native issues should be fixed shortly (I was working on that when I saw this question).

NIO uses a selector and a thread pool to handle received messages. When the selector detects that data is available it passes the socket to a thread from the thread pool (via an executor) to process it. That processing may result in data being buffered internally, the application being notified of a partial message, the application being notified of a complete message or a combination of these. Notification to the application is handled by the same thread that processes the incoming data.

If multiple messages are received from multiple clients then multiple threads will be dispatched to handle those messages.

There is no functionality in the JSR 356 API that would allow an application to opt for messages or partial messages to be handled via an ExecutorService one the application has been notified of a new message without the application implementing one. It should be relatively simple for an application that only handles whole messages to implement this. If the applications handles partial messages then it will be a lot harder.

APR/native (once fixed) will behave the same way as NIO. BIO always uses blocking IO (even where the JSR356 API indicates non-blocking) and also requires one thread per connected client rather than one thread per connected client with data to process.