Не удалось отправить сообщение в очередь сообщений Azure Cloud
В настоящее время я пытаюсь отправить сообщение в очередь сообщений Azure с сервера компании, но, похоже, возникают проблемы с подтверждением того, что сообщение получено в Azure.
Никто не потребляет сообщение, поэтому оно должно быть помещено в "мертвую очередь сообщений".
Сообщения, которые я отправляю с сервера, не увеличивают этот счетчик. Сообщение, отправленное с виртуальной машины, увеличивает счетчик?
Что может блокировать это? Любой способ отладить проблему.
Ни одно из моих исключений не срабатывает..
Помимо этого, я заметил, что мои сообщения принимаются в очереди недоставленных сообщений, а не в активной очереди сообщений.
Nothings потребляет сообщение, но все примеры лазурной очереди, которые я видел до сих пор, упоминают, что активная очередь сообщений должна быть увеличена?
На сервере есть прокси-сервер для доступа в Интернет, но как же использовать этот тип соединения?
какая разница между этими двумя?
Я добавил сообщение трассировки стека:
The process failed: Microsoft.Azure.ServiceBus.ServiceBusCommunicationException: No connection could be made because the target machine actively refused it ErrorCode: ConnectionRefused ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it
но моя проверка на наличие связи isclosedвсегда возвращает false.
1 ответ
Из того, что я прочитал, я думаю, что Сэм Коган в комментариях прав. Я думаю, что вам нужно открыть соответствующие порты, чтобы служебная шина могла общаться.
В приведенной ниже статье перечислены требования к открытым портам:
- Сервисная шина Azure всегда требует использования TLS.
- Он поддерживает соединения через TCP-порт 5671 и TCP-порт 5672. Сервер немедленно предлагает обязательное обновление до TLS с использованием модели, предписанной AMQP. Привязка AMQP WebSockets создает туннель через TCP-порт 443, который затем эквивалентен соединениям AMQP 5671.
- Как современные клиенты (.Net Standard, так и Java) используют AMQP, поэтому применимо приведенное выше руководство.
- Старая библиотека.NET имеет собственный протокол на основе WCF, который использует TCP и порт 9354 (называемый SBMP, протокол обмена сообщениями служебной шины).
- Если вы используете исключительно API отдыха, вы можете открыть только порт 443.
TL; DR
Попробуйте открыть исходящие TCP-порты 5671, 5672 на брандмауэре, если это не сработает, попробуйте открыть порт 9354.
PS
Вот ссылки на то, как вы можете открыть порты на ваших брандмауэрах:
- Linux: https://www.codero.com/knowledge-base/content/24/431/en/how-to-open-_-close-ports-in-your-firewall-on-linux-iptables-firewalld-ufw.html
- Сервер Windows (выберите исходящий вместо входящего, как показано в этой ссылке): https://www.vultr.com/docs/how-to-open-a-port-in-windows-firewall-on-windows-server-2012
А также вот ссылка на причины, по которым сообщения могут автоматически отправляться в очередь недоставленных сообщений:
https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues
- HeaderSizeExceeded
- exception.GetType (). Имя
- TTLExpiredException
- Идентификатор сеанса пуст.
- MaxTransferHopCountExceeded
- Указано приложением