Ejemplo de integración Akka con proyecto java existente.

integration

Question

Si ya tengo una aplicación web java existente que usa spring y servlet container. ¿Cuál es la forma correcta de integrar Akka en él?

Al igual que voy a tener Actor1 y Actor2 que se comunican entre sí. ¿Cuál sería el punto de entrada para comenzar a utilizar a esos actores? (como: 1. ponerlo allí 2. cambiar configuración 3. obtener referencia al actor)

Encontré http://doc.akka.io/docs/akka/2.2-M3/general/configuration.html Pero el suyo no me proporciona un pegamento. Solo quiero obtener un ejemplo real de integración.

¿Hay algún ejemplo de integración simple?

EDITAR: la aplicación realiza una búsqueda, obtiene algunos datos del exterior y almacena la información en archivos.

La aplicación es bastante grande. Algunos componentes / objetos pueden dejar su propia vida, es decir, fuera de las solicitudes directas de los clientes, puede hacer que algunas cosas sean paralelas. Como algunos objetos singleton que tienen un estado mutable en él.

La cosa es que no sé exactamente dónde puedo aplicar Actores, lo estoy investigando. Pero lo que ya tengo son muchos bloques sincronizados aquí y allá.

Y, creo que ya es una especie de señal de que los actores podrían ser aplicados. (porque no estoy seguro, tal vez olvidé poner algo sincronizado y, por supuesto, no hay pruebas de integración)

Acerca de la configuración, simplemente no estoy seguro de si debo configurar algún application.conf para que Actrors / Akka viva allí ( ya que la documentación lo describe ).

Lo que veo:

@Component("someManager")
public class SomeManager {
 List<Some> something;  // mutable state, that why I use locks here.
 // methods: add(), delete(), update()  
}

Podría hacerlo SomeManagerActor

SomeManager se utiliza desde el controller . Por lo tanto, sería bueno tener un controlador de actor también? Quiero recibir comentarios sobre el onReceive ( onReceive ()).

Esto es algo discutible ... Esa es una razón más por la que necesito algún ejemplo .

Creo que puedo mejorar la aplicación deshaciéndome de todas las cosas synchronized/whait/notify , synchronized/whait/notify responsabilidades a los actores, utilizando mensajes como una forma de comunicación con / entre ellos.

O así, podría ser el actor que escriba en los archivos de propiedades :

EDITAR:

Por ejemplo, por ahora lo que encontré: para hacer que Actor1 envíe un mensaje a Actor2, utilizo un truco:

