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 unde

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.