scala - actors - akka actor watch

¿Debo volver a utilizar el mismo Akka ActorSystem o solo puedo crear uno cada vez que lo necesite?

Question

Akka 2.x requiere muchos comandos para hacer referencia a un ActorSystem . Entonces, para crear una instancia de un actor MyActor puedes decir:

val system = ActorSystem()
val myActor = system.actorOf(Props[MyActor])

Debido a la frecuente necesidad de un ActorSystem : muchos ejemplos de código omiten la creación del código y suponen que el lector sabe de dónde viene una variable del system .

Si su código produce actores en diferentes lugares, podría duplicar este código, posiblemente creando instancias adicionales de ActorSystem , o podría intentar compartir la misma instancia de ActorSystem refiriéndose a algún elemento global o pasando el ActorSystem .

La documentación de Akka proporciona una descripción general de los sistemas de actores bajo el título "Actor Systems", y hay documentación de la clase ActorSystem . Pero ninguno de estos ayuda mucho explicando por qué un usuario de Akka no puede confiar únicamente en Akka para gestionar esto bajo el capó.

Pregunta (s)

• ¿Cuáles son las implicaciones de compartir el mismo objeto ActorSystem o crear uno nuevo cada vez?

• ¿Cuáles son las mejores prácticas aquí? Pasar por todo un ActorSystem todo el tiempo parece sorprendentemente pesado.

• Algunos ejemplos le dan un nombre al ActorSystem("MySystem") : ActorSystem("MySystem") otros simplemente llaman a ActorSystem() . ¿Qué diferencia hace esto, y qué pasa si usa el mismo nombre dos veces?

• ¿ akka-testkit que compartas un ActorSystem común con el que pasas al constructor de TestKit ?

Answer 1

Aquí hay algunos materiales que pueden ser útiles para comprender "¿Por qué el documento siempre sugiere utilizar un ActorSystem para una aplicación lógica"?

1. La parte más pesada de un ActorSystem es el despachador. Cada ActorSystem tiene al menos uno. El despachador es el motor que hace funcionar a los actores. Para hacer que funcione, necesita subprocesos (generalmente obtenidos de un grupo de subprocesos). El despachador predeterminado utiliza un grupo de subprocesos de unión de horquilla con al menos 8 subprocesos.

2. Hay instalaciones compartidas, como los actores guardianes, el flujo de eventos, el programador, etc. Algunos de ellos están en el espacio de usuario, algunos son internos. Todos ellos deben ser creados e iniciados.

3. Un ActorSystem con un grupo de subprocesos configurado para los números de núcleos debería dar los mejores resultados en la mayoría de los casos.

4. Aquí el documento menciona la aplicación lógica, prefiero considerar la aplicación de bloqueo o no bloqueo. De acuerdo con la configuración del despachador, un ActorSystem es para una configuración. Si la aplicación es para la misma lógica, un ActorSystem debería ser suficiente.

Aquí hay una discussion , si tiene tiempo, puede leerlo. Discuten mucho, ActorSystem, local o remoto, etc.

Answer 2

La creación de un ActorSystem es muy costosa, por lo que debe evitar crear una nueva cada vez que la necesite. Además, tus actores deberían correr en el mismo ActorSystem, a menos que haya una buena razón para que no lo hagan. El nombre de ActorSystem también forma parte del camino hacia los actores que se ejecutan en él. Por ejemplo, si creas un actor en un sistema llamado MySystem , tendrá una ruta como akka://MySystem/user/$a . Si estás en un contexto de actor, siempre tienes una referencia al ActorSystem. En un Actor puedes llamar a context.system . No sé qué espera akka-testkit, pero podrías echar un vistazo a las pruebas de akka.

Entonces, para resumir, siempre debe usar el mismo sistema, a menos que haya una buena razón para no hacerlo.