問題タブ [message-bus]

このアプリケーションでは、パブリッシャーがメッセージを作成してトピックに送信します。

次に、トピックのすべてのサブスクライバーがメッセージに確認応答するまで待機する必要があります。

表示されません。メッセージ バスの実装により、これが自動的に行われます。そのため、各サブスクライバーが完了したら、クライアントに独自の新しいメッセージを送信するようにしています。

これで、クライアントはそのようなメッセージをすべて受信し、各宛先から 1 つを受信したら、必要なクリーンアップを実行できます。しかし、クライアント (送信者) が確認応答のストリームの途中でクラッシュした場合はどうなるでしょうか? このような不運に対処するには、バスが既に実装しているものをクライアントで (再) 実装する必要があります。十分な受信確認が得られるまで、受信確認を保存します。

私たちのニーズはそれほど難解なものではないと思います。送信者 (パブリッシャー) が複数の受信者 (サブスクライバー) からの確認を待たなければならない状況をどのように処理しますか? 各購読者からメーリングリストへのReturn-Receiptsをリクエスト（および待機）するようなものです...

問題があれば、RabbitMQ を使用しています。ありがとう！

Simple Injector に接続しようとした Membus の IoC 機能を見てきました

アイデアは、すべてのタイプを自動的に に登録するというものですRegisterManyForOpenGeneric(typeof<CommandHandler<>),typeof<CommandHandler<>).Assembly)。

通常は正当な理由で間違いなく、SimpleInjector は複数の登録を許可しませんが、コマンド処理のさまざまな側面/懸念をさまざまなハンドラーによって実装するためにこれを行いたいと考えています。

確かに、IEnumerable<object> IocAdapter.GetAllInstances(Type desiredType)membus からのインターフェースはコレクションを想定しているため、複数のハンドラーを呼び出すことができます。

Membus を SimpleInjector IC と組み合わせる最善の方法は何でしょうか?

脚注

私は、慣習によってメンバスを接続する他の方法を見てきました:

しかし、IoC コンテナーを使用してライフタイム スコープを処理し、コマンド ハンドラーをインスタンス化して必要になる前に手動で接続することを避けたいと考えています。

サード パーティの Web サービスと対話する Rebus メッセージ ハンドラーがあります。すぐには制御できない理由により、この WCF サービスは、独自のデータベースでデータベース デッドロックが発生したため、頻繁に例外をスローします。その後、Rebus はこのメッセージを 5 回処理しようとします。これは、ほとんどの場合、5 回のうちの 1 回が幸運であり、デッドロックに陥らないことを意味します。しかし、メッセージがデッドロックに続いてデッドロックになり、エラー キューに入ることがよくあります。

長期的な目標となるデッドロックの原因を修正する以外に、次の 2 つのオプションが考えられます。

1. 成功するまで、この特定のメッセージ タイプのみを試してください。できればタイムアウトを設定できるので、継続的に試行してプロセスをさらに詰まらせるのではなく、「デッドロックが 5 回発生した場合は 5 分後に再試行してください」とします。私はすでに Thread.Sleep(random) を実行してメッセージをいくらか広めていますが、5回試行してもあきらめます。

2. この特定のメッセージ タイプを、メッセージを処理するワーカーが 1 つしかない別のキューに送信して、これが並列ではなく逐次的に行われるようにします。現在の構成では 8 つのワーカー スレッドを使用していますが、Web サービスが同時に呼び出され、メッセージが相互に干渉するため、デッドロックの状況が悪化するだけです。

オプション＃2が私の好みですが、これが可能かどうかはわかりません。現在、受信側の構成は次のようになっています。

そして、受信側の .config :

構成からわかることから、「リッスン」する入力キューを 1 つしか設定できません。流暢なマッピング API を介してこれを行う方法を実際に見つけることもできません。それも入力キューとエラーキューを1つだけ取るようです：

基本的に、私が探しているのは、次のようなものです。

私の要件を処理する方法に関するヒントはありますか?

