2017-11-15 15 views
0

私は最新のAzure Service Bus SDKを試してきました。非常に少量のトピックメッセージ(ブラウザから手動で実行されるAzureファンクションHTTPトリガーによってポストされたもの)を使用して、私はAzureダッシュボードでかなり高い失敗率を見ています。しかし、Azure関数コードで例外を検出することはありません。送信アプリケーションは、これらの障害をどのように検出する必要がありますか?その点について、どのように特定の失敗を記録するのですか?私はグラフのスパイクを見ますが、詳細を見つけることができません。 (私はMSDN VS Enterprise freebieサブスクリプションを使用しています。)キューに入れられたメッセージや失敗が数分間Azureポータルに表示されないことがあります。 (これまでのところ私はサブスクライバを書いていないが、私はポータルが事実上「何でも加入している」クライアントだと思っている)Azure Service Busのエラー

トピックは長いTTLデフォルト)。重複検出はありません。コードは十分な(キャッチは省略/してみてください)シンプルで、NEWEVENTプロパティとToStringメソッドだけのカップルで簡単なC#クラスであるJsonConvertを使用してオーバーライドです:

 TopicClient topic = new TopicClient(connection, topic); 
     Message msg = new Message(Encoding.UTF8.GetBytes(newevent.ToString())); 
     msg.MessageId = newevent.Timestamp; 
     await topic.SendAsync(msg); 
     await topic.CloseAsync(); 
+0

エラーの詳細 - エラーテキストなどの追加情報を入力してください。 – Mikhail

+0

前述のように、ポータルでエラーカウントが表示され、例外が発生しないため、エラーはあります。 – McGuireV10

+0

数回のスローファイアテスト(数秒ごとに1回のヒット)と、私は50%の成功率を下回っています。実際に送信された12のうち5つのメッセージが受信されて配信されましたが、送信者には例外はありません。 (私はちょうど今、テスト目的のために加入者を追加したので、すべての配信が一度に起こったのです) [ポータル](https://i.imgur.com/DqoDe65.jpg) – McGuireV10

答えて

0

私はそれが低のためのブロッカーだとは思いません大量のトラフィックが発生する可能性がありますが、メッセージごとに新しく作成してTopicClientを閉じてはいけません。これを一度作成して後続の要求に再利用することができます。

Azure関数のコンテキストでは、自分自身でTopicClientを作成する代わりに、出力バインディング機能を使用する方がよい場合があります。docsの例を参照してください。ランタイムはトピッククライアントを管理します。

+0

バインディング、 'TopicClient'の接続が遅く、' AsyncClose'を管理するための関数のライフサイクル(イベント、廃棄など)がありません。私は関数のその機能を無視して、あらかじめ作成されたコードを書くことに集中してきました。技術的には、サービスバスメッセージは副作用が多い(機能の主要な作業成果物ではない)ので、契約に入れるのは少し間違っていると感じるが、とにかく試してみる。 – McGuireV10

+0

私はバインドアプローチへの切り替えが直面している直面する問題は、私の非同期HTTP機能はパラメータを使用できないため、ICollector 'に依存してしまいます。つまり、メッセージプロパティにアクセスできません。たぶん私はそれを考えすぎている - TopicClientを決して閉じないのは安全だろうか? – McGuireV10

+0

安全です。しかし、ICollectorはBrokeredMessageでも使えます。 – Mikhail

関連する問題