Processus personnalisé démarré dans Application_Start

Je dois traiter une application ASP.NET héritée écrite dans .NET Framework 1.1. En vérifiant le code de l'application, j'ai trouvé une partie intéressante. L'application démarre le thread personnalisé dans le gestionnaire d'événements Application_Start (Global.asax). Ce fil doit fonctionner toute la vie de l'application. Il ya longtemps, j'ai lu que cela ne devrait jamais être utilisé, mais je ne me souviens pas pourquoi. Quels sont les problèmes liés à une telle conception d'application? Est-il possible de recommencer à filer quand il se bloque? Est-ce que le crash sera enregistré quelque part automatiquement (journal des événements)? Le runtime ASP.NET peut-il tuer le thread pour une raison quelconque?Processus personnalisé démarré dans Application_Start

Pour l'instant je ne suis pas intéressé par le recyclage AppPool. Il redémarre l'application, toutes les sessions et crée un nouveau thread.

Source

2010-09-08 Ladislav Mrnka

Le seul problème auquel je peux penser est que le thread sera terminé lorsque le pool d'applications recycle - mais il recommencera alors. Il est clair que le code de thread doit être écrit de manière robuste et ne pas se terminer en raison d'exceptions inattendues. –

Le principal problème est que le thread peut être arrêté à tout moment par ASP.NET. Si le thread s'exécute tout le temps, il y a probablement du travail qu'il devrait faire, et se terminer ne peut pas rendre votre application heureuse la prochaine fois qu'il démarre.

Les solutions modernes incluent l'utilisation de pages asynchrones et le pool de threads intégré.

Si vous choisissez de mettre à niveau, n'oubliez pas que in .NET 1.1, threads throwing a top-level exception just exit; in .NET 2.0, threads throwing a top-level exception crash. Si vous mettez à niveau, il serait probablement préférable de faire le saut vers les pages asynchrones plutôt que de garder un fil séparé.

Source

2010-09-08 15:09:40

C'est ce dont j'ai peur. Je sais qu'ASP.NET 2.0 gère les threads dans le pool de threads, mais je ne suis pas sûr de savoir comment cela fonctionne dans ASP.NET 1.1. Le thread est en fait très important car il gère les verrous expirés dans le verrouillage pesimiste en mémoire. L'un des problèmes que je dois résoudre est que les verrous ne sont parfois pas libérés ... –

Puisque le verrouillage est en mémoire, il doit tout être recyclé avec le thread au redémarrage de l'application. La première chose à déterminer est si le thread meurt pour une raison inattendue; encapsuler la procédure de thread dans un try/catch et enregistrer l'erreur. Reproduire le problème et voir ce qui apparaît dans le journal (si quelque chose). –

Oui, c'est ce que je prévois de faire. Je suis juste curieux de savoir si c'est une bonne pratique et quelles sont les raisons de ne pas l'utiliser. –

Processus personnalisé démarré dans Application_Start

Répondre

Questions connexes