Para evitar OOM, estoy limitando el tamaño del buzón de algunos de mis actores Akka 1.1.3 con un despachador personalizado compartido. Por ejemplo:Manejar Akka buzón delimitado por el actor MessageQueueAppendFailedException
object Static {
val dispatcher = Dispatchers.newExecutorBasedEventDrivenWorkStealingDispatcher(
"customDispatcher",
1000,
BoundedMailbox(capacity = 10)
)
}
class MyActor extends Actor {
self.dispatcher = Static.dispatcher
...
}
me gustaría reaccionan al buzón de correo desbordando por lo que puedo mensaje de los productores aguas arriba para hacer una pausa (nota: se ve tristemente como actor.stop(), esperar y actor.start() lanzará una ActorStartException). Alguna pérdida de datos es aceptable entre la cola que se llena y la cola que drena un poco.
capítulo de Akka en Dispatchers dice
al intentar enviar un mensaje al actor que arrojará un MessageQueueAppendFailedException (“BlockingMessageTransferQueue transferencia Tiempo de espera agotado”) si el mensaje no se puede añadir al buzón dentro el tiempo especificado por pushTimeout.
¿Dónde puedo detectar esta excepción?
La documentación lo hace parecer como si tuviera que envolver cada myActor ! message en un try/catch. ¿Está bien? Realmente me gustaría centralizar su manejo. ¿Puede mi Supervisor quizás interceptarlo y ejecutar mi controlador?
¿Cuál es el propósito de inspeccionarlo? –
No estoy seguro si esto se aplicaría a su caso específico, pero si se encuentra con situaciones en las que corre el riesgo de desbordar buzones, puede considerar un diseño "pull" donde sus actores consumidores soliciten trabajo a un productor en lugar del productor enviando spam a tus consumidores. –
@Viktor es tomar medidas previas, específicamente para detener a los consumidores (voy a agregar esto a la pregunta). Dan tiene razón, y definitivamente consideraré el modelo de atracción. Sin embargo, me gustaría hacer esto ahora mismo con pocas modificaciones, y la pérdida de datos es aceptable. – Bluu