1

人々のリストをトラバースし、class1の各人々のコールバックを呼び出す次のコードがあります。

def syncPeople(callback: Person => _) = Future {
   person.findAll(criteria).foldLeft(0L) { (count, obj) =>
      callback(obj)
      count + 1
   } 
}

コールバックとsyncPeopleの呼び出しは、class2にあり、次のようになります。

def getActor(person: Person):ActorRef = {
  if(person.isMale) maleActor
  else femaleActor
}

def process(person: Person): Unit = {
   val workActor = getActor(person)
   workActor ! person
} //The actor does the actual work and may be quite intense

def syncPeople(process)

ここで、すべての人を同期するのにかかった合計時間を追跡したいと思います。つまり、最後のworkActorが作業を完了したとき。3番目のアクターであるMonitorActorを使用して、開始時刻と終了時刻を追跡しています。MaleActor、FemaleActorは、個人を処理するときにこれにメッセージを送信できます

この生成されたプロセスを追跡するための最良の方法は何ですか？

探検しました

  1. Future.sequence //しかし、workActorにメッセージを送信するクラスはアクターではありません。だから未来はメッセージを受け取らない

  2. 終了時にpersonIdを追跡しますが、varを使用せずに、受信したメッセージをMonitorActorに蓄積することはできません。これを実装することはできません。また、varを使用することは好ましい方法ではありません。

これを実装する他の方法は何でしょうか

4

2 に答える 2

4

おかしい、私は現在これと非常によく似た問題に取り組んでいます。私が提案する解決策は、状態を追跡するakka-fsmを使用することです。

基本的に、状態オブジェクトの外部で、IDを表すLongを生成するようなことを行います。

def getId(): Long = System.currentTimeMillis() / 1000L

正しく実装された場合の状態オブジェクトは不変であるため、トランザクション全体でこのIDを再利用し続けるだけです。

私はこの答えが実装の詳細の多くを欠いていることを知っていますが、私はまだ自分のコードで実装に取り​​組んでいます。うまくいけば、akka-fsmについて少し読んで遊んだ後、この答えは理にかなっていますか？

于 2012-11-08T22:52:33.183 に答える
1

ミュータブルな状態を悪者扱いしないでください。それは SHARED ミュータブルな状態であり、ほとんどの問題を引き起こします。アクター内で変更可能な状態を共有する必要はありません。これは、常にactorRefsと対話し、アクターが一度に1つのメッセージのみを処理するためです(競合状態やその他の悪事はありません)。私が言っているのは、 a を使用しても問題varないということです (アクター内でいくつかの先物を生成し、それが を変異させない限り、varその後 SHARING 可変状態に戻るため)。FSM は @devnulled が提案したもう 1 つのソリューションですが、ユースケースではやり過ぎのように思えます。

于 2012-11-08T23:19:42.463 に答える