Tomcat 8 JSR 356 WebSocket 线程 [英] Tomcat 8 JSR 356 WebSocket Threading

问题描述

我正在使用 Tomcat 8 中的 JSR-356 WebSocket 支持来驱动我正在处理的应用程序.到目前为止，看起来所有消息都在单个线程中处理.虽然我理解这背后的原因 - 以及为什么以这种方式实现 websocket，但有没有办法使用 ExecutorService 来处理传入的消息(无需在我的代码中创建 ExecutorService)?

这将允许具有 1 个(或仅几个)网络选择器线程(以支持大量连接的客户端)的可扩展性，同时允许对实际消息进行标准的基于线程的处理(当消息需要为客户处理).

我没有看到任何可以改变这一点的特别内容.

解决方案

线程模型因您使用的连接器而异.对于可扩展性，您希望使用 NIO(默认)或 APR/native(8.0.0-RC3 有问题).蔚来确实是目前唯一的选择.APR/本机问题应该很快得到解决(当我看到这个问题时，我正在研究这个问题).

NIO 使用一个选择器和一个线程池来处理接收到的消息.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.该处理可能导致数据被内部缓冲，应用程序被通知部分消息，应用程序被通知完整消息或这些的组合.对应用程序的通知由处理传入数据的同一线程处理.

如果从多个客户端收到多条消息，则将分派多个线程来处理这些消息.

JSR 356 API 中没有任何功能允许应用程序选择通过 ExecutorService 处理消息或部分消息，即应用程序已被通知新消息而应用程序未实现该消息.对于仅处理整个消息的应用程序来说，实现这一点应该相对简单.如果应用程序处理部分消息，那将会困难得多.

APR/native(一旦修复)的行为方式与 NIO 相同.BIO 总是使用阻塞 IO(即使 JSR356 API 指示非阻塞)，并且每个连接的客户端也需要一个线程，而不是每个连接的客户端一个线程来处理数据.

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.

解决方案

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.

这篇关于Tomcat 8 JSR 356 WebSocket 线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！