我已经设置了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
感谢您的时间和投入!
答案 0 :(得分:23)
我刚刚在python中解决了类似的问题。在我的例子中,它通过减少消费者的预取计数来解决,因此它在接收缓冲区中排队的消息更少。
我的理论是消费者的接收缓冲区已满,然后RMQ尝试将其他消息写入消费者的套接字,而不是由于消费者的套接字已满。 RMQ在此套接字上阻塞,最终超时,只关闭消费者的连接。 具有较小的预取队列意味着套接字接收缓冲区不会被填充,并且RMQ能够写入它尝试执行的任何簿记消息,因此不会对其写入超时,也不会关闭连接。
这只是一个理论,但它似乎在我的测试中持有。
在Python中,设置预取计数可以这样完成:
with
(感谢@ shawn-guo提醒我添加此代码段)
答案 1 :(得分:12)
添加更多@ tul的答案。
subChannel.basicQos(10);
减少消费者预取计数确实消除了此超时异常 默认的预取计数是无限制的。