score:0

2) The body of your case can contain more than one statement:

def receive = {

  case "Update Price" => 
    context.actorSelection("akka://system/user/positionActor")  ! "Update Position"
    log.info("Price updated!)
  case _ => log.info("Received an unknown message")

}

1) It depends on the logic of your application, if you see PriceActor as the logical parent or supervisor of PositionActor then yes. Otherwise, it's better to create it in your main and pass it as a constructor argument to PriceActor:

val positionActor = system.actorOf(Props[PositionActor], "positionActor")
val priceActor = system.actorOf(Props(classOf[PriceActor], "priceActor", positionActor))

class PriceActor(positionActor: ActorRef) extends Actor

I think it's cleaner than looking up the actor in the context.

score:0

I would not nest one Actor subclass within another (probably ever—but tomorrow I could encounter the situation that leads me to do it anyway…). Doing so would make the inner one a dependent type of the outer one. Instances of the inner one could not exist independent of an instance of the outer one. Given the restrictions on Actor subclass instantiations, it might be difficult to set up the actor system you need with that arrangement.

I'm not quite sure what you're asking in question (2). You can simply:

def receive = {
  case "Update Price" =>
    log.info("Updating price")
    positionActor ! "Update Position"
  …
}

By the way, I hope you're using proper message types and not String for your inter-actor messaging and what you show here is for illustrative purposes only. It seems that must be the case since your messages don't carry any parameters (price or position). While there are cases where messages are constants (heartbeats, e.g.), in any system at least some of them bear some kind of information content other than the message value or type itself.


Related Query

More Query from same tag