Netty EventExecutorGroup 中断管道答案

【问题标题】：Netty EventExecutorGroup breaks pipelineNetty EventExecutorGroup 中断管道
【发布时间】：2014-02-14 01:03:31
【问题描述】：

情况：我有一个使用 Netty 4.0.17.Final 的代理应用程序（仅供参考：我已经遇到了 4.0.13.Final 和 4.0.9.Final 版本的问题），就是这样基于proxy from the Netty examples。

我的代码与示例之间的主要区别在于，当通道处于活动状态时，我的代码不会连接到后端服务器，而是仅在第一次读取时，因为此读取必须先对输入进行一些检查，然后再连接和将该消息转发到后端服务器。

我已经对我的应用进行了数小时的单元测试和负载测试，它运行良好。

问题： 由于收到的第一条消息需要执行一些阻塞操作，我尝试为执行该操作的那个处理程序使用单独的 EventExecutorGroup（这样 IO 线程就不会被阻塞）：

private static final EventExecutorGroup handlersExecutor = new DefaultEventExecutorGroup(10);
...
pipeline.addLast(handlersExecutor, "authenticationHandler", new FrontendHandler(outboundAddress));

这（= 我所做的唯一更改！）在负载测试期间破坏了应用程序。什么破？ 3500 个客户端连接中的 XXX 向我报告说，这些客户端的 500 条消息中有 YY 没有得到代理的回复（每个请求都应该得到一个响应）。客户端日志摘录：

2014-02-14 00:39:56.146 [id: 0x34cb2c60] 错误 (com.nsn.ucpsimulator.common.UcpDecoder) - 空闲连接 (/127.0.0.1:7201)。收到的 PDU：13

2014-02-14 00:39:56.146 [id: 0xf0955993] 错误 (com.nsn.ucpsimulator.common.UcpDecoder) - 空闲连接（/127.0.0.1:7201）。收到的 PDU：13

2014-02-14 00:39:56.147 [id: 0x9a911fa3] 错误 (com.nsn.ucpsimulator.common.UcpDecoder) - 空闲连接（/127.0.0.1:7201）。收到的 PDU：13

2014-02-14 00:39:56.149 [id: 0x811bbadf] 错误 (com.nsn.ucpsimulator.common.UcpDecoder) - 空闲连接（/127.0.0.1:7201）。收到的 PDU：13

2014-02-14 00:39:56.150 [id: 0x0c4d4c5a] 错误 (com.nsn.ucpsimulator.common.UcpDecoder) - 空闲连接（/127.0.0.1:7201）。收到的 PDU：13

代理应用告诉我收到并转发了 500 条消息，但只收到了 13 条回复并转发回客户端：

2014-02-14 00:39:57.683 [id: 0x39af563b] 错误 (be.demmel.fun.UcpDecoder) - 空闲连接 (/127.0.0.1:49359)。 PDU 收到：500

2014-02-14 00:39:57.683 [id: 0x82056d39] 错误 (be.demmel.fun.FrontendHandler) - 空闲连接 (/127.0.0.1:52004), 关闭它。转发的 PDU：500。成功：500

2014-02-14 00:40:00.717 [id: 0xcdca8f66] 错误 (be.demmel.fun.UcpDecoder) - 空闲连接 (/127.0.0.1:7900)。收到的 PDU：13

2014-02-14 00:40:00.718 [id: 0xcdca8f66] 错误 (be.demmel.fun.BackendHandler) - 空闲连接 (/127.0.0.1:7900)。转发的 PDU：13。成功：13

服务器告诉我一切正常：

2014-02-14 00:40:02.855 [id: 0x4980be2c] 错误 (com.nsn.ucpsimulator.common.UcpDecoder) - 空闲连接（/127.0.0.1:37944）。收到的 PDU：500

2014-02-14 00:40:02.856 [id: 0x4980be2c] 错误 (com.nsn.ucpsimulator.server.TestUcpHandler) - 空闲连接（/127.0.0.1:37944）。发回的 PDU：500

有人知道是什么原因造成的吗？

附加信息：

请注意，在我开始为阻塞处理程序使用单独的 EventExecutorGroup 之前，一切正常。
每次 XX 客户端阻塞时，它们都会阻塞转发给客户端的相同数量的回复。
我已经在这里上传了 netty 代码（它是可运行的，包含代理、服务器和客户端应用程序以及一个 README）：https://github.com/AndrewBourgeois/ucp-proxy/tree/master/src/main/java/be/demmel/fun
代理应用被杀时，服务器端会弹出这个错误：

java.io.IOException: Connection reset by peer
    at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_45]
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) ~[na:1.7.0_45]
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_45]
    at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[na:1.7.0_45]
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379) ~[na:1.7.0_45]
    at io.netty.buffer.UnpooledUnsafeDirectByteBuf.setBytes(UnpooledUnsafeDirectByteBuf.java:401) ~[netty-all-4.0.9.Final.jar:na]
    at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:869) ~[netty-all-4.0.9.Final.jar:na]
    at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:208) ~[netty-all-4.0.9.Final.jar:na]
    at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:87) ~[netty-all-4.0.9.Final.jar:na]
    at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:478) ~[netty-all-4.0.9.Final.jar:na]
    at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:447) ~[netty-all-4.0.9.Final.jar:na]
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:341) ~[netty-all-4.0.9.Final.jar:na]
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) [netty-all-4.0.9.Final.jar:na]
    at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]

我相信这个错误表明我的 Netty 处理程序没有处理服务器回复。

【问题讨论】：

你解决过这个问题吗？我也有类似的问题。

标签： java netty

【解决方案1】：

