c# - una - ¿Cómo manejar las excepciones dentro del actor?

tipos de excepciones en c#

Question

¿Hay un patrón estándar para lidiar con las excepciones dentro de los actores en Akka.NET?

Vi algunos patrones para crear supervisores, pero parece que la SupervisorStrategy es una forma de lidiar con cosas que el actor no puede resolver.

Tengo un actor que recibe muchos datos y necesita almacenarlos en un servidor externo. La base de datos externa puede ser inalcanzable. Si es así, es posible que el servidor se esté reiniciando o que la red esté inactiva. No necesito reiniciar el actor ni nada, solo quiero notificar al remitente con información sobre lo que está sucediendo, para que pueda guardar el mensaje en el disco y reprogramarlo para más adelante.

El remitente no es un padre de este actor que se conecta a la base de datos. ¿Debo crear un supervisor solo para manejar esto también? ¿O debería encapsular mis controladores de recepción en los bloques try / catch y simplemente usar Tell para notificar a los remitentes con una respuesta personalizada como si fuera un mensaje normal?

Sé que hay una clase de Failure , pero no estoy seguro de si debo usar eso para esta situación.

Answer 1

Sí hay. En primer lugar, siempre delegue el trabajo peligroso a los actores infantiles, deles todos sus cuchillos, lanzallamas y demás. Si chocan y se queman, su estado sigue intacto y puede engendrar nuevos hijos.

Así que para el ejemplo de base de datos inalcanzable; Gira un actor de comunicación DB. A continuación, puede permitir que este actor tenga dos estados, DB arriba y DB abajo, esto puede ser modelado como un FSM o mediante el uso de Become / Unbecome .

Entonces, cuando llega un mensaje y se solicita una consulta de base de datos, si las cosas explotan, el actor comunicador de base de datos se pone automáticamente en el estado de bajada de datos. Si se recibe alguna consulta en el estado DB-Down, puede responder de inmediato con un evento de Failure .

Entonces, ¿cómo vamos de DB-Down a DB-Up de nuevo? El actor DB-Communicator puede hacer ping a sí mismo utilizando ScheduleOnce , por ejemplo, pasar un mensaje "CheckDBStatus" cada x segundos. Cuando se recibe el mensaje CheckDBStatus, verifica si la base de datos vuelve a estar activa, y si es así, vuelve al estado DB-Up.

De esta manera, no inundará su base de datos en situaciones en las que no pueda responder debido a una carga alta, agregar más carga en ese caso solo empeorará las cosas. Así que este tipo de interruptor de circuito evitará que eso suceda.

Así que en resumen:

En estado DB-Up:

Si se recibe un mensaje DBQuery, intente ejecutar la consulta y envíe la respuesta. Si las cosas explotan, vaya directamente al estado DB-Down y responda con un evento de falla.

En el estado DB-Down: si se recibe un mensaje DBQuery, responda con un evento de Failure directamente sin tocar el DB. Hágase un ping cada x segundos para ver si el DB está activo y vuelva al estado DB-Up si es posible.

En este escenario, no usaría ningún supervisor para transitar por el estado, el intento normal / captura sería suficiente para lidiar con esto.

Espero que esto se aclare.