-9

私は現在 Rebus を調査していますが、適切なドキュメントを見つけることができないため、このプロセスは困難であることが証明されています。誰かがこのエキサイティングな製品を理解するのを手伝ってくれることを願っています.

メッセージ処理中に何か問題が発生した場合、メッセージはキューに戻ることを読みました。

  1. メッセージはキューの先頭に戻されますか、それとも最後に置かれますか? 前面に配置すると、キューが本質的に処理できないメッセージでブロックされるため、これは問題になります。少なくともタイムアウトするか、再試行が超過するまでは。
  2. Rebus はすぐに使用できる個別の Retry キューをサポートしていますか?
  3. 再試行の間隔を指定できますか?
  4. Apache ActiveMQのように、再試行に指数バックオフ間隔を指定できますか?

ありがとう

4

1 に答える 1

3

1) キュー トランザクションがロールバックされ、メッセージが効果的に前に移動されます。したがって、すぐに再試行されます。

試行が 5 回失敗すると (少なくともそれが既定値です)、Rebus はメッセージをエラー キューに移動します。デフォルトの再試行メカニズムは、意図的に非常に迅速です。このようにして、入力キューが有害なメッセージによって詰まることはありません。

bus.Deferより洗練された再試行が必要な場合は、メッセージの配信を将来に延期できることを確認することをお勧めします。ただし、タイムアウト マネージャ(*)が実行されている必要があります。

2）再試行がないことを除いて、それは私が「エラーキュー」と呼んでいるものだと思います:)

ただし、いくつかのソリューションを作成しました。そこでは、エラー キューを定期的に空にし、すべてのメッセージを元のソース キューに戻す単純なエンドポイントをコーディングしました。

3) いいえ。NServiceBus には2 番目のレベルの再試行の概念がありますが、これは Rebus では (十分に) 必要とされたことはありません。しかし、Rebus を使用すると、ここでは自分で作業bus.Deferできます。予想されるさまざまな種類のエラーに簡単に適応できるインテリジェントな作業を行うのはかなり簡単なはずです。

4) (3)参照

それが少し明確になることを願っています:)

(*) タイムアウト マネージャーは、メッセージを受信し、しばらく保持し (つまり、データベースに保存し)、時間が経過したときに送信者に返すことだけを行う別のエンドポイントにすることができます。 . ただし、タイムアウト マネージャーはインプロセスでホストできますが、.Timeouts(t => t.???)構成スペルを使用します。

于 2014-08-13T07:17:16.067 に答える