actores Scala - peores prácticas?

Question

Me siento un poco insegura sobre el uso de actores en Scala. He leído la documentación acerca de cómo hacer las cosas, pero supongo que también necesitaría algunos no lo hacen normas para sentirse libre de usarlos. Creo que me temo que voy a utilizar de una manera equivocada, y ni siquiera se dará cuenta ella.

¿Se le ocurre algo, que, si se aplica, daría lugar a romper los beneficios que aportan los actores Scala, o incluso resultados erróneos?

Answer 1

• Evitar !? siempre que sea posible. Usted conseguir un sistema bloqueado!

• Siempre envíe un mensaje de un hilo Actor-subsistema. Si esto significa la creación de un Actor transitoria a través del método Actor.actor que así sea:

  case ButtonClicked(src) => Actor.actor { controller ! SaveTrade(trdFld.text) }

• Añadir un "cualquier otro mensaje" manejador a las reacciones de su agente. De lo contrario es imposible averiguar si va a enviar un mensaje al actor equivocado:

  case other => log.warning(this + " has received unexpected message " + other

• No utilice Actor.actor para sus actores principales, sublcass Actor lugar. La razón de esto es que es solamente por subclases que puede proporcionar un método toString sensata. Una vez más, la depuración de los actores es muy difícil si los registros están llenos de declaraciones como:

  12:03 [INFO] Sending RequestTrades(2009-10-12) to scala.actors.Actor$anonfun$1

• Documento de los actores en el sistema, indicando explícitamente qué mensajes van a recibir y precisa cómo deben calcular la respuesta. Usando actores resultados en la conversión de un procedimiento estándar (normalmente encapsulado dentro de un método) para convertirse propagación lógica a través de reacciones múltiples del actor. Es fácil perderse sin una buena documentación.

• Siempre asegúrese de que puede comunicarse con su agente fuera de su bucle react para encontrar su estado. Por ejemplo, siempre me declaro un método que se invoca a través de un MBean que se parece al siguiente fragmento de código. De otro modo, puede ser muy difícil decir si su actor está en funcionamiento, se ha apagado, tiene una gran cola de mensajes, etc.

.

def reportState = {
  val _this = this
  synchronized {
    val msg = "%s Received request to report state with %d items in mailbox".format(
                   _this, mailboxSize) 
    log.info(msg)
  }
  Actor.actor { _this ! ReportState }
}

• Enlace sus actores juntos y utilizar trapExit = true -. De lo contrario puede fallar en silencio que significa que su programa no está haciendo lo que creo que es y será probablemente salir de la memoria como los mensajes permanecen en el buzón del actor

• Creo que algunas otras opciones interesantes alrededor de marca que se tomen decisiones utilizando actores se han destacado aquí y aquí

Answer 2

Sé que esto no responde realmente a la pregunta, pero al menos debe tener corazón en el hecho de que la concurrencia basado en mensajes es mucho menos propenso a errores extraño que la concurrencia a base de memoria compartida-hilo.

supongo que usted ha visto las directrices actor en Programación en Scala , pero para el registro:

• Los actores no deben bloquear al procesar un mensaje. Donde es posible que desee bloquear el intento de organizar para obtener un mensaje más tarde en su lugar.
• Uso react {} en lugar de receive {} cuando sea posible.
• Comunicarse con los actores sólo a través de mensajes.
• Prefiero mensajes inmutables.
• Haga autónomo de mensajes.