看看你的 github 项目，你的执行看起来有点像：

--> serve request
  --> authenticate (blocking db call)
    --> forward request
    <-- receive response
<-- serve response

如果没有单独的 EventExecutorGroup，您的所有执行都在 NioEventLoopGroup 内运行，它应该仅用于非阻塞操作。服务的每个请求都会解码，然后立即阻塞 DB 调用，因此您的服务器实际上被限制为 NioEventLoopGroup 中的线程数。

您已经在 ChannelHandler 周围添加了一个 DefaultEventExecutorGroup 来进行身份验证，因此现在服务请求和身份验证部分解耦，因为每个请求都将被解码，然后执行将传递给 DEEG，让 NioEventLoopGroup 解码更多请求。

除了连接到数据库的引导程序配置为使用与初始通道相同的 NioEventLoopGroup：

b.group(inboundChannel.eventLoop())

这意味着您仍在使用阻塞的数据库连接阻塞主要的 netty 工作线程。

我不确定在那之后会发生什么，但也许您提供了一堆请求（实际上是将它们全部排队等待 DEEG 可用）然后将它们超时，因为它们都在等待阻塞数据库调用（因为它与服务器解码的东西争用，所以它的执行能力被饿死了）。

即（假设你有很多并发客户端）

[原创，2线程NioEventLoopGroup，没有EventExecutorGroup]

nio-thread-1: serve-request 1 and authenticate (block)
nio-thread-2: serve-request 2 and authenticate (block)

(db calls completes)

nio-thread-1: forward-request 1 (non-blocking)
nio-thread-2: forward-request 2 (non-blocking)

nio-thread-1: serve-request 3 and authenticate (block)
nio-thread-2: serve-request 4 and authenticate (block)

(db calls complete)

nio-thread-1: forward-request 3 (non-blocking)
nio-thread-2: forward-request 4 (non-blocking)

nio-thread-1: either serve-response 1/2 or serve-request 5 (and block)
nio-thread-2: either serve-response 1/2 or serve-request 6 (and block)

这并不漂亮，但您一次只能处理大约 n*2 个请求，假设服务器请求和服务器响应以相同的紧迫性处理。

[2线程NioEventLoopGroup，2线程DefaultEventExecutorGroup]

nio-thread-1: serve-request 1 and pass to DEEG
nio-thread-2: serve-request 2 and pass to DEEG
nio-thread-1: serve-request 3 and pass to DEEG
nio-thread-2: serve-request 4 and pass to DEEG
nio-thread-1: serve-request 5 and pass to DEEG
nio-thread-2: serve-request 6 and pass to DEEG
nio-thread-1: serve-request 7 and pass to DEEG
nio-thread-2: serve-request 8 and pass to DEEG

def-evt-eg-1: try to authenticate, pass execution back to nio-thread-x
def-evt-eg-2: try to authenticate, pass execution back to nio-thread-x

nio-thread-1: serve-request 9 and pass to DEEG
nio-thread-2: serve-request 10 and pass to DEEG
nio-thread-1: serve-request 11 and pass to DEEG
nio-thread-2: serve-request 12 and pass to DEEG
nio-thread-1: authenticate against DB (block)
nio-thread-2: serve-request 12 and pass to DEEG
nio-thread-2: serve-request 13 and pass to DEEG
nio-thread-2: serve-request 14 and pass to DEEG
nio-thread-2: serve-request 15 and pass to DEEG
nio-thread-2: authenticate against DB (block)

现在您可以处理更多请求，但是您通过服务器进行数据库调用的速率和总延迟将取决于您拥有的并发客户端数、DEEG 线程数 v NioEventLoop 线程数，上下文切换等

您可以通过在运行应用程序时打印出一些基本的线程诊断信息来可视化这一点。我可能完全错了，因为我没有机会运行它并亲自查看，这只是我的猜测。

【讨论】：

虽然您的观点是有效的（阻止 Netty 的 IO 线程很糟糕），但我认为这不是我问题的根源。仅对第一个 PDU 进行身份验证，之后数千个 PDU 不会阻塞。您的第二个示例说明了为什么我要使用 DEEG。我会查找 EventLoop 共享的东西。
嘿安德鲁，你最终找到解决方案了吗？我很想知道问题出在哪里。
@Norman Maurer 将运行我的项目，看看他是否可以重现并理解该问题（请查看我的 cmets 在他的回复中）。检查阻塞问题目前不是我的首要任务（它不是我上传的代码的一部分（并且该代码确实重现了我的问题，排除了您的答案）。

【解决方案2】：

我认为你的问题是你使用创建一个新的 DefaultEventExecutorGroup(10) 添加处理程序的所有内容。您应该只创建一次并传入实例。

【讨论】：

不。我在简化这篇文章的代码时犯了一个错误，仅此而已。我刚刚在我的问题中解决了这个问题。 github上的测试项目有正确的代码。如果我给你客户端和服务器代码（你只需要 mvn exec:java），你会花 2 分钟重现这个吗？
当然...只要给我链接，我会检查
github.com/AndrewBourgeois/ucp-proxy。我添加了一点自述文件。 P.S.：这段代码也经常复制github.com/netty/netty/issues/2086（已修复但尚未发布）；）
我删除了 github 项目中的“UCP”代码，以进一步简化代码。让我知道您是否可以复制它（我确实检查过我仍然可以在没有“UCP”代码的情况下复制它）。谢谢！
@AndrewBourgeois 我试了一下，从客户端日志“be.demmel.fun.StartClient - 成功完成的客户端数：4000”中得到了这个，可能是网络堆栈配置/丢包问题你的机器？