Come gestire le eccezioni all'interno dell'attore?

Question

Esiste un modello standard per gestire le eccezioni all'interno degli attori in Akka.NET?

Ho visto alcuni modelli per creare supervisori, ma sembra che lo SupervisorStrategy sia un modo per gestire le cose che non possono essere risolte dall'attore.

Ho un attore che riceve molti dati e deve memorizzarlo in un server esterno. Il database esterno potrebbe essere irraggiungibile. Se lo è, il server potrebbe essere riavviato o la rete potrebbe essere inattiva. Non ho bisogno di riavviare l'attore o altro, voglio solo notificare al mittente alcune informazioni su ciò che sta accadendo, in modo che possa mantenere il messaggio su disco e riprogrammare per dopo.

Il mittente non è un genitore di questo attore che si collega al database. Devo creare un supervisore solo per gestire anche questo? O dovrei incapsulare i miei gestori di ricezione nei blocchi try/catch e usare semplicemente Tell per notificare ai mittenti una risposta personalizzata come se fosse un messaggio normale?

So che esiste una classe Failure, ma non sono sicuro di doverlo usare per questa situazione.

Answer 1

Sì, c'è. Prima di tutto, delegare sempre il lavoro pericoloso agli attori bambini, dare loro tutti i coltelli, il lanciafiamme e così via. se si bloccano e bruciano, il tuo stato è ancora intatto e puoi generare nuovi figli.

Quindi per l'esempio di database non raggiungibile; Inserire un attore di comunicazione DB. Puoi quindi lasciare che questo attore abbia due stati, DB up e DB down, questo può essere modellato come un FSM o usando Become/Unbecome.

Quindi, quando arriva un messaggio e richiede una query DB, se le cose esplodono, l'attore del comunicatore DB si inserisce automaticamente nello stato DB-Down. Se una query viene ricevuta nello stato DB-Down, è possibile rispondere immediatamente con un evento Failure.

Quindi, come passare di nuovo da DB-Down a DB-Up? L'attore DB-Communicator può eseguire il ping con sé utilizzando ScheduleOnce, ad es. passare un messaggio "CheckDBStatus" ogni x secondi. Quando viene ricevuto il messaggio CheckDBStatus, si controlla se DB è di nuovo attivo e, in caso affermativo, si ritorna allo stato DB-Up.

In questo modo, non si allagherà il DB in scenari in cui non è in grado di rispondere a causa del carico elevato, aggiungendo più carico in tal caso peggiorerà solo le cose. Quindi questo tipo di interruttore impedirà che ciò accada.

Così, in breve:

In DB-up dello stato:

Se viene ricevuto un messaggio DBQuery, provare a eseguire la query, e inviare la risposta. se le cose esplodono, andare direttamente allo stato DB-Down e rispondere con un evento di errore.

In stato DB-Down: se viene ricevuto un messaggio DBQuery, rispondere direttamente con un evento Failure senza toccare il DB. Ping ogni x secondi per vedere se il DB è attivo e, se possibile, ripristinare lo stato DB-Up.

In questo scenario, non si utilizzerebbe alcun supervisore per il transito dello stato, normale tentativo/cattura sarebbe sufficiente per gestire questo.

Spero che questo chiarisca le cose.