2

クライアントが提供する一連のイベントシンクを管理し、それぞれが独自のイベントストリームにサブスクライブしています。通常、各シンクはデータを独自のネットワークパイプにプッシュします。つまり、イベントをシンクにプッシュする際に悪用可能な同時実行性があります。同時に、適切なイベントの順序を確認する必要があります。これは素朴なアプローチです。

final Set<Sink> sinks = new HashSet<>();
final ExecutorService pool = Executors.newCachedThreadPool();

eventSource.addListener(new SourceListener() { 
  public void sourceEvent(final Event event) {
    final Sink sink = resolveSink(sinks, event);
    pool.submit(new Runnable() { public void run() { sink.accept(event); }});
}});

これは適切な順序を保証するものではありません。スレッドプールが各イベントキューを単一のスレッドに関連付け、accept-eventタスクをその特定のスレッドのタスクキューにディスパッチした場合、これは堅牢になります。基本的なアイデアや実行可能なアプローチのスケッチを探しています。

4

2 に答える 2

3

それぞれが発生した順序でイベントを処理する必要があるということであればSink、これはまさにActor モデルのアプリケーションです。Java で実装された多数の Actor フレームワークが存在します。最も単純なものは、私が開発した df4jです。

補遺

(Marko Topolnik による、コメントでの議論の要約)

各イベント ストリームごとにキューを維持し、executor サービスを使用します。新しいイベントが発生したら、キューをシンクに排出するタスクを送信します。タスクは無条件に送信してはなりませんが、そのようなタスクがまだ実行されていない場合に限ります。これを確実に行うには、タスクの送信時に設定され、完了時にタスクによってリセットされるブール フラグ (イベント ストリームごとに 1 つ) を使用します。

于 2012-10-18T09:36:42.763 に答える
1

独立性を確保するために、クライアントごとに 1 つのスレッド プールを用意します。

クライアント リスナーをラップして、クライアントのスレッド プールで同じイベントをトリガーできるため、コードの残りの部分で単純なリスナーとして扱うことができます。

于 2012-10-18T08:42:52.703 に答える