web-dev-qa-db-ja.com

メッセージをAzureクラウドメッセージキューに送信できませんでした

現在、会社のサーバーからAzureメッセージキューにメッセージを送信しようとしていますが、メッセージがAzureで受信されたことの確認に問題があるようです。

誰もメッセージを消費していないので、「デッドメッセージキュー」に配置する必要があります。

サーバーから送信するメッセージは、そのカウンターをインクリメントしません。 VMから送信されたメッセージはカウンターをインクリメントしますか？

これをブロックしているのは何ですか？問題をデバッグする方法。

私の例外はどれもトリガーされていません。

これに加えて、メッセージがアクティブメッセージキューではなくデッドレターキューで受信されていることに気付きました。

メッセージを消費しているものはありませんが、これまでに見たすべてのAzureキューの例では、アクティブなメッセージキューをインクリメントする必要があると述べていますか？

サーバーにはWebアクセス用のプロキシがありますが、このタイプの接続にも使用される必要がありますか？

これら2つの違いは何ですか？

スタックトレースメッセージを追加しました：

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を返すかどうかを確認します。

azuremessage-queuing
1
nano

私が読んだことから、コメントのサム・コーガンは正しいと思います。 Service Busが通信できるようにするには、適切なポートを開く必要があると思います。

以下の記事は、オープンポートの要件を示しています。

https://blogs.msdn.Microsoft.com/servicebus/2017/11/07/open-port-requirements-and-ip-address-whitelisting/

  • Azure Service Busでは、常にTLSを使用する必要があります。
  • TCPポート5671以上TCPポート5672）経由の接続をサポートします。サーバーは、AMQP規定モデルを使用してTLSへの必須アップグレードをすぐに提供します。AMQPWebSocketsバインディングは、TCPポート443を介してトンネルを作成します。これは、AMQP5671接続と同等です。
  • 最新の（.Net StandardおよびJava）クライアントはどちらもAMQPを使用するため、上記のガイダンスが適用されます。
  • 古い.NETライブラリには、TCPおよびポート9354（SBMP、Service Bus Messaging Protocolと呼ばれる）を使用するカスタムのWCFベースのプロトコルがあります。
  • Rest APIのみを使用する場合は、ポート443のみを開くことができる場合があります。

TL; DR

ファイアウォールでアウトバウンドTCPポート5671、5672を開いてみてください。それでも問題が解決しない場合は、代わりにポート9354を開いてみてください。

PS

ファイアウォールでポートを開く方法に関するリンクは次のとおりです。

また、メッセージがデッドレターキューに自動的に送信される理由へのリンクもあります。

https://docs.Microsoft.com/en-us/Azure/service-bus-messaging/service-bus-dead-letter-queues#moving-messages-to-the-dlq

  • HeaderSizeExceeded
  • exception.GetType（）。Name
  • TTLExpiredException
  • セッションIDがnullです。
  • MaxTransferHopCountExceeded
  • アプリケーションによって指定
1
user9975441