問題タブ [disruptor-pattern]

私は Scala の Disruptor で遊んでいますが、奇妙な問題があります。チェーンの最後のハンドラー (どのハンドラーであっても、チェーンの長さに関係なく) も呼び出されません。これが私がやっていることです：

デバッガーでは、最後のハンドラーがコンシューマー リポジトリに追加されていることがわかりますが、どういうわけか onEvent は呼び出されません。私は CachedThreadPool エグゼキュータを使用しています。

どうすればこれを機能させることができますか？

いくつかの単体テスト コードを書いており、ディスラプターのリング バッファーに発行されたすべてのイベントが処理されたことを知る必要があります (前述のように、特定のテスト ケースのみを対象としています)。

数時間調査しても洗練された解決策が見つからなかった後、テスト ケースで次のコードを使用することにしました。

動作しているように見えgetBufferSize()ますが、 anintをremainingCapacity()返し、 alongを返すので、何かを見落としているのではないかと心配しています。

を返し、?を返す理由getBufferSize()は誰でも知っています。バグでない限り、私には意味がありません。intremainingCapacity()long

ディスラプターを含む一部のコードを単体テストするには、メインのテスト スレッドが続行される前に、ディスラプターに発行されたイベントが処理されるようにする必要があります (明らかに、ディスラプター コードをテストしていません)。

より洗練された解決策がないため、次のように問題を解決しました。

ただし、ディスラプターを「同期モード」に設定する方法があるかどうか（調べましたが見つかりませんでした）、または使用可能な「同期モックディスラプター」実装で、スレッドがpublish()によってすべてのイベントが処理される前onEvent()から戻る

IO を処理する別のディスラプターにパブリッシュするビジネス ロジックにディスラプターを使用しています。IO ディスラプターにパブリッシュされたイベントは、IO を構築して検証するにはあまりにも早く到着する可能性があります。まあ、それは一種のポイントです...

IO ディスラプターは次のようにセットアップされます。

次に、Logic イベント ハンドラーを次のように設定します。

何が起こっているかというと、送信 (ioMessage) するまでに、何らかの形で ioMessage を上書きする新しいイベントが発生したため、重複したメッセージが送信されています。

何を提案できますか？

Disruptor ( https://github.com/LMAX-Exchange/disruptor/wiki )の上にアクター モデルを作成するプロトタイプを作成しています。すべての例に基づいて、イベントのミューテーションは、揮発性または可視性が保持されることを確認する他の方法を使用しません。これが安全であることを可能にするものは何ですか？

FAQ では、これが処理されているようです ( https://github.com/LMAX-Exchange/disruptor/wiki/Frequently-Asked-Questions#do-you-relax-the-consistency-model-to-gain -パフォーマンス）しかし、私はまだ方法を見ていません。

これを読んでくれてありがとう！

2 つ以上の異なるイベントを出力ディスラプターに同時に (次々に) 発行していますが、ディスラプター onEvent は通常、最後に発行されたイベントのみを IO セッションに送信しています。基本的にイベントデータは上書きされます。セッションレイヤーで各イベントのコピーを見たいのですが。セッションレイヤーをロックで同期しようとしましたが、通常、パブリッシャーはロックに対してもまだ速すぎます (動作している場合もありますが、ほとんどの場合は動作していません)。

ここにいくつかのコードがあります：

これは他の誰かに起こりましたか？パブリッシャーのスピード バンプ以外に別の解決策はありますか?

プロデューサーコードは次のとおりです。

Web サービスをホストする Java でオーケストレーター システムを設計しています。要求に応じて、XML で記述されたフローを呼び出します。これは、次々に実行されるステップにすぎませんが、XML はユーザーにフローが何であるかを伝え、ユーザーはXML を変更してフローを変更することもできます。新しいサービスを追加して、それを XML に追加できます。しかし、設計している間、私は今、次のようなことで混乱しています.

1. ブロッキング キューを使用してサービスを実行可能にし、エグゼキューターにスケジュールすることでサービスを常に有効にしておく必要があります。これにより、新しいリクエストが到着したときにリクエストがブロッキング キューにプッシュされ、サービスがそれを処理します。そして、異なるサービス間でメッセージ パッシング タスクを実行するメールボックスを作成します。

2. サービスを実行可能にする代わりに、クラスをシングルトンにするSpring IOCを使用する必要があります。したがって、インスタンスは1つだけになり、リクエストをサービスメソッドに直接送信します。したがって、スレッドがないため、面倒なことはありません。また、メールボックスを実装する必要もありませんでした。

3. nodejsやngnixのようにイベント駆動型システムがどのように高速であるかについて読んだので、disuptorフレームワークを使用してすべての着信リクエストをリングバッファーにプッシュし、リクエストの処理を開始するオーケストレーターにイベントを発行するハンドラーを作成して、また、オーケストレーターが完了すると、コールバックを使用して呼び出し元に応答を返すように、要求と共にコールバックを送信します。しかし、リクエストは同じタイプではないため、ディスラプター オブジェクトの割り当てを利用することはできません。

システムは、低遅延で最大のスループットを提供する必要があります。システムは、将来的に新しいサービス/フローを XML に追加するため、パフォーマンスに影響を与えずに新しいフローを採​​用する必要があります。私はJava 7のみを使用でき、Scalaは使用できないため、制限があります。