2009-05-10 16 views
7

Jaki jest dobry sposób na utrzymanie stanu podczas restartowania awarii?Jak mogę przywrócić stan procesu po awarii?

Mam superwizora w aplikacji OTP, który obserwuje kilka "podsystemów" gen_servers.

Na przykład, jeden jest podsystemem "pogodowym", który generuje nowy stan pogody co 15 minut i obsługuje zapytania dotyczące aktualnego stanu pogody. (Pomyśl o stoliku z lemoniadą)

Jeśli ten gen_server się zawiesza, chcę go zrestartować, ale powinien zostać uruchomiony ponownie z najnowszym stanem pogody, a nie jakimś arbitralnym stanem zakodowanym w init(). Nie byłoby sensu, by stan symulacji nagle przeszedł z "burzy gradowej" na "przyjemny i przewiewny" właśnie z powodu wypadku.

Waham się używać mnesii lub ETS do przechowywania stanu po każdej aktualizacji ze względu na dodatkową złożoność; Czy istnieje prostszy sposób?

Odpowiedz

4

Tak długo, jak to tylko musi być podczas uruchamiania, sugeruje użycie ETS. Wartość jest znacznie większa niż złożoność. Interfejs API jest prosty i jeśli pracujesz z nazwanymi tabelami, dostęp jest prosty. Musisz tylko utworzyć tabelę przed uruchomieniem serwera gen_ przez przełożonego.

Dwa - bardziej skomplikowane - alternatywy:

  • Zbuduj para procesów, jeden za zadanie do wykonania, jeden dla utrzymania stanu. Z powodu prostoty drugiego byłby naprawdę niezawodny.
  • Prawdziwą głupią może być wymiana specyfikacji dziecka z opiekunem, z aktualnym stanem jako argumentem za każdym razem, gdy zmienia się stan. (uśmiech) Nie, tylko żartuję.
2

czy jest łatwiejszy sposób?

gdy proces zmarł wysyła wiadomość do przełożonego, który zawierającej Stan procesu, więc można użyć tej wartości do przechowywania w przełożonego (w mnesia lub stanu przełożonego) i gdy serwer rozpocznie (w init,) go musisz wysłać połączenie synchronizacyjne do nadzorcy, aby uzyskać wartość State. Nie mam prawdziwego przykładu, ale mam nadzieję, że ma to sens.

W każdym razie nie widzę problemu z przechowywaniem stanu w stanie mnesia.

Przepraszam mój angielski :)

+1

Osoba nadzorująca powinna zawierać mniej informacji logicznych, jak to tylko możliwe i ponosić odpowiedzialność tylko za ponowne uruchomienie. Pojedynczy błąd w tej logice może doprowadzić do awarii całego poddrzewa. –

Powiązane problemy