java - Akka: ¿Es necesaria la limpieza de los actores creados dinámicamente cuando han terminado?

resource-cleanup

Question

He implementado un sistema Actor utilizando Akka y su API Java UntypedActor. En él, un actor (tipo A) inicia a otros actores (tipo B) dinámicamente a pedido, utilizando getContext().actorOf(...); . Esos actores B harán algunos cálculos que a A realmente ya no les importan. Pero me pregunto: ¿es necesario limpiar a esos actores del tipo B cuando hayan terminado? ¿Si es así, cómo?

• ¿Al hacer que los actores B llamen a getContext().stop(getSelf()) cuando terminan?
• Al hacer que los actores B llamen a getSelf().tell(Actors.poisonPill()); cuando se hacen? [esto es lo que estoy usando ahora].
• ¿Al no hacer nada?
• ¿Por ...?

Los documentos no son claros en esto, o lo he pasado por alto. Tengo un conocimiento básico de Scala, pero las fuentes Akka no son exactamente cosas de nivel de entrada ...

Answer 1

Además de la respuesta de Roland Kuhn, en lugar de crear un nuevo actor para cada solicitud, puede crear un conjunto predefinido de actores que comparten el mismo despachador, o puede usar un enrutador que distribuya las solicitudes a un grupo de actores.

El enrutador de grupo de equilibrio , por ejemplo, le permite tener un conjunto fijo de actores de un tipo particular que comparte el mismo buzón:

akka.actor.deployment {
/parent/router9 {
router = balancing-pool
nr-of-instances = 5
}
}

Lea la documentación sobre dispatchers y sobre routing para más detalles.

Answer 2

Estaba perfilando (visualvm) una de las aplicaciones de muestra de clúster de la documentación de AKKA y veo una recolección de basura que limpia los actores por solicitud durante cada GC. No se puede entender completamente la recomendación de matar explícitamente al actor después de su uso. Mi sistema de actores y actores son administrados por el contenedor SPRING IOC y utilizo actores y productores directos de Spring Extension para crear actores. El actor " agregador " está recolectando basura en cada GC, yo monitoreé el número de instancias en VM visual.

@Component
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public class StatsService extends AbstractActor {
private final LoggingAdapter log = Logging.getLogger(getContext().getSystem(), this);
@Autowired
private ActorSystem actorSystem;
private ActorRef workerRouter;
@Override
public void preStart() throws Exception {
System.out.println("Creating Router" + this.getClass().getCanonicalName());
workerRouter = getContext().actorOf(SPRING_PRO.get(actorSystem)
.props("statsWorker").withRouter(new FromConfig()), "workerRouter");
super.preStart();
}
@Override
public Receive createReceive() {
return receiveBuilder()
.match(StatsJob.class, job -> !job.getText().isEmpty(), job -> {
final String[] words = job.getText().split(" ");
final ActorRef replyTo = sender();
final ActorRef aggregator = getContext().actorOf(SPRING_PRO.get(actorSystem)
.props("statsAggregator", words.length, replyTo));
for (final String word : words) {
workerRouter.tell(new ConsistentHashableEnvelope(word, word),
aggregator);
}
})
.build();
}
}

Answer 3

Lo que estás describiendo son actores de un solo propósito creados por "solicitud" (definidos en el contexto de A), que manejan una secuencia de eventos y luego se realizan, ¿no? Eso está absolutamente bien, y tiene razón al cerrarlos: si no lo hace, se acumularán con el tiempo y se encontrará con una pérdida de memoria. La mejor manera de hacerlo es la primera de las posibilidades que menciona (la más directa), pero la segunda también está bien.

Un poco de antecedentes: los actores se registran dentro de sus padres para poder ser identificables (por ejemplo, se necesitan para la comunicación remota pero también en otros lugares) y este registro evita que se recojan de basura. OTOH, cada padre tiene el derecho de acceder a los hijos que creó, por lo tanto, no tiene sentido la terminación automática (es decir, por Akka), en su lugar requiere un cierre explícito en el código de usuario.

Answer 4

Los actores por defecto no consumen mucha memoria. Si la aplicación pretende usar el actor b más adelante, puedes mantenerlos con vida. Si no, puedes apagarlos a través de poisonpill. Mientras sus actores no tengan recursos, dejar un actor debería estar bien.