奇妙な問題が発生しています。別のクラウド サービス B が読み取れるように、メッセージをサービス バス キューに入れるクラウド サービス A があります。クラウド サービス B は、必要なことを処理するのに約 1 秒かかることがあります。その後、メッセージをクラウド サービス A のキューに戻します。クラウド サービス B がこれを行うとき、ScheduledEnqueueTimeUtc を使用して約 1 秒から 10 秒の遅延を設定します。メッセージで。
先週の金曜日、紺碧の停止により、このアプリケーションは完全にダウンしました。オンラインに戻すと、ScheduledEnqueueTimeUtc によって常に少なくとも 10 秒の遅延が発生します。たとえば、将来の 1 ～ 10 秒の日時を生成します。これを ScheduledEnqueueTimeUtc として設定し、送信するメッセージのプロパティとしてその時間を設定します。クラウド サービス A でメッセージを受信したときに、その datetime プロパティとメッセージの EnqueuedTimeUtc プロパティを比較します。これらの 2 つの時間はきれいなはずです。近くにあり、それが先週の金曜日までの数か月間機能していた方法です。
したがって、クラウド サービス B は、このメッセージを 1 秒でキューに入れると言っています。クラウド サービス A は、12 ～ 14 秒間キューに入れられなかったと言っています。メッセージをキューに入れるときに非同期メソッドを使用しています。ScheduledEnqueueTimeUtc を使用しない場合、遅延はありません。クラウド サービス A でそれらを振り返ってみると、時間は十分に一致しています。 -14 秒。
ScheduledEnqueueTimeUtc プロパティを設定する代わりに、quartz.net を使用してメッセージをスケジュールすることで、この問題を回避しています。しかし、これが起こり始めたのは本当に奇妙に思えます。