Как установить обнаружение тайм-аута на сервере RabbitMQ?

Я не вижу amqp_consumer.py или amqp_producer.py в архиве, поэтому воспроизвести ошибку сложно.

RabbitMQ завершает работу подключений, выпуская свои неподтвержденные сообщения для повторной доставки другим клиентам, когда операционная система сообщает, что сокет закрыт. У вас очень странные симптомы: даже kill -9 должен привести к правильной очистке TCP-сокета.

Некоторые люди заметили проблемы с сокетами, живущими дольше, чем они должны, при работе с брандмауэр или устройство NAT между клиентами AMQP и сервером. Может ли это быть проблемой или вы все запускаете на локальном хосте? Кроме того, в какой операционной системе используются различные компоненты системы?

ETA: Из вашего комментария ниже, Я предполагаю, что пока вы запускаете сервер в Linux, вы можете запускать клиенты в Windows. Если это так, то, возможно, драйвер TCP Windows неправильно закрывает сокеты, что отличается от поведения kill-9 в Unix. (В Unix ядро ​​правильно закроет TCP-соединения для любого убитого процесса.)

Если это так, то плохая новость заключается в том, что RabbitMQ может освобождать ресурсы только тогда, когда сокет закрыт, поэтому если клиентская операционная система этого не делает, она ничего не может сделать. Это то же самое, что и почти любой другой сервис на основе TCP.

Хорошая новость , однако, заключается в том, что AMQP поддерживает опцию «пульса» именно для этих случаев, когда сетевая структура ненадежна. . Вы можете попробовать включить сердцебиение. Когда они' при включении, если сервер не получает трафик в течение настраиваемого интервала, он решает, что соединение должно быть разорвано.

Плохая новость , однако, заключается в том, что я не думаю, что py- amqplib в настоящий момент поддерживает сердцебиение. Но стоит попробовать!

RabbitMQ не имеет тайм-аута на подтверждение от клиента, что сообщение было обработано: см. этот пост (может быть интересна вся ветка). Некоторые важные моменты из сообщения:

Модель AMQP ack для подписок и «тянуть» идентичны. В обоих случаях сообщение хранится на сервер, но недоступен для других потребителей, пока он не был ack'ed (и удаляется), nack'ed (с basic.reject; хотя RabbitMQ не реализует это) или канал / соединение закрыто (при котором точка сообщение становится доступным другим потребителям).

и (выделено мной)

Нет тайм-аута на ожидание acks. Обычно это не проблема поскольку распространенные случаи пропавшего без вести ack - сбой сети или клиента - приведет к получению соединения упал (и таким образом запускает поведение, описанное выше). Все еще, тайм-аут может быть полезен, скажем, иметь дело с живым, но не отвечающим потребители . Это появилось в обсуждение раньше. Есть ли конкретный вы имеете в виду, что требует такой функциональности?

Проблема вполне может возникать, потому что в модели клиентского запроса серверу сложнее обнаружить разорванное соединение (в отличие от живого, но не отвечающего потребителя), особенно потому, что сервер кажется счастливым ждать вечно для подтверждения.

Обновление: В Linux вы можете подключить обработчики сигналов для SIGTERM и / или SIGKILL и / или SIGINT и, надеюсь, закрыть соединение упорядоченным образом от клиента. В Windows я считаю, что закрытие из диспетчера задач вызывает Win32 TerminateProcess API, о котором MSDN сообщает:

Если процесс завершается TerminateProcess , все потоки процесс прекращается немедленно без возможности запустить дополнительный код. Это означает, что поток не выполнить код в обработчике завершения блоки. Кроме того, нет прикрепленных DLL уведомляются о том, что процесс отсоединение.

Это означает, что может быть трудно поймать завершение и закрыть упорядоченным образом.

Возможно, стоит продолжить изучение списка RabbitMQ с вашим собственным вариантом использования для тайм-аута подтверждения.

Пожалуйста, предоставьте еще несколько деталей относительно заявленных вами компонентов. Обычно (и независимо от реализации клиента) очередь со свойствами

• эксклюзив и
• автоудаление

должна удаляться, как только разрывается соединение между декларирующим клиентом и брокером. Однако это не поможет вам с общими очередями. Пожалуйста, подробно опишите, что именно вы пытаетесь моделировать.

Обычно (и независимо от реализации клиента) очередь со свойствами

• эксклюзив и
• автоудаление

должна удаляться, как только разрывается соединение между декларирующим клиентом и брокером. Однако это не поможет вам с общими очередями. Пожалуйста, подробно опишите, что именно вы пытаетесь моделировать.

Обычно (и независимо от реализации клиента) очередь со свойствами

• эксклюзив и
• автоудаление

должна удаляться, как только разрывается соединение между декларирующим клиентом и брокером. Однако это не поможет вам с общими очередями. Пожалуйста, подробно опишите, что именно вы пытаетесь моделировать.