java - Netty EventExecutorGroup 中断管道

Question

情况:我有一个使用 Netty 4.0.17.Final 的代理应用程序(仅供引用:我已经遇到了版本 4.0.13.Final 和 4.0.9.Final 的问题)，那就是基于 proxy from the Netty examples .

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

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

问题:由于收到的第一条消息需要执行一些阻塞操作，因此我尝试为执行此操作的处理程序使用单独的 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] ERROR (com.nsn.ucpsimulator.common.UcpDecoder) - Idle connection (/127.0.0.1:7201). PDUs received: 13

2014-02-14 00:39:56.146 [id: 0xf0955993] ERROR (com.nsn.ucpsimulator.common.UcpDecoder) - Idle connection (/127.0.0.1:7201). PDUs received: 13

2014-02-14 00:39:56.147 [id: 0x9a911fa3] ERROR (com.nsn.ucpsimulator.common.UcpDecoder) - Idle connection (/127.0.0.1:7201). PDUs received: 13

2014-02-14 00:39:56.149 [id: 0x811bbadf] ERROR (com.nsn.ucpsimulator.common.UcpDecoder) - Idle connection (/127.0.0.1:7201). PDUs received: 13

2014-02-14 00:39:56.150 [id: 0x0c4d4c5a] ERROR (com.nsn.ucpsimulator.common.UcpDecoder) - Idle connection (/127.0.0.1:7201). PDUs received: 13

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

2014-02-14 00:39:57.683 [id: 0x39af563b] ERROR (be.demmel.fun.UcpDecoder) - Idle connection (/127.0.0.1:49359). PDUs received: 500

2014-02-14 00:39:57.683 [id: 0x82056d39] ERROR (be.demmel.fun.FrontendHandler) - Idle connection (/127.0.0.1:52004), closing it. PDUs forwarded: 500. Success: 500

2014-02-14 00:40:00.717 [id: 0xcdca8f66] ERROR (be.demmel.fun.UcpDecoder) - Idle connection (/127.0.0.1:7900). PDUs received: 13

2014-02-14 00:40:00.718 [id: 0xcdca8f66] ERROR (be.demmel.fun.BackendHandler) - Idle connection (/127.0.0.1:7900). PDUs forwarded: 13. Success: 13

服务器告诉我一切正常:

2014-02-14 00:40:02.855 [id: 0x4980be2c] ERROR (com.nsn.ucpsimulator.common.UcpDecoder) - Idle connection (/127.0.0.1:37944). PDUs received: 500

2014-02-14 00:40:02.856 [id: 0x4980be2c] ERROR (com.nsn.ucpsimulator.server.TestUcpHandler) - Idle connection (/127.0.0.1:37944). PDUs sent back: 500

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

附加信息:

• 请注意，在我开始为阻塞处理程序使用单独的 EventExecutorGroup 之前，一切正常。

• 每次 XX 个客户端阻止时，它们都会阻止转发给客户端的相同数量的回复。

• 我已经在此处上传了 netty 代码(它是可运行的，包含代理、服务器和客户端应用程序以及自述文件):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 处理程序没有处理服务器回复。

Answer 1

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

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

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

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

除了连接到数据库的 Bootstrap 被配置为使用与初始 channel 相同的 NioEventLoopGroup:

b.group(inboundChannel.eventLoop())

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

我不确定在那之后会发生什么，但也许你服务了一堆请求(有效地将它们全部排队等待 DEEG 可用)然后将它们超时，因为它们都在等待阻塞DB 调用(因为它与服务器解码内容争用而使其执行能力不足)。

即(假设您有大量并发客户端)

[原创，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 线程数，上下文切换等

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