Salve a tutti!

Ho creato un servizio WCF hostato da IIS7 la cui logica alla base é la seguente:
in fase di avvio, il servizio importa dal database tutti i dati necessari e crea gli oggetti necessari a tenere in memoria tutti i dati caricati.
Alla fine di questa fase, il worker process raggiunge la ragguardevole dimensione di 1,1 gb di ram. (dimensione che scende a 350 mb non appena le DataTable utilizzate vengono scaricate dalla memoria).

Una volta finito il caricamento degli oggetti, il servizio é pronto a rispondere alle richieste che riceve. A questo scopo viene utilizzato un endpoint di tipo wsHttpBinding (ovvero SOAP).

A regime, il servizio ha ottime prestazioni in quanto l'uso di memoria ed il carico di cpu é pressoché stabile ed i tempi di risposta ottimi.

I problemi iniziano quando:
1) ASP.NET decide che é il caso di riciclare il processo
2) Il server web che utilizza il servizio viene riciclato.

Nel primo caso, nell'event viewer (Application log) trovo un errore di ASP.NET 2.0.50727.0 che fa riferimento ad un'eccezione di tipo "System.AppDomainUnloadedException". Mentre nel System log trovo un warning lanciato da WAS simile a questo

"A process serving application pool 'Studentum.Search.Cloud02' suffered a fatal communication error with the Windows Process Activation Service. The process id was '4036'. The data field contains the error number."

Il secondo problema avviene quando sostituiamo la cartella "bin" dell'applicazione web con una nuova versione. A naso direi che le connessioni webserver=>servizio restano in qualche modo "aperte" quando l'application pool del server web viene distrutto e riciclato e, per qualche motivo, il servizio wcf muore. Ma non crasha, semplicemente la sua attivitá nel task manager cessa del tutto.

Qualcuno ha qualche suggerimento per investigare meglio l'origine del problema?

Inoltre sono curioso di sapere se é possibile in qualche modo intervenire nell'attivazione del servizio WCF da parte di ASP.NET.

Grazie mille.

in effetti stavo pensando a spostare tutta la struttura da tenere in memoria in un altro processo in modo da disaccoppiare ASP.NET dalla logica dell'applicazione (come dovrebbe essere).

Ma, anche volendo usare un NetNamedPipeBinding, si pagherebbe stupidamente una serializzazione ed una deserializzazione in piú. E siccome i dati in questione non sono pochi, si tratterebbe di aggiungere altri 150 ms al totale.

Ed il capo potrebbe ammazzarmi se gli aumento il response time di 150ms...

Ad ogni modo, volendo fare in modo che il processo venga terminato piú "teneramente", ho chiamato System.Web.Hosting.HostingEnvironment.RegisterObject(IRegisteredObject) ed ora ricevo notifica quando l'AppDomain sta per essere scaricato. Il problema é che non riesco a scaricare la memoria in tempo tra la chiamata del metodo IRegisteredObject.Stop(false) e quella IRegisteredObject.Stop(true).

Non so se é un problema di memory leak o semplicemente troppi dati da scaricare in troppo poco tempo...

Velocity é affidabile da usare in ambiente di produzione? credevo fosse solo in CTP...

scusate se resuscito il topic ma non riesco a venire a capo della seconda parte del problema.

In pratica quando il web server che usa il numero di thread usati dal servizio web inizia a crescere a dismisura provocando il blocco dell'applicazione una volta arrivati ad 80 thread (o giú di lí).

La cosa strana é che se testo il servizio dal server stesso, esso funziona. Al contrario se provo ad usarne le funzionalitá da un altro computer, la richiesta non viene servita.

Ho alcune idee in merito e mi piacerebbe discuterne con voi:

1) quando il server web ricicla improvvisamente (ad es. cambio della cartella /bin causato dall'xcopy deployment), restano alcune connessioni "aperte" verso l'endpoint wsHttpBinding.

Ieri pensavo di aver risolto attraverso l'impostazione di timeouts nella configurazione del wsHttpBinding (closeTimeout, openTimeout, sendTimeout e receiveTimeout settati tutti a 10 secondi). Ma purtroppo oggi abbiamo avuto di nuovo un problema del genere. Forse, usando un valore minore riusciamo a gestire carichi maggiori, peró ho paura di falsi positivi.

2) le connessioni aperte saturano il numero di connessioni contemporanee accettate da IIS sull'indirizzo remoto. Se fosse vero, questo spiegherebbe il corretto funzionamento del servizio attraverso l'uso dell'interfaccia di loopback (localhost).

PS: scusate l'italiano ma sto scrivendo mentre discuto del problema con il boss e siete fortunati che non ho usato parole svedesi -.-