Amazon ec2 在EC2上使用pika BlockingConnection消耗长时间运行的任务

我有一个队列系统，我使用pika的BlockingConnection来使用托管在上的rabbitmq队列。 以下是连接的设置方式：

params = pika.URLParameters(self.queue_url)
self.connection = pika.BlockingConnection(params)
self.channel = self.connection.channel()
self.channel.queue_declare(queue=self.queue_name, durable=True)
self.channel.basic_qos(prefetch_count=1)
# set up subscription on the queue
self.channel.basic_consume(self._on_new_task,
                           queue=self.queue_name,
                           no_ack=False)
self.channel.start_consuming()

def _on_new_task(self, ch, method, properties, body):
    logging.info("Processing new scan")

    """
    Do long running task here
    """

    self.channel.basic_ack(delivery_tag=method.delivery_tag)
    # Program crashes here

处理队列中的任务最多需要15分钟。然而，在大多数情况下，处理任务只需要2-3分钟，然后一切正常。当花费>5分钟时，我从pika获得以下错误：

ERROR - pika.adapters.base_connection - Read empty data, calling disconnect
WARNING - pika.adapters.base_connection - Socket closed when connection was open
WARNING - pika.connection - Disconnected from RabbitMQ at squirrel.rmq.cloudamqp.com:5672 (0): Not specified
CRITICAL - pika.adapters.blocking_connection - Connection close detected

显然，基本确认没有成功处理，因为任务仍然保留在任务队列上，导致无限循环，任务永远不会从队列中释放

我尝试将心跳调整为0、30、600等，但心跳似乎无法与阻塞连接一起工作，因为长时间运行的任务正在阻塞连接以发送心跳（？）

该程序在docker容器中运行。我在AWS ECS2上托管容器时遇到问题，但在我的家用电脑上运行容器时却没有。因此，在我看来，ECS2正在关闭空闲连接（？）。 这一假设得到了以下事实的支持：当运行

 for i in range(1,10):
     self.connection.sleep(60)
     self.connection.process_data_events()

与长时间运行的任务不同，一切都很顺利，可能是因为心跳被发送并保持了连接

---

不知道如何解决这个问题。用SelectConnection取代pika的BlockingConnection有什么意义吗？或者EC2/ECS2中是否有任何配置不会中断空闲连接？

在处理消息时，您需要保持泵送事件。有点棘手，因为皮卡并不完全是线程安全的。我最终编写了自己的amqp库，可以处理诸如背景中的心跳之类的事情。这样你就不用担心他们了。