Блог
RabbitMQ: Рукопожатие прекращено сервером (ДОСТУП-ОТКАЗАНО)
- Post author: admin
- Запись опубликована: 26 января, 2022
- Post category: Вопросы по программированию
#javascript #kubernetes #rabbitmq
Вопрос:
Я пытаюсь отправлять сообщения RabbitMQ со своей хост — машины на экземпляр Minikube с развернутым кластером RabbitMQ.
При запуске моего сценария отправки я получаю эту ошибку:
Handshake terminated by server: 403 (ACCESS-REFUSED) with message «ACCESS_REFUSED — Login was refused using authentication mechanism PLAIN. For details see the broker logfile.
В файлах журналов брокера я вижу эту строку:
Error on AMQP connection (172.17.0.1:40157 -> 172.17.0.8:5672, state: starting): PLAIN login refused: user ‘rabbitmq-cluster-default-user’ — invalid credentials
Я уверен, что у меня есть правильные учетные данные, так как я получил их непосредственно из модуля RabbitMQ, следуя официальной документации (ссылка).
Error establishing a database connection – исправляем ошибку соединения с базой данных
Мой сценарий отправки приведен ниже:
Я знаю, что код работает, так как я запустил точно такой же сценарий для своей настройки локального хоста, и он сработал. Единственное, что я изменил, — это URL-адрес (для сервиса Minikube RabbitMQ).
Я видел несколько других сообщений, содержащих аналогичную проблему, но большинство решений связано с включением правильных учетных данных в URI, что я и сделал.
Есть еще какие-нибудь идеи?
Ответ №1:
Вы можете использовать переадресацию порта службы RabbitMQ на свой локальный компьютер и использовать логин пользовательского интерфейса и проверить пароль с помощью пользовательского интерфейса, предоставленного самим RabbitMQ.
kubectl port-forward svc/rabbitmq UI-PORT:UI-PORT (must be 15672)
затем из браузера
localhost:15762
должно быть достаточно
Для получения разрешения вы можете проверить, можете ли вы войти в систему из самого контейнера. Если вход в систему из контейнера завершится неудачно, вы также можете проверить файл yaml или диаграмму управления, которую вы используете, на предмет методов входа и учетных данных. Обычный вход в систему может быть отключен.
Другая ситуация может быть связана с распределением. При развертывании RabbitMQ я стараюсь использовать диаграммы bitnami. Я могу их предложить.
Если все это не сработает, вы можете использовать другой способ. Вы можете попытаться создать другого пользователя с правами администратора для подключения к RabbitMQ, а затем продолжить его использование.
Для получения дополнительной информации вы можете публиковать журналы контейнеров/модулей, чтобы мы могли их видеть. Хороший день.
Комментарии:
Вам также может понравиться
Почему для проверки роли требуется запрос между разделами?
19 августа, 2022
Как записать порядок пар ключ-значение в словаре?
28 августа, 2022
Написание скрипта для сжатия всех изображений размером менее 500 кб в скрипте Rails
13 января, 2022
Как исправить ошибку: java.net.connectexception connection timed out no further information
- О нас
- Онлайн игры
- Конвертеры
- Base64 конвертер онлайн
- Оформление кода JavaScript CSS HTML Онлайн
- URL Encoder (кодировщик) / Decoder (декодировщик) онлайн
- Конвертер регистров
- Рассчитать количество дней между датами
- Генератор ключей и паролей
- Генератор QR кодов
- Преобразование времени
- Преобразование микросекунд в секунды
- Преобразование микросекунд в миллисекунды
- Преобразование миллисекунд в микросекунды
- Преобразование миллисекунд в секунды
- Преобразование миллисекунд в минуты
- Преобразование миллисекунд в часы
- Преобразователь миллисекунд в дату
- Преобразование секунд в миллисекунды
- Преобразование секунд в минуты
- Преобразование секунд в часы
- Преобразование секунд в дни
- Преобразование минут во время
- Преобразование минут в миллисекунды
- Преобразование минут в секунды
- Преобразование минут в часы
- Преобразование часов в миллисекунды
- Преобразование часов в секунды
- Преобразование часов в минуты
- Преобразование часов в дни
- Преобразование дней в часы
- Преобразование из часы в недели
- Конвертация из недели в часы
- Через несколько часов калькулятор
- Преобразование времени AM/PM в 24-часовое
- Преобразование Военного Времени
- Время до десятичного калькулятора
- Безопасность
- Финансы
- Энциклопедия
Источник: programbox.ru
Ошибки AMQP в Служебной шине Azure
В этой статье приведены некоторые ошибки, которые могут возникнуть при использовании AMQP с Служебной шиной Azure. Все это стандартное поведение службы. Вы можете избежать их, сделав вызов отправки и получения для соединения или связи, чтобы автоматически воссоздать соединение или связь.
Связь закрыта
Вы увидите следующую ошибку, если соединение и связь AMQP активны, но в течение 10 минут нет вызовов (например, для отправки или получения) с помощью этой связи. Это значит, что связь закрыта. Соединение все еще открыто.
amqp:link:detach-forced:The link ‘G2:7223832:user.tenant0.cud_00000000000-0000-0000-0000-00000000000000’ is force detached by the broker due to errors occurred in publisher(link164614). Detach origin: AmqpMessagePublisher.IdleTimerExpired: Idle timeout: 00:10:00. TrackingId:00000000000000000000000000000000000000_G2_B3, SystemTracker:mynamespace:Topic:MyTopic, Timestamp:2/16/2018 11:10:40 PM
Соединение закрыто
При подключении к AMQP отображается следующая ошибка, когда все связи в соединении закрыты из-за отсутствия активности (простой), а новая связь не была создана в течение 5 минут.
Error
Канал не создан
Эта ошибка возникает при создании нового соединения AMQP, если канал не создается в течение 1 минуты после создания соединения AMQP.
Error
Дальнейшие действия
Сведения о служебной шине и AMQP см. по следующим ссылкам.
- Протокол AMQP служебной шины — обзор
- Руководство по использованию протокола AMQP 1.0
- Протокол AMQP служебной шины для Windows Server
Источник: learn.microsoft.com
Не могу установить соединение по AMQP между двумя контейнерами, в чем может быть дело?
Текущее состояние:
Все контейнеры объединены в одну сеть:
Пинги проходят:
Но тем не менее не могу подключиться:
Продолжение лога:
С этим конфигом:
При том что через браузер зашел без проблем:
Подскажите пожалуйста, почему не могу подключиться через воркер?
- Вопрос задан более года назад
- 571 просмотр
2 комментария
Средний 2 комментария
Источник: qna.habr.com
Обработка ошибок с помощью Spring AMQP
Узнайте о различных способах обработки ошибок с помощью Spring AMQP с помощью RabbitMQ.
1. введение
Асинхронный обмен сообщениями-это тип слабо связанной распределенной коммуникации, который становится все более популярным для реализации архитектуры, управляемой событиями . К счастью, Spring Framework предоставляет проект Spring AMQP, позволяющий нам создавать решения для обмена сообщениями на основе AMQP.
С другой стороны, работа с ошибками в таких средах может быть нетривиальной задачей . Поэтому в этом уроке мы рассмотрим различные стратегии обработки ошибок.
2. Настройка среды
Для этого урока мы будем использовать RabbitMQ , который реализует стандарт AMQP. Кроме того, Spring AMQP предоставляет модуль spring-rabbit , который делает интеграцию очень простой.
Давайте запустим RabbitMQ как автономный сервер. Мы запустим его в контейнере Docker, выполнив следующую команду:
docker run -d -p 5672:5672 -p 15672:15672 —name my-rabbit rabbitmq:3-management
Для получения подробной конфигурации и настройки зависимостей проекта, пожалуйста, обратитесь к нашей статье Spring AMQP .
3. Сценарий Отказа
Обычно существует больше типов ошибок, которые могут возникнуть в системах обмена сообщениями по сравнению с монолитными или однопакетными приложениями из-за их распределенной природы.
Мы можем указать на некоторые типы исключений:
- Сеть- или Связанные с вводом-выводом/| – общие сбои сетевых соединений и операций ввода-вывода Протокол-
- или связанные с инфраструктурой -ошибки, которые обычно представляют собой неправильную конфигурацию инфраструктуры обмена сообщениями Связанные с брокером
- -сбои, предупреждающие о неправильной конфигурации между клиентами и брокером AMQP. Например, достижение определенных пределов или порога, аутентификация или недопустимая конфигурация политик Application-
- и message-related – исключения, которые обычно указывают на нарушение некоторых бизнес-или прикладных правил
Конечно, этот список отказов не является исчерпывающим, но содержит наиболее распространенные типы ошибок.
Следует отметить, что Spring AMQP обрабатывает связанные с подключением и низкоуровневые проблемы из коробки, например, применяя политики retry или requeue . Кроме того, большинство отказов и неисправностей преобразуются в AmqpException или один из его подклассов.
В следующих разделах мы в основном сосредоточимся на специфичных для приложений и высокоуровневых ошибках, а затем рассмотрим глобальные стратегии обработки ошибок.
4. Настройка проекта
Теперь давайте определим простую конфигурацию очереди и обмена для начала:
Далее, давайте создадим простого производителя:
public void sendMessage()
И, наконец, потребитель, который бросает исключение:
По умолчанию все неудачные сообщения будут немедленно запрашиваться в начале целевой очереди снова и снова.
Давайте запустим наш пример приложения, выполнив следующую команду Maven:
mvn spring-boot:run -Dstart-class=com.baeldung.springamqp.errorhandling.ErrorHandlingApp
Теперь мы должны увидеть аналогичный результирующий результат:
WARN 22260 — [ntContainer#0-1] s.a.r.l.ConditionalRejectingErrorHandler : Execution of Rabbit message listener failed. Caused by: com.baeldung.springamqp.errorhandling.errorhandler.BusinessException: null
Следовательно, по умолчанию мы будем видеть бесконечное количество таких сообщений в выходных данных.
Чтобы изменить это поведение у нас есть два варианта:
- Установите параметр defaultrequeuerejected в значение false на стороне слушателя – spring.rabbitmq.listener.simple.default-requeue-rejected=false
- Throw an AmqpRejectAndDontRequeueException – t his может быть полезен для сообщений, которые не будут иметь смысла в будущем, поэтому их можно отбросить.
Теперь давайте узнаем, как обрабатывать неудачные сообщения более разумным способом.
5. Очередь Мертвых писем
Очередь мертвых писем (DLQ) – это очередь, содержащая недоставленные или неудачные сообщения . DLQ позволяет нам обрабатывать неисправные или плохие сообщения, отслеживать шаблоны сбоев и восстанавливаться после исключений в системе.
Что еще более важно, это помогает предотвратить бесконечные циклы в очередях, которые постоянно обрабатывают плохие сообщения и снижают производительность системы.
Всего существует два основных понятия: Обмен мертвыми письмами (DLX) и сама очередь мертвых писем (DLQ). На самом деле, DLX-это обычный обмен, который мы можем определить как один из распространенных типов : direct , topic или fanout .
Очень важно понимать, что продюсер ничего не знает об очередях. Он знает только об обменах, и все произведенные сообщения маршрутизируются в соответствии с конфигурацией обмена и ключом маршрутизации сообщений .
Теперь давайте посмотрим, как обрабатывать исключения, применяя подход очереди мертвых писем.
5.1. Базовая конфигурация
Чтобы настроить DLQ, нам нужно указать дополнительные аргументы при определении нашей очереди:
В приведенном выше примере мы использовали два дополнительных аргумента: x-dead-letter-exchange и x-dead-letter-routing-key . Пустое строковое значение для параметра x-dead-letter-exchange указывает брокеру использовать обмен по умолчанию .
Второй аргумент столь же важен, как и установка ключей маршрутизации для простых сообщений. Эта опция изменяет начальный ключ маршрутизации сообщения для дальнейшей маршрутизации по DLX.
5.2. Неудачная Маршрутизация Сообщений
Поэтому, когда сообщение не доставляется, оно направляется на обмен мертвыми письмами. Но, как мы уже отмечали, DLX-это нормальный обмен. Поэтому, если ключ маршрутизации неудачного сообщения не совпадает с обменом, он не будет доставлен в DLQ.
Exchange: (AMQP default) Routing Key: baeldung-messages-queue.dlq
Таким образом, если мы опустим аргумент x-dead-letter-routing-key в нашем примере, неудачное сообщение застрянет в бесконечном цикле повторных попыток.
Кроме того, исходная метаинформация сообщения доступна в x-death heaven:
x-death: count: 1 exchange: baeldung-messages-exchange queue: baeldung-messages-queue reason: rejected routing-keys: baeldung-messages-queue time: 1571232954
То приведенная выше информация доступна в консоли управления RabbitMQ обычно работает локально на порту 15672.
Помимо этой конфигурации, если мы используем Spring Cloud Stream , мы можем даже упростить процесс настройки, используя свойства конфигурации republishToDlq и autoBindDlq .
5.3. Обмен Мертвыми письмами
В предыдущем разделе мы видели, что ключ маршрутизации изменяется, когда сообщение направляется на обмен мертвыми буквами. Но такое поведение не всегда желательно. Мы можем изменить его, настроив DLX самостоятельно и определив его с помощью типа fanout :
На этот раз мы определили пользовательский обмен типа fan out , поэтому сообщения будут отправляться во все ограниченные очереди . Кроме того, мы установили значение аргумента x-dead-letter-exchange для имени нашего DLX. В то же время мы удалили аргумент x-dead-letter-routing-key .
Теперь, если мы запустим наш пример, неудачное сообщение должно быть доставлено в DLQ, но без изменения начального ключа маршрутизации:
Exchange: baeldung-messages-queue.dlx Routing Key: baeldung-messages-queue
5.4. Обработка Сообщений Очереди Мертвых Писем
Конечно, причина, по которой мы переместили их в очередь мертвых писем, заключается в том, что они могут быть переработаны в другое время.
Давайте определим слушателя для очереди мертвых писем:
Если мы запустим наш пример кода сейчас, то увидим вывод журнала:
WARN 11752 — [ntContainer#0-1] s.a.r.l.ConditionalRejectingErrorHandler : Execution of Rabbit message listener failed. INFO 11752 — [ntContainer#1-1] c.b.s.e.consumer.SimpleDLQAmqpContainer : Received failed message:
Мы получили неудачное сообщение, но что нам делать дальше? Ответ зависит от конкретных системных требований, вида исключения или типа сообщения.
Например, мы можем просто запросить сообщение в исходное место назначения:
Но такая логика исключений не отличается от политики повторных попыток по умолчанию:
INFO 23476 — [ntContainer#0-1] c.b.s.e.c.RoutingDLQAmqpContainer : Received message: WARN 23476 — [ntContainer#0-1] s.a.r.l.ConditionalRejectingErrorHandler : Execution of Rabbit message listener failed. INFO 23476 — [ntContainer#1-1] c.b.s.e.c.RoutingDLQAmqpContainer : Received failed message, requeueing:
Общая стратегия может потребовать повторной обработки сообщения в течение n раз, а затем отклонить его. Давайте реализуем эту стратегию, используя заголовки сообщений:
public void processFailedMessagesRetryHeaders(Message failedMessage) < Integer retriesCnt = (Integer) failedMessage.getMessageProperties() .getHeaders().get(HEADER_X_RETRIES_COUNT); if (retriesCnt == null) retriesCnt = 1; if (retriesCnt >MAX_RETRIES_COUNT) < log.info(«Discarding message»); return; >log.info(«Retrying message for the <> time», retriesCnt); failedMessage.getMessageProperties() .getHeaders().put(HEADER_X_RETRIES_COUNT, ++retriesCnt); rabbitTemplate.send(EXCHANGE_MESSAGES, failedMessage.getMessageProperties().getReceivedRoutingKey(), failedMessage); >
Сначала мы получаем значение заголовка x-retries-count , затем сравниваем это значение с максимально допустимым значением. Впоследствии, если счетчик достигнет предельного числа попыток, сообщение будет отброшено:
WARN 1224 — [ntContainer#0-1] s.a.r.l.ConditionalRejectingErrorHandler : Execution of Rabbit message listener failed. INFO 1224 — [ntContainer#1-1] c.b.s.e.consumer.DLQCustomAmqpContainer : Retrying message for the 1 time WARN 1224 — [ntContainer#0-1] s.a.r.l.ConditionalRejectingErrorHandler : Execution of Rabbit message listener failed. INFO 1224 — [ntContainer#1-1] c.b.s.e.consumer.DLQCustomAmqpContainer : Retrying message for the 2 time WARN 1224 — [ntContainer#0-1] s.a.r.l.ConditionalRejectingErrorHandler : Execution of Rabbit message listener failed. INFO 1224 — [ntContainer#1-1] c.b.s.e.consumer.DLQCustomAmqpContainer : Discarding message
Мы должны добавить, что мы также можем использовать заголовок x-message-ttl , чтобы установить время, после которого сообщение должно быть отброшено. Это может быть полезно для предотвращения бесконечного роста очередей.
5.5. Очередь на Парковку
С другой стороны, рассмотрим ситуацию, когда мы не можем просто отбросить сообщение, например, это может быть транзакция в банковской сфере. Кроме того, иногда сообщение может потребовать ручной обработки или нам просто нужно записать сообщения, которые потерпели неудачу более n раз.
Для подобных ситуаций существует понятие очереди на парковку . Мы можем переслать все сообщения из DLQ, которые вышли из строя более разрешенного количества раз, в очередь парковки для дальнейшей обработки .
Давайте теперь воплотим эту идею:
Во – вторых, давайте реорганизуем логику прослушивателя, чтобы отправить сообщение в очередь парковки:
В конце концов, нам также нужно обрабатывать сообщения, поступающие в очередь парковки:
Теперь мы можем сохранить неудачное сообщение в базе данных или, возможно, отправить уведомление по электронной почте.
Давайте проверим эту логику, запустив наше приложение:
WARN 14768 — [ntContainer#0-1] s.a.r.l.ConditionalRejectingErrorHandler : Execution of Rabbit message listener failed. INFO 14768 — [ntContainer#1-1] c.b.s.e.c.ParkingLotDLQAmqpContainer : Retrying message for the 1 time WARN 14768 — [ntContainer#0-1] s.a.r.l.ConditionalRejectingErrorHandler : Execution of Rabbit message listener failed. INFO 14768 — [ntContainer#1-1] c.b.s.e.c.ParkingLotDLQAmqpContainer : Retrying message for the 2 time WARN 14768 — [ntContainer#0-1] s.a.r.l.ConditionalRejectingErrorHandler : Execution of Rabbit message listener failed. INFO 14768 — [ntContainer#1-1] c.b.s.e.c.ParkingLotDLQAmqpContainer : Sending message to the parking lot queue INFO 14768 — [ntContainer#2-1] c.b.s.e.c.ParkingLotDLQAmqpContainer : Received message in parking lot queue
Как видно из выходных данных, после нескольких неудачных попыток сообщение было отправлено в очередь парковки.
6. Пользовательская Обработка Ошибок
В предыдущем разделе мы видели, как обрабатывать сбои с помощью выделенных очередей и обменов. Однако иногда нам может потребоваться отловить все ошибки, например, для регистрации или сохранения их в базе данных.
6.1. Глобальный обработчик ошибок
До сих пор мы использовали по умолчанию SimpleRabbitListenerContainerFactory и эта фабрика по умолчанию использует ConditionalRejectingErrorHandler . Этот обработчик ловит различные исключения и преобразует их в одно из исключений в иерархии AmqpException .
Важно отметить, что если нам нужно обрабатывать ошибки подключения, то нам нужно реализовать интерфейс ApplicationListener .
Проще говоря, Условное отклонение ErrorHandler решает, отклонять ли конкретное сообщение или нет. Когда сообщение, вызвавшее исключение, отклоняется, оно не запрашивается.
Давайте определим пользовательский Обработчик ошибок , который будет просто запрашивать только Бизнес-исключение s:
Кроме того, поскольку мы выбрасываем исключение внутри нашего метода listener, оно оборачивается в ListenerExecutionFailedException . Итак, нам нужно вызвать метод getCause , чтобы получить исходное исключение.
6.2. Стратегия Фатальных Исключений
Под капотом этот обработчик использует стратегию Fatal Exception , чтобы проверить, следует ли считать исключение фатальным. Если это так, то неудачное сообщение будет отклонено.
По умолчанию эти исключения фатальны:
- MessageConversionException
- MessageConversionException
- MethodArgumentNotValidException
- Метод Аргумент TypeMismatchException
- NoSuchMethodException
- ClassCastException
Вместо реализации интерфейса Ierrorhandler мы можем просто предоставить нашу стратегию Фатальных исключений :
Наконец, нам нужно передать нашу пользовательскую стратегию конструктору Conditional Rejecting ErrorHandler :
7. Заключение
В этом уроке мы обсудили различные способы обработки ошибок при использовании Spring AMQP и, в частности, RabbitMQ.
Каждая система нуждается в определенной стратегии обработки ошибок. Мы рассмотрели наиболее распространенные способы обработки ошибок в архитектуре, управляемой событиями. Кроме того, мы убедились, что можем объединить несколько стратегий для создания более комплексного и надежного решения.
Как всегда, полный исходный код статьи доступен на GitHub .
Читайте ещё по теме:
- Сообщения с весенним АМЗП
- Экспоненциальный Откат С Пружинным AMQP
- Обработка ошибок для отдыха с пружиной
- Публикация и получение сообщений с клиентом Nats Java
- Фиксация 401s с помощью предварительных фар CORS и пружинной защиты
- Пользовательские страницы ошибок с Spring MVC
- Обработка ошибок в весеннем веб – потоке
- Метки amqp, error, handling, message, queue, spring
Источник: javascopes.com
А теперь давайте поговорим за RabbitMQ
Снова решил пописать про работу. На сей раз, проблема возника с RabbitMQ.
Имеется кролик с неработающими очередями. При этом всё поднято, но если заглянуть в логи, то можно увидеть в первую очередь нечто такое:
2021-06-09 10:02:38.030 [error] Error on AMQP connection (192.168.0.1:42538 -> 192.168.0.3:5672, vhost: ‘none’, user: ‘updater’, state: opening), channel 0:
«access to vhost ‘/’ refused for user ‘XXX’: vhost ‘/’ is down»,
‘connection.open’>>
2021-06-09 10:02:38.030 [info] closing AMQP connection (192.168.0.1:42538 -> 192.168.0.3:5672, vhost: ‘none’, user: ‘updat
er’)
2021-06-09 10:02:38.031 [info] accepting AMQP connection (192.168.0.2:14580 -> 192.168.0.3:5672)
2021-06-09 10:02:38.032 [info] accepting AMQP connection (192.168.0.1:42540 -> 192.168.0.3:5672)
2021-06-09 10:02:38.033 [error] Error on AMQP connection (192.168.0.2:14580 -> 192.168.0.3:5672, vhost: ‘none’, user: ‘smsc’, state: opening), channel 0:
«access to vhost ‘/’ refused for user ‘YYY’: vhost ‘/’ is down»,
‘connection.open’>>
2021-06-09 10:02:38.034 [info] closing AMQP connection (192.168.0.2:14580 -> 192.168.0.3:5672, vhost: ‘none’, user: ‘smsc’)
2021-06-09 10:02:38.035 [error] Error on AMQP connection (192.168.0.1:42540 -> 192.168.0.3:5672, vhost: ‘none’, user: ‘updater’, state: opening), channel 0:
«access to vhost ‘/’ refused for user ‘XXX’: vhost ‘/’ is down»,
‘connection.open’>>
Если же зайти в админку кролика, то мы видим сообщение вида:
После раскуривания некоторого количества логов, выяснилось, что проблема в Mnesia. По какой-то причине корраптятся сообщения в msg_stores. Если повнимательнее поискать, то можно заметить такое:
Некоторые люди зачем-то удаляют mnesia целиком, но если у вас, как и у меня, тонны очередей, эксчейнджей и пользователей, то потом это порой будет проблематично восстаналивать даже при наличии любой системы управления конфигурациями.
Источник: techquisitor.livejournal.com