2017-08-22 10 views
0

私の俳優の中で、サードパーティのライブラリ(未来を後戻りさせる)への呼び出しがあります。私はその未来を自己に配管しているので、返信をメールボックスのメッセージとして処理することができます。俳優内のFuture.pipeToの処理

class MyActor{ 
    def receive:Receive = { 
    case x:Message => { 
     val future = callToThridPartyLib(x) 
     future pipeTo self 
    } 
    case x:Reply => { 
     //process reply received on future completion 
    } 
    } 
} 

私の質問は、このアプローチのオーバーヘッドは何

  1. ですか?

  2. このようなパイプごとに別々のスレッドが割り当てられますか。 ステートメント?

  3. そうなら、 スレッドがすべて使い果たされるのを避けるためにpipeToを管理するスレッドプールが必要ですか?

は、基本的にビクターが言う何

+0

^^私があなただったらコードを見てみましょう:https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/pattern/PipeToSupport .scala –

+0

Viktorありがとう、私はコードを見たが、まだオーバーヘッドの疑いを持っていた – Anand

答えて

3

ありがとう、しかし: はpipeToのオーバーヘッドが非常に低いです:それは、一つのメッセージを送りつの閉鎖を作成します。それだけです。スレッドを追加する必要はありません。 Futureが完了したスレッドからメッセージが送信され、すべてのアクターメッセージのように、指定されたアクターに対して構成されたディスパッチャーで受信されます。

callToThirdPartyLibでもExecutionContextの世話をする必要があります。内部でブロッキング呼び出しを使用していて、デフォルトのAkkaディスパッチャを使用してコードを実行すると、スレッドが不足することがあります。しかし、これは質問のために話題にはならないようです。

+0

pipeToはandThen、andThenのakkaドキュメントを使用しています - "andThenは指定されたコールバックを持つFutureを作成します。将来のサンプルと同じように、次のサンプルのような順序付けが可能です。 "新しい未来が作成されます。親と同じスレッドを使用しますか? – Anand

+0

Link - http://doc.akka.io/docs/akka/current/scala/futures.html#define-ordering – Anand

+0

完了したら、暗黙の 'ExecutorContext'を使ってタスクをスケジュールします。これは、実行する具体的なスレッドを決定するものです。 – jrudolph