Netty多线程在4.1版中损坏？长查询之后无法处理短查询？

Question

我只想设置一个非常普通的服务器：它必须接受连接并进行一些业务计算以返回答案。计算可以是长也可以是短->我需要某种ThreadPoolExecutor来执行这些计算。

在很久以来一直使用的netty 3中，通过在我的BusinessHandler之前在管道中使用ExecutionHandler可以很容易地实现这一点。

但是现在尝试在netty 4中设置相同的内容，我在文档中读到ExecutionHandler不再存在，并且在将我的BusinessHandler添加到通道管道时，我添加了指定EventExecutor的内容。

DefaultEventExecutorGroup applicativeExecutorGroup = new DefaultEventExecutorGroup(10);
...
ch.pipeline().addLast(applicativeExecutorGroup, businessHandler);

它适用于非常基本的情况（仅简短查询），但不适用于以下情况。 原因是DefaultEventExecutorGroup不会选择空闲的工作程序，而是基于轮询的任何工作程序。

• 第一个请求（R1）到来，被分配了T1（DefaultEventExecutorGroup的线程1），将花费很长时间（例如1分钟）。
• 然后接收到其他一些查询Ri（i = 2到10）。它们被分配了Ti，并且也已成功处理。
• 但是当R11出现时，由于在DefaultEventExecutorGroup中实现了循环算法，因此再次为其分配了T1，并且查询在长R1之后排队。结果，它将在一分钟之前不会开始处理，这显然是不可接受的延迟。在具体情况下，客户永远都无法获得答案，因为在我们开始处理之前，他们会等待答案。
• 并且这样继续。每10个查询中的一个查询只会失败，因为在唯一繁忙的线程中，长查询排在长查询之后，而Group的所有其他线程都处于空闲状态。

我的管道是否还有其他可行的配置？例如，是否存在像标准执行器（选择免费工作程序）那样工作的EventExecutor限制。还是仅仅是netty 4.1中的错误？这看起来很奇怪，因为这对于任何服务器来说都是很常见的情况。

感谢您的帮助。

Answer 1

根据您上面的解释，我认为您想使用UnorderedThreadPoolEventExecutor代替DefaultEventExecutorGroup。或者，如果订购很重要NonStickyEventExecutorGroup。