// somewhere in existing code
public void initActors() {

        ActorSystem system = ActorSystem.create(example");

        // initializing
        final ActorRef actor1 = system.actorOf(Props.create(Actor1.class), "actor1");

}

Actor1 tiene un método preStart() que se inicia tan pronto como obtengo una referencia a él (arriba). Y envía mensaje a Actor2:

@Override
public void preStart() {

Pero no estoy seguro de que sea bueno por qué inicializar a dos actores para que hagan su trabajo.

Answer 1

Me he encontrado con un problema similar.

Estoy de acuerdo en que hay pocos beneficios de agregar AKKA a la aplicación web simple con un pequeño número de usuarios.

Pero no creo que sea difícil adjuntar AKKA a la aplicación spring mvc existente. En caso de que su proyecto necesite escalar, puede envolver su capa @Service en actores. Por lo tanto, los @Controllers no necesitan estar dentro de los actores.

Aquí hay una presentación sobre la fusión de spring con akka: https://www.youtube.com/watch?v=fALUf9BmqYE

Código fuente para la presentación: https://github.com/jsuereth/spring-akka-sample/tree/master/src/main/java/org/springframework/samples/travel

Answer 2

Respondiendo a mi propia pregunta. Solo para compartir mis pensamientos, lo que se me ocurrió.

Si ya tenemos una aplicación web en funcionamiento basada en Servlets / Spring MVC, parece que a menudo no hay una buena razón para cambiar a Actors / AKKA (o introducir actores al sistema existente solo para piratearlo) si en nuestra aplicación:

• No tiene: Lógica de trabajadores de subprocesos , cuando las tareas se dividen en el fondo. (Generalmente, la aplicación web típica no tiene esto), como un cálculo largo y largo ( paralelismo ).
• Tenga: Si tenemos llamadas secuenciales: cuando un componente llama a otro, entonces eso llama a otro, donde las llamadas dependen entre sí: Al igual que los controladores llaman a Componente, el componente guarda algunos datos en alguna Lista (que es mutable, pero se sincroniza como Lista sincronizada).
• No tenga tiempo libre para reemplazar todos los controladores de Spring Controllers por Akka o usar servidores diferentes (no Tomcat) (no hay tantos gerentes / propietarios de productos que le permitan hacerlo)

Que es incorrecto tener Actores en este simple sistema:

• Tener toneladas de mensajes (clases que envuelven comandos a / desde actores) que vienen a través de los componentes en lugar de llamar a métodos generales (usando las ventajas de OPP, implementando interfaces, teniendo varias implementaciones, pero los actores generalmente son de final class ).

• Tener mensajes como una string , tampoco es una buena solución, ya que es difícil de depurar.

• En un sistema de este tipo (como el sitio de mvc), generalmente no hay tantas cosas para sincronizar (ya es bastante stateless ). Por lo general, hay 0..2 mutable shared data en cada Controlador / Componente. Lo que no es tan difícil de sincronizar (solo haga un hábito de sincronizar todo lo que es común y compartido en la parte superior de sus clases (para que los estados sean reconocibles / localizados). .

Cuando los Actores podrían ser utilizados para la aplicación existente. Los casos de uso pueden ser así:

• cuando tenemos una búsqueda de larga duración, eso pasa por varias fuentes (tipo de trabajador de subprocesos). Tener varios / pull de MasterActor -> SiteSearchActor (como se describió here para el cómputo PI ). El MasterActor tiene el resultado final. Donde SiteSearchActor calcula (busca en varios sitios) para varios clientes.
• O cuando tengamos alguna bifurcación de hilos, fuera de los servlets actuales.
• cuando estemos seguros / desciframos que nuestro sistema será utilizado por millones de clientes (incluso con lógica simple), deberíamos pensar con anticipación sobre la scalability y el performance (
  • Los actores son buenos: podemos delegar un trabajo de un actor a N-ones.
  • los actores protegen el tipo de procesador cuando trabajan con subprocesos (no se necesitan 10000 subprocesos para 10000 clientes , en la mayoría de los casos bastan con 4 subprocesos (la misma cantidad que el núcleo del procesador, digamos))

Pero en general estoy de acuerdo con this artículo sobre la concurrency y el parallelism . Si tengo la oportunidad de hacer una aplicación desde cero, usaría Akka sin el contenedor Servlets y me preocuparía de alguna manera sobre los mensajes (clases de comando) y OOP cuando sea necesario (no hay tantos OOP en aplicaciones web generales. Debería diga de todos modos. Pero nadie impide mantener alguna lógica de negocios en modo OOP , los actores solo son un pegamento de comunicación). Eso es mucho mejor / más simple que usar JMS, por ejemplo.

Pero como dije:

Actores / Akka es bueno para:

1. Servicios / Controladores (en lugar de Servlet / SpringMVC)
2. Trabajar con hilos como la lógica.
3. Especialmente para proyectos desde cero (cuando la infraestructura actual no lo convierte en una barrera para aplicar el actor uno).

La única pregunta que tengo ahora es la performance comparison . Suponiendo que sabemos que:

tener 10000 hilos en una JVM con sincronizados y bloqueos para datos mutables compartidos en nuestros Controladores / Servicios MVC puede ser muy malo desde el punto de vista del rendimiento. Dado que hay muchos bloqueos posibles, subprocesos que son concurrentes (un rival o un competidor para un recurso de conexión) entre sí.

Si tenemos el mismo escenario para AKKA / Servlets con N (actores, donde N mucho más que 1000), lo más probable es que tengamos un rendimiento mucho mejor (ya que nadie bloquea a nadie, excepto la cola en sí, no hay necesidad de cambiar de un hilo) a otro).

Pero incluso si tiene un sistema con 10000 clientes para la aplicación basada en Servlet (modelo de subproceso), con 100 clientes podría funcionar muy bien. Y si tenemos un grupo de conexiones (ciertamente tenemos), hace el mismo trabajo que la cola (bandeja de entrada) del Actor, programando al cliente para que tenga acceso a algún servicio. Podría mejorar nuestro rendimiento en K veces (donde K es mucho más que si no tuviéramos pool, dejando que el hilo se bloquee desesperadamente).

La pregunta es:

¿Es una buena razón para no aplicar AKKA para una aplicación basada en servlet existente?

Tomando esto como un argumento: incluso tener un sistema antiguo en Servlers, con un connection pool puede mejorar el rendimiento a un buen nivel. Y este nivel, lo más probable, podría ser lo suficientemente bueno para NO aplicar AKKA a la aplicación Servlet existente, como intentar cambiar el modelo de servlet (que se supone que es malo en comparación con los controladores en la parte superior de AKKA).

¿Tiene sentido pensar así?

Considere que la conexión es un tipo de INBOX (como en AKKA) que programa los comandos (conexión).

Incluso si el modelo de Servlets es incorrecto (tener que lidiar con los bloqueos en el subproceso de resto (activo) que se crean por la conexión que proviene del grupo de conexiones).

Podría ser lo suficientemente bueno con el conjunto de conexiones, que se olvida al comparar akka con cosas basadas en servlets. Todavía podemos ajustar nuestra aplicación, cambiando MAX-CONNECTION en el grupo de conexiones. Y por lo general, hacemos todo lo posible para que la aplicación sea sin estado, por lo que, en la mayoría de los casos, no sincronizamos nada.

Pero, por supuesto, es malo tener un solo grupo de conexiones para toda la aplicación. Si se compara con los Actores, cada actor tiene cada grupo de conexión (buzón) y cada actor puede ser responsable de aceptar la solicitud HTTP. Ese modelo sin duda mejor.

PS En la mayoría de los casos ** Los Future ** s son lo suficientemente buenos. Los actores son buenos si usted quiere que la "seguridad" almacene el estado en él (eso lo diferencia básicamente del futuro).

ACTUALIZACIÓN: Algunas personas creen que es una mala idea usar Actores. Lo que es bueno es: un enfoque funcional puro o algo que scalaz ya proporciona (así como también Haskell , supongo), pero no para llamadas remotas todavía.