20

我设置了 RabbitMQ 以解析来自外部 API 的大约 20.000 个请求，但几分钟后它一直超时。它确实可以正确解析总共 20.000 个请求中的大约 2000 个。

日志文件说：

=INFO REPORT==== 16-Feb-2016::17:02:50 ===
accepting AMQP connection <0.1648.0> (127.0.0.1:33091 -> 127.0.0.1:5672)

=ERROR REPORT==== 16-Feb-2016::17:03:21 ===
closing AMQP connection <0.1648.0> (127.0.0.1:33091 -> 127.0.0.1:5672):
{writer,send_failed,{error,timeout}}

我已经增加了心跳值，但我无法弄清楚它为什么会超时。配置为：Ubuntu 14.04、NGINX 1.8.1、RabbitMQ 3.6.0

感谢您的时间和投入！

4

2 回答 2

33

我刚刚在python中解决了一个类似的问题。在我的例子中，它是通过减少消费者的预取计数来解决的，这样它的接收缓冲区中排队的消息就会更少。

我的理论是消费者的接收缓冲区已满，然后 RMQ 尝试将一些其他消息写入消费者的套接字，但由于消费者的套接字已满而不能。RMQ 在此套接字上阻塞，最终超时并关闭消费者上的连接。具有较小的预取队列意味着套接字接收缓冲区不会被填满，并且 RMQ 能够写入它试图执行的任何簿记消息，因此不会在其写入时超时，也不会关闭连接。

虽然这只是一个理论，但它似乎在我的测试中成立。

在 Python 中，可以像这样设置预取计数：

subChannel.basicQos(10);

（感谢@shawn-guo 提醒我添加此代码段）

于 2016-03-20T13:09:32.780 回答
13

在@tul 的答案中添加更多内容。

subChannel.basicQos(10);

减少消费者预取计数确实消除了此超时异常。
默认预取计数是无限的。

于 2016-08-18T14:44:53.773 回答