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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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