为什么 IIS 会“启动”仍在运行的应用程序?

发布于 2024-09-10 17:25:30 字数 680 浏览 10 评论 0原文

我们有一个在 IIS7 / Windows 2008 上运行的 ASP.NET (3.5 SP1) 应用程序。我们在 Global.asax 中捕获 Application_Start 和 Application_End 事件。我们还在应用程序中托管 WCF 服务,并通过 ServiceHostFactory 捕获 OnOpening 和 OnClosing 事件。因此,我们认为,我们可以保证收到任何应用程序启动和停止(无论是计划内还是计划外)的通知。

几天前,我们的应用程序在“启动”/“运行”状态下捕获了 Application_Start 事件。

在 Application_Start 之前没有 Application_End 事件(如果考虑竞争条件,甚至在几分钟后也没有发生)。

我们的第一个想法是我们的​​应用程序实际上无声地崩溃并终止了。实际上,发生的情况是一个新的应用程序域启动来服务入站请求,但现有应用程序域的后台线程(我们在 ThreadPool 线程中做了很多事情)仍然运行了几天 - 直到我用 IISRESET 杀死了它们。

猜测是 Application_End 没有触发,因为原来的 AppDomain 没有结束...但是为什么 Application_Start 触发了?

寻找描述半关闭+AppDomainStartup 机制如何在 ASP.NET 中工作的提示或文档。

提前致谢,

霍华德·霍夫曼

We have an ASP.NET (3.5 SP1) application running on IIS7 / Windows 2008. We trap Application_Start and Application_End events in Global.asax. We also host WCF services in the app and trap the OnOpening and OnClosing events via a ServiceHostFactory. Thus, we thought, we are guaranteed notification of any application start and stop, scheduled or unscheduled.

Several days ago our application caught an Application_Start event while in a 'started' / 'running' state.

No Application_End event preceeded the Application_Start (or even followed it a few minutes later, if race conditions are considered).

Our first thought was that our application actually silently crashed and terminated. Actually what happened was a new App Domain spun up to service inbound requests but the existing App Domain's background threads (we do lot's of stuff in ThreadPool threads) remained running for several days -- until I killed them with an IISRESET.

The guess is Application_End did not fire because the original AppDomain did not end... but then why did Application_Start fire?

Looking for a tip or document describing how this semi-shutdown+AppDomainStartup mechanism works in ASP.NET.

Thanks in advance,

Howard Hoffman

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

執念 2024-09-17 17:25:30

请了解应用程序池回收,这可能会导致这种情况。当IIS决定回收一个池时,它只是先初始化一个新的工作进程(依次调用Application_Start),然后关闭旧的工作进程(Application_End)。

我建议您在日志中添加一些带有进程 ID 的应用程序级别日志记录,以更好地理解我的上述分析是否正确。

对于 ASP.NET 开发人员,建议更多地了解 IIS。

Please learn about application pool recycle, which can lead to such situations. When IIS determines to recycle a pool, it simply initializes a new worker process first (Application_Start will be called in turn), and then shuts down the old (Application_End).

I suggest you add some application level logging with process id in logs, to better understand if my above analysis is right.

For ASP.NET developers, learning more about IIS is recommended.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文