Dopo quale tipo di eccezioni/crash viene eseguita un'istanza di Azure Cloud viene riavviata?

Question

Per quanto ricordo, un'istanza di ruolo dovrebbe eseguire automaticamente un riavvio dopo un arresto anomalo/errore. Per testare questo comportamento, ho scritto un'applicazione che applica un'eccezione out-of-memory e la mia applicazione si è bloccata. L'istanza del ruolo non ha eseguito un riavvio, perché era ancora in esecuzione e ok, l'istanza ha appena riavviato il runtime .NET.

Sto cercando di scoprire come un'istanza reagisce a diversi errori. Nel mio caso, un riavvio non era necessario. Quale tipo di errori/eccezioni (che posso applicare) causerebbe il riavvio completo di un'istanza? Quale tipo di errori/eccezioni ucciderebbe un'istanza per sempre?

Answer 1

L'unico motivo per cui un'istanza del ruolo deve essere riciclata (riavviata) è quando si esce dal metodo RunRoleEntryPoint. Questo accade in genere quando si: il metodo

1. Overrided Run(), e
2. Avete un'eccezione non gestita nel codice del programma, che causerebbe il metodo Run() per uscire

Il vostro ruolo però sarebbe riciclare , ma piuttosto bloccati, quando hai abilitato la raccolta dei registri di IntelliTrace.

Il modello predefinito per un WebRole non sovrascrive il metodo Run(), lasciando quindi l'implementazione predefinita, che è "Thread.Sleep (-1);". Non esiste un evento (automatico) che possa causare il riciclaggio automatico dei ruoli di un WebRole. A meno che tu non faccia qualcosa nel tuo RoleEntryPoint, ciò causerebbe l'uscita del metodo Run. Questo riciclaggio automatico avviene solo con WorkerRole, che implementa il metodo Run().

UPDATE 1 (tronchi con commentare 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 è possibile eseguire l'override di Run() nella tua WebRole, perché il tuo RoleEntryPoint descendat risiede in diversi domini di app (anche diversi processi) della tua applicazione web (quindi non avrà idea delle eccezioni dell'applicazione) . Maggiori informazioni sull'hosting e sull'elaborazione di IIS completi here.

Quindi, per un ruolo Web è sufficiente un'applicazione Web in tutte le funzionalità di IIS 7.0/7.5, che non ha idea che questo IIS sia parte di una distribuzione di Azure. Global.asax è il posto dove gestire gli errori di applicazione Web non gestiti in ASP.NET. Controlla this question, la cui risposta fornisce un buon esempio per il gestore Application_Error().

È possibile utilizzare il metodo statico di tipo RoleEnvironment RequestRecycle per richiedere manualmente il riciclaggio del ruolo nel metodo Application_Error(). Comunque non ti consiglio di farlo. Non vedo una buona pratica nel riavvio del server Web a causa di un errore dell'applicazione. È necessario implementare una buona gestione delle eccezioni e una strategia di registrazione degli errori, esaminare regolarmente i registri degli errori e intraprendere azioni per evitare errori critici che richiederebbero il riavvio del server.

Qual è il tuo intento originale? Per capire quando un ruolo verrà riciclato automaticamente, o per modellare la tua applicazione in modo da riciclare automaticamente il tuo ruolo in caso di errore? Se è quest'ultimo, ti suggerisco di rivedere le tue esigenze/logiche di business.

UPDATE 2

Non posso parlare dalla bocca di Neil, ma "fallimento esempio" è tutto ciò che può causare una VM in esecuzione da appendere. L'istanza in Windows Azure è una macchina virtuale signle che ospita il codice dell'applicazione (leggi this blog post per spiegazioni dettagliate su servizio, ruolo, istanza in hosting). L'applicazione viene eseguita in un sistema operativo basato su Windows Server. È una macchina virtuale. Qualsiasi cosa potrebbe accadere, dall'errore hardware sull'host, a un errore software/driver generico del sistema operativo guest. Non è necessario essere il tuo codice. Quindi, nel caso in cui succeda qualcosa che potrebbe causare il fallimento di una singola VM, questo problema viene gestito automaticamente da Windows Azure Fabric. Se necessario, il codice verrà automaticamente distribuito su un'altra macchina virtuale. E questo accade automagicamente. Non fai nulla. Immagina un disco fisso si rompe, o un modulo di memoria si brucia, o un'interfaccia di rete smette di rispondere - questi sono solo alcuni semplici problemi che potrebbero causare il fallimento di una VM in esecuzione. Questo è un errore di istanza.

Un errore nel codice è qualcosa di cui dovresti aver cura. Tutto il resto: il controller Windows Azure Fabric si occupa di.

UPDATE 3

1. Cosa accade a un'applicazione asp.net in WebRole se si verifica un'eccezione e non viene gestita? L'applicazione si bloccherà in uno stato indefinito ("interrotto") finché non lo cerco o sarà terminato dal vm?

Questa domanda è totalmente fuori portata! Cosa succede a un'applicazione asp.net in un account di hosting condiviso? O nell'installazione di IIS in loco? Crash dell'applicazione per l'utente le cui azioni hanno causato l'arresto anomalo. Il caso peggiore riciclo di app pool. Non ho mai visto un'applicazione asp.net "appesa". Non esiste una cosa come "un'applicazione asp.net terminata" o "interrotta". Se si tratta di un errore generico causato durante l'avvio dell'applicazione o la prima richiesta, l'applicazione non sarà mai online. Se si tratta di un errore causato da una sequenza di azioni dell'utente, l'utente vedrà un brutto messaggio di errore e nient'altro (a meno che non abbiate il gestore Application_Error() appropriato nel Global.asax. Penso che siano sufficienti spiegazioni per una domanda che non ha nulla da fare con Azure.

2. Riuscite a 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 e web forzerà un riciclo:

RoleEnvironment.RequestRecycle() 

Si prega di accettare questa domanda, in quanto non credo che manchi qualcosa. Inoltre ha risposte ad almeno altre 4 domande, aggiunte a quella originale.

FINALE

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