Server Application Unavailable e IIS6

Internet Information Services (IIS) non è solo una piattaforma per ospitare siti web, è in alcuni casi anche un component essenziale per diversi altri prodotti Microsoft come Content Management Server, Exchange Server ecc. I processi di sviluppo che hanno investito questa piattaforma sin dalla sua versione 1.0 all’attuale 6.0 di Windows 2003 Server sono molteplici.
In particolare nell’ultima versione, considerate tutte le critiche mosse contro Microsoft circa sicurezza e stabilità del sistema, il team di sviluppo di IIS si è adoperato profondamente al fine di riscrivere completamente un nuovo server web che sopperisse le critiche mosse.

 

Un po’ di storia prima di proseguire

Fino ad IIS3 tutti i siti web hostati, compreso la stessa piattaforma giravano su di un unico processo chiamato inetinfo.exe.

IIS 3

Con IIS4 si è iniziato a pensare per la prima volta ad un modello che slegasse completamente la piattaforma dai servizi web. Risultato un processo di nome inetinfo.exe che gestiva il WWW e tanti siti web che potevano girare “tranquillamente” sotto la stessa macchina, con il vantaggio di poter essere avviati e fermati a piacimento senza per questo impattare le altre applicazioni. Svantaggio, nessun sito web poteva interagire con gli altri, e in fase di debug, tutto veniva spostato sotto il processo principale e quando il primo bug veniva alla luce, se questo mandava in crisi il processo, bisognava procedere nuovamente al riavvio del servizio (e tutti gli altri siti ignobilmente venivano spenti e riaccesi facendo perdere le sessioni di lavoro).

IIS 3

IIS 4

IIS5, avvento di ASP.net 1.0 e nuovo approccio alla programmazione dinamica (a memoria ricordo fosse il tardo 2000, primi del 2001). Piccole modifiche al server web e al suo modo di gestione ora denominato “pooled process” che consentiva di far girare diverse applicazioni in un processo separato chiamato dllhost.exe, realmente separatp dal core della piattaforma. Vantaggio indiscusso di poter riavviare, fermare, debuggare applicazioni in maniera totalmente indipendente, di poter assegnare all’applicazione un profilo di isolamento del processo (a scelta tra basso, medio e alto), cioè assegnare l’area di memoria condivisa dove poter lavorare. Questo il vero svantaggio, perché comunque, bene o male, tutte le applicazioni lavorano sotto un unico processo.

IIS 6.0 e ora ASP.net 2.0 / 3.0. Riscrittura totale del server web, un solo livello di isolamento del processo ora denominato “application pool”. Un processo che può essere creato ex-novo e per un numero “infinito” di applicazioni che possono ora girare in uno spazio realmente distinto o condiviso a seconda delle impostazioni date via console.

 

Perché la storia era necessaria

 

Non sono un fanatico dei libri, ma era necessario evidenziare i cambiamenti che ci sono stati nel passaggio tra IIS5 e IIS6 per affrontare il problema. Ma diamo un’occhiata alle immagini prima di proseguire oltre.

La prima immagine mostra un task manager di IIS5, 3 processi aspnet_wp.exe, uno per ogni istanza del frame work caricata.

Con IIS5 se il processo con la versione del framework richiesta non era attiva, veniva semplicemente caricata. Un piccolo stratagemma implementato da MS per permettere di far coesistere diverse versioni di framework senza troppe preoccupazioni per lo sviluppatore che per l’amministratore di sistema.

Con IIS6, invece, la storia è cambiata. Notate l’assenza di aspnet_wp.exe, e invece un prolificarsi di processi denominati w3wp.exe. Ognuno di quei w3wp.exe è un application pool distinto e separato nel quale possono giare più siti web (o anche uno solo) e una versione X del framework. In questo caso parlo al singolare. Si perché è impossibile che sotto ad un singolo application pool girino più versioni del framework.. Pena, la prima applicazione con il framework differente che inzierà a girare, ritornerà con un bell’errore di questo tipo.

 

Server Application Unavailable
The web application you are attempting to access on this web server is currently unavailable.  Please hit the "Refresh" button in your web browser to retry your request.
Administrator Note: An error message detailing the cause of this specific request failure can be found in the application event log of the web server. Please review this log entry to discover what caused this error to occur.

 

Questo avviene con un ordine non ben precisato. Mi spiego. Dato che l’application pool per default dopo 20 minuti di inutilizzo viene riciclato, è possibile che se il sito A che richiede la versione 1.1 del framework, non trovando un worker process attivo, ne carichi uno nuovo con quella versione del framework. Dopo pochi secondi arriva una nuova richiesta per il sito B. Stesso application pool, ma framework differente. Essendo l’application pool ancora attivo in memoria, il risultato è l’errore sopra mostrato.
Al successivo riciclo dell’application pool, potrebbe invece succedere l’esatto contrario. Ma l’errore non cambia e comunque nel registro degli eventi vi sarebbe sempre una traccia con la quale fare “debugging”. Infatti per problemi di questo tipo nell’event viewer viene aggiunta una entry con codice di errore 1062, come quella che si vede nell’immagine qui sotto.

Event viewer error

 

 

Soluzione

Esistono due possibili soluzioni per questo genere di problema.

1) Soluzione non sempre praticabile, è quella di aggiornare la versione del framework per tutte le applicazioni. Non sempre possibile, perché alcuni componenti utilizzati magari non funzionano con una specifica versione, piuttosto che del managed code scritto, dato il cambio di alcune classi tra la versione 1.1 e la 2.0 del framework richiedono degli interventi sul codice.

2) Soluzione decisamente più sbrigativa, è quella di creare almeno un application pool diverso per ogni versione del framework che deve girare nel sistema e assegnare le varie applicazioni coerentemente con quanto detto.

 

Technorati Tags: , Server Application Unavailable