私は、Amazon の SQS Dead Letter Queue が正確に何をしているのかを明確にしようとしています。

http://aws.typepad.com/aws/2014/01/amazon-sqs-new-dead-letter-queue.htmlによると

Dead Letter Queue -コンシューマーによる最大数の受信後に正常に処理されなかったメッセージを受信する SQS キューの ARN (Amazon リソースネーム) 。

それはPoision Queueのように聞こえませんか？主な違いは、消費者がメッセージを受け取ったことです。デッド レターは、メッセージに問題がない可能性があるが、おそらくサービスの停止が原因で配信できない場合です。http://www.eaipatterns.com/DeadLetterChannel.html

これは、メッセージが複数回正常に受信されているように聞こえますが、メッセージの処理は失敗します。これは、Poison Message Queue の意味であると理解しています。

メッセージバスとキュー

デッド レター パターンは、普通の古いキューのコンテキストでは異なる意味を持ちますか? SQS は単なるキューであり、メッセージ バスではないため、メッセージの配信は担当しません。代わりに、メッセージがピックアップされる (要求される) のを待ちます。したがって、メッセージを配信しようとして受信者を見つけることができないメッセージ バスがないため、従来のデッド レター パターンは実際には適用されません。

SQS はメッセージ バスのように動作できますか?

キューからメッセージを明示的にポーリングする代わりに、SQS を介してチャネルとリスナーを設定する方法はありますか?

価格設定アプリケーションがあります。価格要求を Azure Service Bus Queue (任意のキュー) "PricingRequestQueue" に送信します。これらを取得して処理し、結果を PricingResponse キューに返すワーカーが多数あります。

PricingResponse キューに Observable を作成したいと思います。フィルタリングは必要ありませんが、バッチ インターフェイス (QueueClient.BeginReceiveBatch) を使用してメッセージを読み上げたいと考えています。キューには予想される数のメッセージがあり、読み取るセッションがあります (QueueClient.AcceptMessageSession(correlationIdentifier))。

私はまだ RX について理解を深めようとしていますが、これで問題は解決します。

さまざまな境界付けられたコンテキストを Windows Service Bus と統合していますが、いくつか質問があります。

1) 他の境界付けられたコンテキストで重複を検出する方法は? 最後に処理されたメッセージ シーケンスを保存しますか? イベントを再起動HandleEvent(OrderPlaced orderPlaced, bool isReplay)して、最初の同期のために将来的に本番環境に組み込まれる新しい境界付けられたコンテキストを再同期できるようにする機能が必要です。

2) コンテキスト間メッセージ バスの場合、境界付けられたコンテキストごとにトピックを使用しますか (また、境界付けられたコンテキストをグループ化する名前空間を持ちますか)? それとも、名前空間ごとに 1 つの境界付けられたコンテキストですか?

3) メッセージ バスのドキュメントには、メッセージが順不同で到着する可能性があると記載されています。メッセージ 6 と 8 が受信されたが、7 が受信されなかった場合はどうなるでしょうか? 指定された時間待ってから続行しますか? 自己修復を許可するには?

4) 上記はほぼすべての DDD プロジェクトでかなり一般的だと思いますが、コマンド/応答プロトコルを含むメッセージングを処理して、外部の境界付けられたコンテキストから以前のイベントの同期を要求するライブラリはありますか?

Xamarin で音楽を再生する Android アプリを構築しています。音楽とプレイリストを表示するフラグメントを再生するサービスがあります。サービスからの小さなフィードバックが必要な場合があり、これまで通信にMessageBusを使用していました。

今のところ、フィードバックが必要なのは、ユーザーがリスト全体をループすることを選択し、現在のトラックが終了したときに、次のトラックを強調表示するためにフラグメントに通知する必要があるときだけです。将来的にはフィードバックが必要になるかもしれません。

これは悪い考えですか？サービスをboundServiceに変更したほうがいいですか？この方法を選択したのは、この方法の方がはるかに簡単で、必要なフィードバックが非常に限られているためですが、今は考え直しています。ありがとう