問題タブ [azure-queues]

Azure Message Queue メッセージの有効期限は最大 7 日間です。うーんなんで？メッセージの存続時間を無限にして、処理に取り掛かるまでキューで待機させたいと考えています。この奇妙な 7 日間の制限がなければ、Azure キューは私にとって完璧なソリューションです。キューをバックアップする 100 TB のストレージ アカウント全体を持っていますが、それを使用できないのはなぜですか?

誰かがこの問題の回避策または解決策を考えていることを願っています。何か案は？

(ご想像のとおり) メールを送信するだけのメール Azure ワーカー ロールがあります。

To、From、および Body を持つキューで動作します。したがって、実際のキュー メッセージには電子メール自体が含まれます。

しかし、メールのサイズが 64KB を超えるという問題が発生したため、キューに入れることができません。

そのため、メールを Azure Blob に保存し、代わりにその Blob への参照をメッセージに保存する必要があると考えています。その後、ワーカーは blob からメールを取得できます。

しかし、Blob Storage は画像やファイルなどに適しているようです。これは、私が作成したメモリ内の POCO にすぎません。

どうすれば本質的にPOCOをAzure Blobに配置できますか?または、このタスクを達成するための他のアイデアはありますか?

名前空間マネージャーを使用しているサービス バス トピックを作成しようとしています。名前空間マネージャーは関数 CreateFromConnectionString を表示していません。

}

Azure トピックがあり、トピックに追加されるタイプ X のイベ​​ントごとに、そのイベントを 1 つの場所に記録する 1 つのサブスクライバーが必要であり、そのトピック メッセージに対して実際に何らかの処理を行う別のサブスクライバーが必要です。

監査またはサブスクライバーの処理の失敗を数分間処理し、トピック メッセージを見逃さず、データ破損のシナリオを作成するための正しい設計は何ですか?

各インスタンスの 3 つのバージョンを実行できた場合、3 つすべてが同時にダウンする可能性はほとんどありませんが、それは完璧なシナリオではありません。これには他にどのようなオプションがありますか? API の一部として不足しているものはありますか?

Azure キュー ストレージを使用しています。Microsoft.WindowsAzure.StorageClient から Microsoft.WindowsAzure.Storage にアップグレードしました。最近、Lokad から CloudFx に切り替えました。プロセスのある時点で、重複する Dequeue Count を含むいくつかの列を Queue storage に取得し始めました。

これらの列がどのように作成されているのかわかりません。Dequeue Count 列が 2 つあるのはなぜですか?

Windows サービスから Windows azure キューに接続しようとしています (つまり、azure で実行されておらず、今のところデスクトップでのみ実行されますが、最終的には自己ホスト型の Windows サーバーで実行されます)。

ダッシュボードによって生成される接続文字列は、次の形式になります。

を初期化しようとしていますCloudStorageAccountが、フォーマットの例外が発生します (タイトルに記載されているとおり)。

これはすべてのドキュメントと一致しているようです...何が起こっているのか誰でも解決できますか?

通常の Azure キューでは、メッセージをポップしてから、いくつかの作業を行います。作業が完了するまでメッセージを削除したくありませんでした。

そのメッセージは、失敗と見なされてキューに再び表示されるまで、どのくらいの期間非表示のままになりますか?

例えば。

私の作業には 30 秒程度かかる場合があります。または、1 分か 2 分かかった場合はどうなりますか?

基本的に、別のワーカーがキューからメッセージをポップした場合に備えて、作業が完了する前にメッセージが再び利用可能になることは望ましくありません..このワーカーはまだ作業を行っています.

「非表示」時間を設定できますか?

Azure ロールのインスタンスがクラッシュしたという事実を検出したいと考えています。私の場合の検出とは、私の役割の別のインスタンスがクラッシュについて通知されることを意味します。以下で説明する私の考えを確認するか、別の解決策を提案してください。

私が思いついたアイデアは、Azure Queue 内のアイテムの処理時間が限られているという事実を利用しています。

1. Azure キューを構成します。ロールのすべてのインスタンスがこのキューをリッスンします。
2. 内部エンドポイントを持つようにロール インスタンスを構成する
3. インスタンス A が起動すると、メッセージがキューにポストされます。メッセージには、インスタンス A の ID、A の内部エンドポイントの IP、このメッセージを A に転送する必要があるマーカーが含まれています。
4. ほとんどの場合、メッセージは別のインスタンス B で終了します。B は内部エンドポイントを介して MessageId と PopReceipt を A に転送します。インスタンス A は、この ctr http://msdn.microsoft.com/en-us/library/dn451949.aspxを使用して CloudQueueMessage のオブジェクトを作成します。
5. インスタンス A は、受信したメッセージの表示タイムアウトを無限に更新し始めます。Azure キューの観点からすると、このメッセージは非常に長い間処理されます。最初の更新で、A は「このメッセージを転送する」マーカーを削除します。
6. インスタンス A がクラッシュすると、処理の延長が停止します。メッセージは、すぐに他のインスタンスで自動的に表示されるようになります。
7. インスタンス C はメッセージを取得し、クラッシュした A について学習します。メッセージにはインスタンス A の ID が含まれており、「このメッセージを転送する」マーカーは含まれていません。
8. インスタンス A が正常に停止すると、そのキュー メッセージが処理済みとしてマークされます。