問題タブ [azure-servicebus-queues]

私はAzureサービスバスを使用して、Webロールとワーカーロールの間でメッセージを送受信してきましたが、これは本当に良い解決策だと本当に思っていましたが、最近、サービスバスが非常に不安定であることがわかりました。理由もなくデッドレターに。私のコードに問題があるかどうかはわかりませんが、機能する場合と機能しない場合があるため、単に不安定であるように見えます。したがって、サービスバスに代わる解決策があるかどうかを知りたいと思っていました。または、上記の問題を引き起こしているサービスバスの実装で行われている間違いを知りたいと思っています。以下は私のコードです

上記のコードでは、1 つの Service Bus クライアントのみのメソッドを示しています。私のワーカー ロールでは、3 つのサービス バス クライアントを使用しています。つまり、異なるキューからメッセージを非同期的に送受信しています。いくつかのメッセージがどのように機能し、いくつかのメッセージが理由もなくデッドレターになるのは本当に奇妙です。何が問題なのか分からない人がいたら教えてください

Azureメッセージバスキューに問題があります。

MessageLockLostExceptionスローしましたが、割り当てられたタイムアウト00:01:10内にリクエスト操作が完了しませんでした。この操作に割り当てられた時間は、より長いタイムアウトの一部であった可能性があります。

キューをに設定しましたReceiveMode.PeekLock。

私もチェックします

なぜこれが起こるのでしょうか、何が原因でロックが解除されますか？私はあなたが受け取るところからどこかで読んでいましたあなたはデフォルトで5分あります。通常、このプロセスには少し時間がかかります。ロックを更新したかったのですが、うまくいきません。

Java SDK (0.4.1) を使用して SB キューからメッセージを取得するとReceiveQueueMessageResult、問題のキューが空であっても null 以外が返されます。その結果を呼び出すgetValue()と、null 以外が返されますBrokeredMessage。空の Queue で receive を呼び出したことをどのように伝えればよいですか? 明らかに、サイズのクエリは、分散型の同時実行システムではオプションではありません。

モードを使用してReceiveAndDeleteいて、キューが新しく作成されたので、空であることはわかっています。

ドキュメントによると、API への基になる呼び出しは 204 の StatusCode を返す必要があります。返された結果またはメッセージでそのコードにアクセスする方法が見つかりません。

過去26時間ほどで、pathが存在しないキューであるServiceBusConstract.getQueue（path）への呼び出しは、最終的な原因がバインディングの問題であるServiceExceptionをスローします。

原因：javax.xml.bind.UnmarshalException：予期しない要素（uri： " http://www.w3.org/2005/Atom"、local： "feed"）。予想される要素は、<{ http://schemas.microsoft.com/netservices/2010/10/servicebus/connect } QueueDescription>、<{ http://schemas.microsoft.com/netservices/2010/10/servicebus/connect }です。 SubscriptionDescription>、<{ http://schemas.microsoft.com/netservices/2010/10/servicebus/connect } TopicDescription>、<{ http://www.w3.org/2005/Atom } entry> at com.sun .xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent（UnmarshallingContext.java:647）

これは、SDKの0.4.0バージョンと0.4.1バージョンの両方を使用する場合に当てはまります。

以前は、この呼び出しは.getValue（）メソッドがnullを返したGetQueueResultを返しました。私のテストが失敗しているので、これを見つけました。

本番サービスは、この呼び出しとの互換性がなくなるように更新されていますか？ServiceBusContract.getQueue（nonExistentPath）の予想される動作は何ですか？

今日、Azure キューが機能していないことに気付きました。それを再起動することは可能ですか？

Azure キュー (ストア アカウント) 内のメッセージ数 (またはおおよその数) を特定する方法があることは知っています。ただし、Azure Service Busキューで保留中のメッセージの数を照会する方法はありますか?

Azure Service Bus トピックにサブスクライブしたときに受信したメッセージを解析しようとすると、シリアル化例外が発生します。私が欠けているものを見た人はいますか？Silverlight コードに Microsoft.ServiceBus.Samples.Messaging を使用しています。

次のコードを含む Web サービスがあります。

次のコードを持つ SilverLightClient があります。

SerializationException がキャッチされました System.String 型のオブジェクトの逆シリアル化中にエラーが発生しました。ルート レベルのデータは無効です。行 1、位置 1。

スタックトレース：

したがって、シナリオは、SB キューを使用して、他のサービスへの発信コールバックを抑制しているというものです。他のサービスへのコールバックに関する標準的な問題の 1 つは、それらが制御不能な時間ダウンする可能性があることです。ターゲットがダウンしている/応答していないことを検出したと仮定すると、そのメッセージを破棄してキューにすぐに再表示されないようにするための最良のパターンは何ですか?

私が知っている、試した、または検討しているいくつかのアプローチを次に示します。

• 明らかにBrokeredMessage::Abandon()、メッセージを使用しただけではロックが解除され、キューに戻されます。これは、このシナリオと私が回避しようとしているものにとって明らかに望ましくありません。

• エラーが発生したという事実を無視して Abandon を呼び出さないと、すぐに表示されなくなりますが、再び表示されるまでの時間を細かく制御することはできず、実装したいと思います減衰再試行戦略。

• BrokeredMessage::Abandon(IDictionary<string, object>)プロパティを呼び出して何らかの形で更新できるのではないかと思いScheduledEnqueueTimeUTCましたが、これを試してみましたが、メッセージの最初の送信以外にそのプロパティに影響を与える方法はないようです。理にかなっていますが、試してみる価値があると思いました。

• この状況で使用BrokeredMessage::Complete()するだけで、実際にはプロパティ セットを使用してメッセージの新しいコピーをキューに入れることを検討しました。ScheduledEqueueTimeUTC

最後の箇条書きはややこしすぎるように思えますが、キューの固有の性質を考えると、おそらく正しい答えであるという結論に達しています。不足している Azure SB キュー内でこれを行うためのより良い方法があるかもしれないと考えました。

何らかの理由で、Windows azure でホストされているキューが.DefineEndpointName()構成を尊重していません。

Azure Bus のキュー名は常に、それをホストしている worker ロールにちなんで名付けられます。これは問題ありませんが、一般的には、規則を手動でオーバーライドするオプションがあれば、もっと気分が良くなります。

独自のキュー名を定義するにはどうすればよいですか?