В настоящее время я пытаюсь отправить сообщение в очередь сообщений Azure с сервера компании, но, похоже, у меня проблемы с подтверждением того, что сообщение получено на лазурном сервере.
Никто не получает сообщение, поэтому его следует поместить в «очередь мертвых сообщений».
Сообщения, которые я отправляю с сервера, не увеличивают этот счетчик. Сообщение, отправленное с виртуальной машины, увеличивает счетчик?
Что может блокировать это? Любой способ отладить проблему.
Ни одно из моих исключений не запускается ..
Помимо этого, я заметил, что мои сообщения поступают в очередь недоставленных сообщений, а не в активную очередь сообщений.
Ничто не потребляет сообщение, но во всех примерах очереди Azure, которые я видел до сих пор, упоминается, что активная очередь сообщений должна быть увеличена?
На сервере есть прокси для доступа в Интернет, но может ли он использоваться для этого типа соединения?
в чем разница между этими двумя?
Я добавил сообщение stacktrace:
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.
Из того, что я прочитал, я думаю, что Сэм Коган в комментариях прав. Я думаю, вам нужно открыть соответствующие порты, чтобы позволить служебной шине общаться.
В статье ниже перечислены требования к открытому порту:
- Служебная шина 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.
P.S.
Вот ссылки на то, как вы можете открывать порты на ваших брандмауэрах:
А также вот ссылка на причины, по которым сообщения могут автоматически отправляться в очередь недоставленных сообщений:
- HeaderSizeExceeded
- exception.GetType (). Имя
- TTLExpiredException
- Идентификатор сеанса равен нулю.
- MaxTransferHopCountExceeded
- Уточняется приложением