Мы успешно используем Кролика около года.Недавно мы обновились до v2.6.1, потому что мы хотим использовать кластеры с реплицированными очередями сообщений.
Мое тестирование обнаружило удивительное поведение, которое пахнет для меня ошибкой Rabbit.Тест, который обнаруживает это, работает с кластером с двумя узлами.Оба узла работают v2.6.1.Оба узла имеют диск.Оба узла работают в Mac OS, хотя я сомневаюсь, что это уместно.
Я также запускаю Алису на узле, который выполняет тест.Тест использует его, чтобы программно выполнить stop_app на одном из узлов, потому что тест пытается проверить, что в случае сбоя мастера кластера и повышения уровня ведомого на его место, мы не теряем сообщения.
Итак, тест имеет небольшой пул потоков, в котором периодически задаются задачи: 1) публиковать сообщения и 2) переключать состояние главного узла Rabbit (остановлен, если запущен; запущен, если остановлен).Другие потоки потребляют сообщения из очередей.
Я использую подтверждения издателя, а также подтверждаю сообщения получателей (используя autoAck = false для channel.basicConsume ()).
Когда главный узел остановлен, я вижу, как производители и потребители перехватывают исключение ShutdownSignalException.Они справляются с этим, пытаясь переподключиться к кластеру.Это отлично работает.При повторном подключении они продолжают свою деятельность.
Иногда я вижу, что потребитель успешно получил сообщение от брокера и вызывает channel.basicAck (), когда он получает исключение ShutdownSignalException.
Позже, когда потребитель повторно подключился, он снова выводит то же сообщение.(Тела сообщения помечены UUID, так что я знаю, что это то же самое.) На этот раз, когда потребитель пытается выполнить BasicAck () сообщение, он снова получает исключение ShutdownSignalException, но в этом есть следующий текст: "reply-text = PRECONDITION_FAILED - неизвестный тег доставки 7 ".
Фактически, это тот же тег доставки, который был предложен потребителю брокером до того, как мастер отключился, и потребитель повторно подключился.
Поиск в Google предполагает, что это событие означает, что потребитель пытается подтвердить одно и то же сообщение более одного раза.
Но как это может быть?Если первое подтверждение прошло успешно, то сообщение должно было быть удалено из очередей посредника, и потребитель не должен снова видеть то же сообщение.
Тем не менее, если первое подтверждение не удалось, то потребитель не долженне пытайтесь повторно подтвердить сообщение.
Кто-нибудь видел это раньше?Это пахнет ошибкой в реплицированных очередях Rabbit для меня, но я все еще новичок в Rabbit, и поэтому готов поверить, что здесь есть тонкость в потреблении от кластерного брокера, которого я еще не получил!
Спасибо, --Steve