когда умирает канал AMQP/RabbitMQ без соединений?

У меня есть простая тестовая программа RabbitMQ, случайным образом помещающая сообщения в очередь, и другая, читающая их, все с использованием Spring-AMQP. Если потребитель умирает (например, уничтожает процесс, не имея возможности закрыть его соединение или канал), любые сообщения, которые он не подтвердил, остаются неподтвержденными навсегда.

Я видел ряд ссылок (например, этот вопрос), в которых говорится, что канал умирает, когда у него нет соединений, и что оставшиеся неподтвержденные сообщения будут доставлены повторно. Это не то поведение, которое я вижу - вместо этого я получаю растущий список каналов с пометкой IDLE и растущий список подключений, помеченных как работающие, но без активности.

Требуется ли какая-то настройка, чтобы заметить, что соединения мертвы после того, как процесс был убит?

EDIT: я запускал сервер rabbitmq внутри виртуальной машины VirtualBox, которая, по-видимому, неправильно управляет мертвыми входящими соединениями через NAT. Это прекрасно работает с сервером mq, работающим непосредственно на физическом хосте.


java rabbitmq amqp message-queue spring-amqp
person Joe Kearney    schedule 28.11.2011    source источник
comment
К вашему сведению: у меня была аналогичная проблема, когда эксклюзивные очереди не очищались на брокере своевременно после смерти эксклюзивного потребителя. Это предотвратило запуск этих компонентов с детерминированными именами. Это было решено установкой ConnectionFactory.RequestedHeartbeat на небольшое значение (секунды)   -  person drstevens    schedule 10.12.2011

Ответы (2)


arrow_upward
4
arrow_downward

AMQP использует очереди и обмены. Вы публикуете на бирже и привязываете очереди для получения сообщений с бирж (вы можете увидеть краткое объяснение в моем блоге. Когда вы создаете очередь, вы можете настроить ее на автоматическое удаление, а также указать, сколько времени она будет оставаться неиспользованной, прежде чем она будет автоматически удалена. Вот цитата из RabbitMQ quickref:

queue.declare(короткая зарезервированная-1, очередь-имя очереди, бит пассивная, битовая устойчивая, битовая эксклюзивная, автоматическое удаление битов, без ожидания без ожидания, аргументы таблицы) ➔ объявлять-ок

Поддержка: полная очередь Declare, создание при необходимости.

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

RabbitMQ реализует расширения спецификации AMQP, которые позволяют создателю очереди контролировать различные аспекты ее поведения.

Per-Queue Message TTL Это расширение определяет, как долго может существовать сообщение, опубликованное в очереди, прежде чем оно будет отклонено сервером. Время жизни настраивается с помощью аргумента x-message-ttl в параметре arguments этого метода.

Срок действия очереди Очереди можно объявлять с необязательным сроком аренды. Время аренды определяет, как долго очередь может оставаться неиспользованной, прежде чем она будет автоматически удалена сервером. Время аренды указывается в качестве аргумента x-expires в параметре arguments этого метода.

Зеркальные очереди Мы разработали активную/активную высокую доступность для очередей. Это работает, позволяя зеркалировать очереди на других узлах в кластере RabbitMQ. В результате в случае сбоя одного узла кластера очередь может автоматически переключиться на одно из зеркал и продолжить работу без недоступности сервиса. Чтобы создать зеркальную очередь, вы предоставляете аргумент x-ha-policy в параметре arguments этого метода.

person Arnon Rotem-Gal-Oz    schedule 28.11.2011
comment
Я не хочу, чтобы очередь удалялась, я хочу, чтобы она была постоянной. Но я также хочу, чтобы неподтвержденные сообщения (использованные процессами, которые умерли до подтверждения) были доставлены повторно. Удалять нужно мертвые соединения/каналы, а не сообщения. - person Joe Kearney; 29.11.2011
comment
хорошо, теперь я вас понял - вам нужно создать экземпляр ConnectionParameters и установить пульс (setRequestedHeardbeat) на разумное значение (1 промах пульса закроет канал). Затем передайте это конструктору ConnectionFactory. - person Arnon Rotem-Gal-Oz; 30.11.2011
comment
@Arnon Rotem-Gal-Oz, установка RequestedHeartbeat решила мою аналогичную проблему, которая проявлялась в том, что эксклюзивные очереди не очищались своевременно у брокера. Это предотвратило запуск компонентов, которые объявляют монопольные очереди с детерминированными именами. - person drstevens; 10.12.2011
comment
@drstevens прав, это почти та же проблема. Брокер должен знать, что клиенты ушли, чтобы высвободить ресурсы - person Arnon Rotem-Gal-Oz; 10.12.2011

arrow_upward
3
arrow_downward

Ответ закрыть. Оказывается, это не настоящая проблема.

Я запускал сервер rabbitmq внутри виртуальной машины VirtualBox, которая, по-видимому, неправильно управляет мертвыми входящими соединениями через NAT. Это прекрасно работает с сервером mq, работающим непосредственно на физическом хосте.

person Joe Kearney    schedule 22.03.2012