Akka を使用して以下を実装しようとしています (Akka を適切な方法で使用しようとしていると思います)。
n 個のリソース リスナーを持つシステムがあります。基本的に、リソース リスナーは、入力リソースをリッスンし、見たものを公開するエンティティです (つまり、データベースのポーリング、ログ ファイルの追跡など)。
そこで、Akka アクターを使用して、これらの小さな作業単位 (リソースをリッスンする) を実行したいと考えています。Akka がtスレッドのスレッド プールを提供することに気付きましたが、これはリスナーの数よりも少ない可能性があります。残念ながら、これらのリソース リスナーからのメッセージの取得がブロックされている可能性があるため、次のメッセージが表示されるまでに数秒、数分かかることがあります。
リソース リスナーを一時停止してスレッドを別のアクターに任せる方法はありますか?
必要なのは、プロデューサー API (リソース) を非同期にするか、少なくとも非ブロッキング操作をサポートすることです (ポーリングを実行できるようにするため)。API がそれをサポートしていない場合、全能のアクターを使用しなくても、このプロパティを改造する方法はありません ;-)
getWhatever()リソースが物を取得するブロッキング メソッドのみをサポートしている場合は、リソースごとに 1 つのスレッドを割り当てる必要があります。PinnedDispatcher を持つアクタは、これを行う方法になる可能性があります。ただし、リソースからのイベントを待機している間、アクターは応答しないことに注意してください。
peek()リソース API にorメソッドがある場合poll()、リソースごとに 1 つのアクターを使用し、それらにスレッド (またはプール) を共有させ、必要に応じて (つまり、100 ミリ秒ごとまたは必要に応じて) ポーリングをスケジュールできます。これには、実際に誰もブロックされず、システム全体の応答性が維持されるという大きな利点があります。ただし、イベント受信の遅延は、スケジュール間隔のオーダーになります。
優れた非同期 API に遭遇するのに十分なカルマがある場合は、イベントが発生するたびにアクターにメッセージを送信するコールバックを登録するだけです。残念ながら、これは標準ではありません。
JVM は、現在のコール スタックのラップアップをサポートしておらず、別の処理を行って後で同じ処理状態に戻ります。メソッドは、実際に終了したときにのみスタックからポップできます。
1 つのオプションは、ブロック API を Futures 内で呼び出すことです。Future は、Actor の ExecutionContext とは別の ExecutionContext (スレッド プール) を使用する必要があります。
例については、このブログ投稿を参照してください(具体的には CacheActor.findValueForSender)。
一般に、アクターで操作をブロックしないようにする必要があります。ファイル IO には非同期ライブラリがあり、一部のデータベースにもあります。それができない場合は、デフォルトのディスパッチャーを変更して、基になるスレッド プールが必要に応じて拡張されるように設定できます。