Netty EventExecutorGroup打破了管道

时间：2014-02-14 01:03:31

标签： java netty

情况：我有一个使用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客户端阻止时，它们都会以转发给客户端的相同数量的回复进行阻止。

  • 我已经在这里上传了网络代码（它是可运行的，包含带有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处理程序未处理服务器回复。

2 个答案:

答案 0 :(得分：2)

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

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

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

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

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

b.group(inboundChannel.eventLoop())

这意味着您仍然使用阻塞数据库连接阻止主要的网络工作线程。

我不确定在那之后会发生什么，但也许你服务了一堆请求（有效地将它们排队等待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线程数量和NioEventLoop线程数量，上下文切换等。

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

答案 1 :(得分：0)

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

相关问题
最新问题