Nettys在OS上的FileDescriptor使用情况如何

Question

在PLC4X项目中，我们使用Netty作为客户端连接到作为服务器的PLC。有时，无论是用户错误还是PLC错误，连接都不会被接受，而是被拒绝。如果我们多次尝试构建连接，我们就会遇到错误消息Too many open files。我试图清理代码中的所有内容，因此我假设没有可能泄漏的文件复制者：

try {
  final NioEventLoopGroup workerGroup = new NioEventLoopGroup();

  Bootstrap bootstrap = new Bootstrap();
  bootstrap.group(workerGroup);
  bootstrap.channel(NioSocketChannel.class);
  bootstrap.option(ChannelOption.SO_KEEPALIVE, true);
  bootstrap.option(ChannelOption.TCP_NODELAY, true);
  // TODO we should use an explicit (configurable?) timeout here
  // bootstrap.option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 1000);
  bootstrap.handler(channelHandler);
  // Start the client.
  final ChannelFuture f = bootstrap.connect(address, port);
  f.addListener(new GenericFutureListener<Future<? super Void>>() {
      @Override public void operationComplete(Future<? super Void> future) throws Exception {
          if (!future.isSuccess()) {
              logger.info("Unable to connect, shutting down worker thread.");
              workerGroup.shutdownGracefully();
          }
      }
  });
  // Wait for sync
  f.sync();
  f.awaitUninterruptibly(); // jf: unsure if we need that
  // Wait till the session is finished initializing.
  return f.channel();
} catch (InterruptedException e) {
  Thread.currentThread().interrupt();
  throw new PlcConnectionException("Error creating channel.", e);
} catch (Exception e) {
  throw new PlcConnectionException("Error creating channel.", e);
}

据我理解，侦听器应该始终关闭组并释放所有使用的描述符。但实际上，当在macOS Catalina上运行它时，我发现大约1%的失败不是由于“拒绝”，而是由于“打开的文件太多”。这是一件ulimit的事情吗，因为Netty (在macOS上)只需要使用很多fd？还是我漏了什么东西？

谢谢你的澄清！

Answer 1

我找到了解决办法，有点像我自己。在最初的实现中有两个问题(甚至可能是3个)，它们实际上与Mac无关：

应该是chained

• workerGroup.shutdownGracefully()的
• 连接和addListener在另一个线程中触发，因此主(被调用)线程已经完成了
• --它没有等待workerGroup真正完成。

这可能导致出现新的组比旧组关闭的速度更快的情况。因此，我将实现更改为

try {
    final NioEventLoopGroup workerGroup = new NioEventLoopGroup();

    Bootstrap bootstrap = new Bootstrap();
    bootstrap.group(workerGroup);
    bootstrap.channel(NioSocketChannel.class);
    bootstrap.option(ChannelOption.SO_KEEPALIVE, true);
    bootstrap.option(ChannelOption.TCP_NODELAY, true);
    // TODO we should use an explicit (configurable?) timeout here
    // bootstrap.option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 1000);
    bootstrap.handler(channelHandler);
    // Start the client.
    logger.trace("Starting connection attempt on tcp layer to {}:{}", address.getHostAddress(), port);
    final ChannelFuture f = bootstrap.connect(address, port);
    // Wait for sync
    try {
        f.sync();
    } catch (Exception e) {
        // Shutdown worker group here and wait for it
        logger.info("Unable to connect, shutting down worker thread.");
        workerGroup.shutdownGracefully().awaitUninterruptibly();
        logger.debug("Worker Group is shutdown successfully.");
        throw new PlcConnectionException("Unable to Connect on TCP Layer to " + address.getHostAddress() + ":" + port, e);
    }
    // Wait till the session is finished initializing.
    return f.channel();
}
catch (Exception e) {
    throw new PlcConnectionException("Error creating channel.", e);
}

上面提到的问题。因此，只有在正确清理完调用之后，调用才会结束。

我的测试现在显示了数量不变的打开文件描述符。