不确定为什么我的服务器在帧解码器中收到“channelInterestChanged”事件

Question

我实现了自己的帧解码器，根据我们的协议解析通过UDP套接字（使用NioDatagramChannelFactory和ConnectionlessBootstrap）接收的字节。 为了跟踪接收消息时服务器中发生的事情，我在解码器的每个回调方法中添加了跟踪日志。

似乎对于服务器接收的几乎每条消息，我们都可以看到事件“channelInterestChanged”在方法channelInterestChanged（）中被接收两次。事件的值首先是0（OP_NONE）然后是1（OP_READ）。

我阅读了有关此内容的文档，但我仍然不确定为什么会收到此类事件。我首先通过它是因为接收缓冲区（或选择器队列）已满，但服务器收到此事件的次数与接收“messageReceived”事件（在调用decode（）方法之前）和所有消息的次数相同/帧按预期正确解码。当消息丢失时，我根本看不到任何事件。在这种情况下，可能是因为数据报套接字的接收缓冲区已满。但即使我增加了这个接收缓冲区，我仍然会看到这些事件并错过消息。

所以，我想知道为什么对于收到的每条消息，服务器还会收到两个“channelInterestChanged”，一个带有OP_NONE值，另一个带有OP_READ值。请注意，在通道管道中，在我的帧解码器之后，还有一个ExecutionHandler和另一个特定于业务的处理程序（它将一条JMS消息发送到ActiveMQ实例）。

对我有任何想法或解释吗？

谢谢。

Answer 1

当从处理程序触发DownStreamChannelStateEvent（例如调用channel.setReadable()，channel.setWriteable()）时，该事件将在NioDatagramWorker中更改频道的nio选择器键的感兴趣选项，稍后会更改{{将使用更改的选项（即UpstreamChannelStateEvent或OP_READ）

触发1}}

你的帧解码器处理程序接收OP_NONE因为，管道中的一些其他处理程序正在改变通道的读取兴趣选项（调用channel.setReadable / setWriteable的目的是，限制读/写以避免拥塞，{应用程序中的{1}}。

如果您的管道中有任何UpstreamChannelStateEvents（监视所使用的通道内存的大小），如果通道收到的消息太快，它可以随时调用OutOfMemoryError来暂停或恢复读取。您可能必须使用最佳maxChannelMemorySize，maxTotalMemorySize配置MATPE实例，或通过将其设置为0来禁用它。