c++ - 即使建立连接也不会调用 boost asio async_connect 回调

Question

我偶尔会遇到这个问题。我们有一个使用 boost::asio 和 deadline_timer 实现的 http 客户端来处理连接/请求超时。

1. async_connect 被调用。 deadline_timer 以 120 秒超时启动。
2. deadline_timer 回调在 120 秒后被调用并明确关闭连接。
3. async_connect_callback 被调用时带有 error_code boost::system::errc::operation_canceled 并且在这里我还看到计时器已过期。
4. TcpDump 捕获网络流量显示 tcp 连接已成功建立，并在 120 秒后关闭。

问题:

1. 有没有办法调查为什么没有调用 async_connect 回调来表示连接建立成功？
2. io_service 队列是否重载？如果是这样，如何解释 async_connect_callback 因超时而被调用？如果重要的话，该程序还使用 40 个线程的线程池。

Answer 1

如果没有您的代码，就很难说出真正有用的东西。我建议您将代码简化为可暴露问题的最小可行示例。

1. Is there a way to investigate why the async_connect callback was not called to denote successful connection establishment?

您可能会受益于 Handler Tracking .启用后，您可以非常全面地了解哪些操作在何时挂起以及(未)调用哪些完成处理程序。

示例如下:

@asio|1298160085.070638|0*1|signal_set@0x7fff50528f40.async_wait
@asio|1298160085.070888|0*2|socket@0x7fff50528f60.async_accept
@asio|1298160085.070913|0|resolver@0x7fff50528e28.cancel
@asio|1298160118.075438|>2|ec=asio.system:0
@asio|1298160118.075472|2*3|socket@0xb39048.async_receive
@asio|1298160118.075507|2*4|socket@0x7fff50528f60.async_accept
@asio|1298160118.075527|<2|
@asio|1298160118.075540|>3|ec=asio.system:0,bytes_transferred=122
@asio|1298160118.075731|3*5|socket@0xb39048.async_send
@asio|1298160118.075778|<3|
@asio|1298160118.075793|>5|ec=asio.system:0,bytes_transferred=156
@asio|1298160118.075831|5|socket@0xb39048.close
@asio|1298160118.075855|<5|
@asio|1298160122.827317|>1|ec=asio.system:0,signal_number=2
@asio|1298160122.827333|1|socket@0x7fff50528f60.close
@asio|1298160122.827359|<1|
@asio|1298160122.827370|>4|ec=asio.system:125
@asio|1298160122.827378|<4|
@asio|1298160122.827394|0|signal_set@0x7fff50528f40.cancel

请注意，Asio 附带了一个 perl 脚本，可以从中生成 graphviz 图形:

~/custom/boost/libs/asio/tools/handlerviz.pl /tmp/raw.log | dot -Tpng -o q.png

2. Is it possible that io_service queue was overloaded?

仅当您以这种方式编程时。通常的模式是所有发布到 io_service 的任务都应该是非阻塞的和短暂的。如果是这样，您应该能够仅在 1 个线程上多路复用严重的 IO 负载。

If so, what explains the async_connect_callback getting called as a result of the timeout?

当服务对象(在您的例子中是套接字)关闭(或什至被破坏)时，这是设计使然。文档说在这种情况下所有挂起的异步操作都被取消，并且完成处理程序将以 ec=125 (boost::asio::error::operation_abored) 触发，就像你说的那样。

Also the program uses a threadpool of 40 threads, if it matters.

呃。好多啊。为什么是这样？你真的有 40 个逻辑 CPU 内核吗？您使用该服务是否不仅仅是 IO 任务？在后一种情况下，我强烈怀疑问题是您“滥用”了 IO 队列以执行长时间运行或(上帝保佑)阻塞任务，这意味着 IO 任务可能被饿死。

这似乎不太可能，但在链的存在下可能性会增加，特别是如果链参与这样的阻塞操作。在这种情况下，整个线程池在逻辑上就好像对链上的每个操作都有 1 个单线程一样。