Netty EventExecutorGroup打破了管道

Question

情况:我有一个使用Netty 4.0.17.Final的代理应用程序(仅供参考:我已经有版本4.0.13.Final和4.0.9.Final的问题),这是基于Netty示例的代理.

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

我已经进行了单元测试并对我的应用程序进行了几个小时的加载测试

问题: 由于收到的第一个消息需要执行一些阻塞操作,我试图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] ERROR(com.nsn.ucpsimulator.common.UcpDecoder) - 空闲连接(/127.0.0.1:7201).PDU收到:13

2014-02-14 00:39:56.149 [id:0x811bbadf] ERROR(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] ERROR(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] ERROR(com.nsn.ucpsimulator.common.UcpDecoder) - 空闲连接(/127.0.0.1:37944).收到的PDU:500

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

有人知道是什么原因引起的吗？

附加信息:

• 请注意,一切正常,直到我开始使用单独EventExecutorGroup的阻塞处理程序.

• 每次XX客户端阻止时,它们都会以转发给客户端的相同数量的回复进行阻止.

• 我在这里上传了netty代码(它是可运行的,包含带有自述文件的代理,服务器和客户端应用程序):https://github.com/AndrewBourgeois/ucp-proxy/tree/master/src/main/java/be/ demmel /乐趣

• 当代理应用程序被杀死时,服务器端会弹出此错误:

---

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

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