Dopo di che tipo di eccezioni / crash fa un'istanza Azure cloud eseguire riavvio?

Question

Per quanto mi ricordo, un'istanza di ruolo dovrebbe svolgere automaticamente un riavvio dopo un incidente / guasto. Al fine di verificare che il comportamento, ho scritto un'applicazione che impone un out-of-memory-eccezione e la mia domanda caduto. L'istanza ruolo non ha effettuato un riavvio, perché era ancora in esecuzione e ok -. L'istanza appena restartet il runtime .NET

Sto cercando di scoprire come un'istanza reagisce su diversi errori. Nel mio caso, il riavvio non era necessario. Che tipo di errori / eccezioni (che io possa far rispettare) causerebbe un riavvio completo di un esempio? Che tipo di errori / eccezioni avrebbero ucciso un'istanza per sempre?

Answer 1

L'unico motivo che causa un'istanza ruolo da riciclare (rinnovate) è quando il Esegui metodo di RoleEntryPoint uscite. Questo accade in genere quando si:

1. Run ( metodo), e
2. Avere un'eccezione non gestita nel codice del programma, che avrebbe causato il Esegui () metodo per uscire

Il tuo ruolo però sarebbe riciclare, ma piuttosto appendere, quando è stata attivata la raccolta IntelliTrace registri.

Il modello predefinito per un WebRole non ignorare Run () metodo , lasciando così l'implementazione di default, che è "Thread.Sleep (-1);". Non v'è alcuna (auto) evento che potrebbe causare il riciclaggio ruolo automatica di un WebRole. A meno che non si fa qualcosa nel vostro RoleEntryPoint, che causerebbe metodo Run per uscire. Questo riciclo automatico verifica solo con WorkerRole, che fanno implementare il metodo Run ().

UPDATE 1 (di tronchi con un commento, 1)

run-Methoded of a RoleEntryPoint faces an error

Non solo un errore, ma tale tipo di errore (cioè un'eccezione non gestita), quale il metodo Run () per uscire.

Inoltre, non si può semplicemente ignorare il Run () nella WebRole, becasue tua RoleEntryPoint descendat vive in un dominio diverso app (anche diverso processo) quindi l'applicazione web (in modo che non hanno alcuna idea sulle eccezioni della tua applicazione). Per saperne di più di hosting completi IIS e processo qui .

Quindi, per un ruolo Web appena dispone di un'applicazione Web di funzionalità completamente IIS 7.0 / 7.5, che non ha alcuna idea che questo IIS fa parte di una distribuzione Azure. Global.asax è il tuo posto per gestire gli errori di applicazione web non gestite in ASP.NET. Scopri questa domanda , la risposta di che fornisce un buon esempio per Application_Error () gestore .

Si potrebbe utilizzare il RequestRecycle metodo statico di tipo RoleEnvironment richiedere manualmente riciclaggio ruolo nel metodo Application_Error (). Tuttavia non vi consigliamo di farlo. Non vedo una buona pratica nel riavviare il server web a causa di un errore di applicazione. Si dovrebbe implementare una buona gestione delle eccezioni ed errori di strategia di registrazione, regolarmente esaminare i log di errore e intraprendere azioni per evitare errori crytical che richiederebbero riavvio del server.

Qual è il suo intento originale? Per capire quando un ruolo verrà automacitally riciclato, o per modellare la vostra applicazione in modo da riciclare automaticamente il tuo ruolo in caso di errore? Se si tratta di quest'ultimo, vi suggerisco di rivedere i requisiti aziendali / logica.

UPDATE 2

Non posso parlare dalla bocca di Neil, ma "fallimento istanza" è tutto ciò che può causare una VM in esecuzione da appendere. Istanza in Windows Azure è una macchina virtuale signle che il codice di host dell'applicazione (leggere questo post blog per explanaition dettagliate sul servizio Hosted, Ruolo, InstaNCE). L'applicazione viene eseguita in un sistema operativo basato su Windows Server. È una macchina virtuale. Può succedere di tutto - da un guasto hardware sull'host, ad un guasto del software / driver generico del sistema operativo guest. Non è necessario da essere il vostro codice. Quindi, nel caso in cui succede qualcosa che causerebbe una singola macchina virtuale di fallire - questo problema è gestito automaticamente dalla Azure Fabric di Windows. Se neccessary - il codice viene distribuito automaticamente a un'altra macchina virtuale. E questo avviene in automatico. Non nohting. Immaginate un HDD si rompe, o di un modulo di memoria brucia, o di un'interfaccia di rete non risponde - questi sono solo alcuni problemi semplici che potrebbero causare una VM in esecuzione al sicuro. Si tratta di un errore di istanza.

Un fallimento nel codice è qualcosa che si dovrebbe prendere cura di. Tutto il resto -. Controller di Windows Azure Fabric si prende cura di

UPDATE 3

1. Cosa succede ad un'applicazione asp.net in un WebRole se si verifica un'eccezione e non viene gestita? Sarà l'applicazione semplicemente appendere in un stato indefinito ( "rotto") fino a quando non vedo perché o sarà risolto dalla vm?

Questa domanda è del tutto fuori portata! Cosa succede ad un'applicazione asp.net in un account di hosting condiviso? O in on-premise IIS installazione? crash dell'applicazione per l'utente le cui azioni causato l'incidente. Il peggiore piscina caso di app di riciclo. Non ho mai visto una domanda di asp.net "appeso". Non esiste una cosa come "applicazione terminata asp.net" o "broken". Se si tratta di un errore generico che è causato durante l'avvio dell'applicazione o prima richiesta - l'applicazione non sarà mai in linea. Se è l'errore causato da qualche sequenza di azioni dell'utente - utente visualizzerà un messaggio di errore brutto e niente di più (a meno che non si dispone di gestore appropriato Application_Error () nel Global.asax penso che sia abbastanza spiegazioni per una domanda che non ha nulla a che fare. con Azure.

2. Si può pensare a un pezzo di codice .NET nella mia applicazione che potrebbe causare il crash di un ruolo di web tutto o non è possibile con codice gestito (a parte un bug sconosciuto in NET)?

Stai scherzando? Questo codice andrà in crash il vostro ruolo web e costringerà un riciclaggio:

RoleEnvironment.RequestRecycle()

La prego di accettare questa domanda, come io non credo che ci sia qualcosa che manca. In più ha le risposte a almeno altre 4 domande, aggiunte a quella originale.

FINALE

Non esiste una cosa come "uccidere l'istanza per sempre".