2012-05-22 2 views
9

Come posso verificare se un attore remoto, per il quale ho ottenuto un attoreRef tramite actorFor, è vivo? Qualsiasi riferimento alla documentazione sarebbe apprezzato. Sto usando Akka da Scala.Verifica se l'attore Akka remoto è disponibile

Ho visto riferimenti a supervisori e deathwatch, ma non sento davvero che il mio caso d'uso abbia bisogno di macchinari così pesanti. Voglio solo che il mio cliente controlli se il master è attivo usando un percorso noto e se invia un messaggio che presenta se stesso. Se il master non è attivo, allora dovrebbe aspettare un po 'e riprovare.

Aggiornamento 2: I suggerimenti sono che uso solo un test di ping pong per verificare se è vivo. Capisco che questo è qualcosa di simile a

implicit val timeout = Timeout(5 seconds) 
val future = actor ? AreYouAlive 
try{ 
    Await.result(future, timeout.duration) 
}catch{ 
    case e:AskTimeoutException => println("It's not there: "+e) 
} 

penso sono stato confuso dalla presenza di eccezioni nei registri, cui restano ora. Per esempio.

  • Errore: java.net.ConnectException: Connection refused
  • Errore: java.nio.channels.ClosedChannelException: null

Forse questo è solo come funziona e mi devono accettare gli errori/avviso nei registri piuttosto che cercare di proteggere contro di loro?

+0

Che dire semplicemente inviando il messaggio "Ping" all'attore (ovviamente deve gestirlo) e attendere 'Pong' per un po 'di tempo? –

+0

Buona domanda, ho aggiunto l'aggiornamento. – Pengin

+0

No, non dovresti aspettarti operazioni 'tell' /'! 'Per generare un'eccezione perché la gestione del messaggio avviene in modo asincrono. Invece dovresti inviare un 'Ping' e ** wait ** per 'Pong' per un po 'di tempo. Nel tuo attore remoto aggiungi semplicemente: 'case _: Ping => mittente! Pong' e in quello locale: 'remoteActor? Ping' –

risposta

7

Basta inviarlo messaggi. La sua macchina potrebbe diventare irraggiungibile il nanosecondo dopo aver inviato comunque il tuo messaggio. Se non si ottiene alcuna risposta, è molto probabile che sia morto. C'è un ampio capitolo su questo nei documenti: http://doc.akka.io/docs/akka/2.0.1/general/message-send-semantics.html

+0

Grazie. Penso di averlo capito ora. Semplicemente confuso sul fatto che ci siano ancora errori nel registro, ma forse questo è normale (domanda aggiornata). – Pengin

+0

Sì, Akka registra tutti gli errori di rete. È possibile collegare il proprio registratore per ignorare quelli se lo si desidera. –

+0

Viktor, voglio davvero registrare un gestore personalizzato, diciamo uno che restituisce il messaggio al mittente. Registrare grandi quantità di merda ma non farmi sapere che c'era un errore è uno schema difficile da apprezzare. –

1

Non si dovrebbe mai presumere che la rete sia disponibile. Il nostro architetto qui dice sempre che ci sono due concetti chiave che entrano in gioco nella progettazione di sistemi distribuiti.

Essi sono:

  • Timeout
  • Riprova

messaggi dovrebbero 'timeout' se non lo fanno dopo un periodo di tempo x e quindi è possibile ripetere il messaggio. Con il timeout non è necessario preoccuparsi dell'errore specifico: solo la risposta al messaggio è fallita. Per gli alti livelli di disponibilità, si consiglia di prendere in considerazione l'utilizzo di strumenti come zookeeper per gestire il monitoraggio di clustering/disponibilità. Vedi ad esempio l'elezione del leader: http://zookeeper.apache.org/doc/trunk/recipes.html