問題タブ [azure-servicebusrelay]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
ios - iOS のサービス バスでホストされているリレー サービスに接続する方法
iOS アプリで Azure サービス バスを使用して、以下のリンクを経由したサーバーと通信したいと考えています。C#を指しています。iOSで動作するように提案が必要です。
c# - Azure Relay Bus での接続の再利用
Azure の Web サイトをオンプレミスの WCF サービスに接続することを検討しています。これには Azure Relay Bus を使用したいと考えています。
最初の TCP チャネルのセットアップにはコストがかかります。この場合、約 3 秒かかります。これは理解できます。チャネルをキャッシュするので、次の呼び出しが高速になります。( 250ms ) チャネルは ThreadLocal ストレージにキャッシュされます。
複数のユーザーが Web サイトを使用している場合、新しいスレッドが使用されるたびに、チャネルの新しいインスタンスが作成され、TCP チャネルを設定するために再度料金を支払う必要があります。
私の質問は次のとおりです。
実際のユーザーがチャネルのセットアップの遅れに直面するのをどのように防ぐのでしょうか? クライアント スレッドごとに TCP チャネルを用意するのは通常のことですか?
注: オンプレミスでは、IIS 自動起動または NT サービスを使用して WCF サービスを "ウォームアップ" しますが、これは Azure で実行されている Web サイトに進む方法ですか? 各スレッドが独自のチャネルを持っているという事実は、それを容易にするものではありません。
コードを以下に示します。
azure - Azure サービス バス リレーの切断の問題
Windows サービスでホストされている http 経由の Azure Service Bus リレーを使用して、長時間実行されるテスト アプリをいくつか実行していますが、ほとんどの場合、これらは 2 ~ 3 日間正常に実行されます。ただし、インターネット接続を切断する内部ネットワークの不具合 (ファイアウォールの再起動など) が頻繁に発生することがあります。
この時点で、リレーは Azure でドロップされ、Web アプリはオンプレミス サービスと通信できなくなります。
Azure リレー クライアントはフォールト トレラントであると考えていました。つまり、Azure との接続が失われたことに気付いた場合は、接続を再確立し、接続できるまで試行を続けることができない場合は..これはそうではありません。これはかなり基本的なようです...?
サービスがインターネット上で通信できない「System.ServiceModel.CommunicationException」を見たのは一度だけです。それは、クライアントが起動して最初に接続を確立しようとしたときでした。
リレー サービスを介した一時的な切断の処理に関するアドバイスやフィードバックはありますか (それはクラウド --> オンプレミスの方向であるため、クライアントはサーバーに ping を送信できないため)。
azure - Azure メッセージ バスでの TCP リレー バインディングを使用した Hybrid ConnectionMode を使用したタイムアウト
msdn サンプル コード ( http://code.msdn.microsoft.com/windowsazure/Relayed-Messaging-Bindings-ca039161 ) を試しましたが、自分のテスト アプリケーションで同じ問題が発生しました。リレー モードで正常に動作する例がありますが、ハイブリッドに切り替えるとすぐに、クライアントはタイムアウト例外でサーバーに接続できません。タイムアウトを上げてトレースをオンにしましたが、すべてのトレースは一連の警告を示しています。
Tcp、Http、および AutoDetect の間でシステム接続モード環境設定を設定しようとしましたが、成功しませんでした。
サーバーのコード:
クライアントのコード:
読んでくれてありがとう、
ロビン
c# - Azure サービス バス上のタスク ベースのサービス インターフェイス
Azure で net.tcp リレー通信を使用すると、クライアントでコントラクト/フィルターの不一致の例外が発生し続けます。
この問題は、次の条件下でのみ発生します。
- azure net.tcp リレー バインディングの使用
- ハイブリッド モードに設定されたバインディング (サービスが相互に到達できるようにローカルで実行)
- サービス インターフェイスは、単なるデータ コントラクトではなくタスクを返します
インターフェース:
サービス例:
数秒後にバインドが直接接続に切り替わると、コントラクトの不一致例外がスローされるようになります。これは赤いニシンです。何が起こっているかというと、チャネルが混乱しているということだと思います。
クライアントの使用例 (残念ながら問題を解決していないように見えるタスクの継続に注意してください):
実行中にリレー バインディングが「ダイレクト」モードに切り替わるとすぐに、コントラクト/フィルターの不一致の例外 (追加) が定期的に発生し始めます。コールバックを渡します。
nettcprelay バインディングが内部で機能する方法には、呼び出しコードで対応できなかった、より複雑なスレッドプールの使用が含まれていると推測しています。channel を処理するさまざまな方法を試しました。特に、呼び出し後に .ContinueWith を同期的に試みましたが、役に立ちませんでした。
wcf - Azure Service Bus Relay WCF サービスが AddressAlreadyInUseException をスローする原因
Azure Service Bus Relay アドレスと webHttpRelayBinding を使用して WCF サービスを開始しようとすると、AddressAlreadyInUseException が発生します。
ここで例を使用しています: https://code.msdn.microsoft.com/Relayed-Messaging-Bindings-a6477ba0
次のコードで Relay を作成しない限り、サンプルは正しく動作しません。
Program.Main() で他の作業を行う前に、それを行う前に、Azure Service Bus nuget パッケージを追加する必要があります。次に、Microsoft.ServiceBus.ConnectionString という名前の appSettings の下にある App.config の ConnectionString を Azure 資格情報で更新する必要があります。
TCPViewer を使用して、使用中のポートを確認し、競合がないことを確認しました。実際のプロジェクトでは、webHttpRelayBinding と netTcpRelayBinding を試しました。最終的には、DuplexChannels を使用できるように netTcpRelayBinding を使用したいと考えています。
問題の原因について何か考えはありますか? 文書化されていない構成手順が欠落していませんか? どのチュートリアルでもこれは単純に見えますが、各チュートリアルにはいくつかの重要な手順が欠けていることがわかりました。ですから、私たちが見逃したステップがさらにあっても驚かないでしょう。
azure - Azure のモバイル サービスから WCF サービスにアクセスできない
WCF service
からアクセスし
たかったMobile Service
のですWindows Azure
。このために、Service Bus Relay
資格情報で構成された接続を使用してWCF service
.
Mobile Service
これをローカル マシンで公開したところ、WCF service
問題なく呼び出すことができました。
しかし、これMobile Service
を Azure に公開すると、アクセスしようとすると次のエラーが発生します。IService1 は、WCF サービスのコントラクトです。このコントラクトで Mobile Service の Web.Config ファイルにエンドポイントを定義しました。
これを解決するのを手伝ってもらえますか?
Exception=System.InvalidOperationException: ServiceModel クライアント構成セクションで、コントラクト 'ServiceReference1.IService1' を参照する既定のエンドポイント要素が見つかりませんでした。これは、アプリケーションの構成ファイルが見つからなかったか、このコントラクトに一致するエンドポイント要素がクライアント要素に見つからなかったためである可能性があります。
編集: この問題をさらに調査したところ、サービス参照を追加することによって生成されたプロキシ クラスが、クラウドでホストするときに Web.config で定義されたエンドポイント定義を取得していないことがわかりました。しかし、私のマシンの Azure エミュレーターでサービスを実行すると、Web.config からエンドポイント定義が取得されます。
そのため、この問題を解決するには、プログラムでエンドポイントを定義し、ChannelFactory クラスを使用して WCF サービスを呼び出す必要がありました。
Mobile Service がクラウドで Web.config を読み取れない理由について何か考えはありますか?