2010-07-22 28 views
1

Nous avons une application ASP.NET (3.5 SP1) fonctionnant sous IIS7/Windows 2008. Nous interceptons les événements Application_Start et Application_End dans Global.asax. Nous hébergeons également des services WCF dans l'application et piégons les événements OnOpening et OnClosing via un ServiceHostFactory. Ainsi, nous avons pensé, nous sommes garantis la notification de toute demande de démarrage et d'arrêt, programmée ou imprévue.Pourquoi IIS "démarre" une application qui est toujours en cours d'exécution?

Il y a quelques jours, notre application a détecté un événement Application_Start dans un état 'démarré'/'en cours d'exécution'.

Aucun événement Application_End n'a précédé Application_Start (ou même l'a suivi quelques minutes plus tard, si les conditions de course sont prises en compte).

Notre première pensée était que notre application s'est écrasée silencieusement et s'est terminée. En fait, un nouveau domaine d'application a été créé pour traiter les demandes entrantes, mais les threads d'arrière-plan existants d'App Domain (nous faisons beaucoup de choses dans les threads ThreadPool) sont restés actifs pendant plusieurs jours - jusqu'à ce que je les tue avec IISRESET.

La supposition est Application_End n'a pas tiré parce que l'AppDomain d'origine n'a pas fini ... mais alors pourquoi Application_Start feu?

Vous recherchez une astuce ou un document décrivant comment fonctionne ce mécanisme de semi-arrêt + AppDomainStartup dans ASP.NET.

Merci à l'avance,

Howard Hoffman

Répondre

0

S'il vous plaît apprendre sur l'application de recyclage de la piscine, ce qui peut conduire à de telles situations. Lorsque IIS décide de recycler un pool, il initialise tout d'abord un nouveau processus de travail (Application_Start sera appelée à son tour), puis arrête l'ancien (Application_End).

Je vous suggère d'ajouter une journalisation au niveau de l'application avec l'ID de processus dans les journaux, pour mieux comprendre si mon analyse ci-dessus est correcte.

Pour les développeurs ASP.NET, il est recommandé d'en savoir plus sur IIS.

+0

Curieusement, je vois le même comportement - plusieurs invocations Application_start, et nous enregistrons pid, et c'est la même chose. Ainsi, le même processus w3wp décide de démarrer une application qu'il sert déjà à nouveau. –

+0

http://blogs.msdn.com/b/tess/archive/2008/11/06/troubleshooting-appdomain-restarts-and-other-issues-with-etw-tracing.aspx –

+0

Je voulais ajouter que notre AppPool était configuré pour ne jamais recycler - tous les paramètres de recyclage d'AppPool étaient à 0. Nous n'avons jamais pu déterminer de manière prouvable ce qui s'est réellement passé - pourquoi le crash de l'App Pool. Nous avons ensuite modifié notre mécanisme Application_Start/End pour utiliser un fichier en tant que "Mutex" - App-Start crée le fichier et les suppressions App-End, et App-Start se termine rapidement si le fichier existe. Nous pouvons donc au moins détecter le cas de double démarrage s'il se produit de nouveau. Dans quelques années de production depuis ... ce n'est pas le cas. –