如何检测当前应用程序池是否在 IIS7.5 和 Asp.Net 3.5+ 中结束 [英] How to detect if the current application pool is winding up in IIS7.5 and Asp.Net 3.5+

问题描述

好吧 - 正如问题主题所述 - 关于如何做到这一点的任何想法?

Well - exactly as the question subject states - any ideas on how you might do this?

我一直在查看 System.Web.Hosting 中的对象，但没有任何异常.

I've been looking over the objects in System.Web.Hosting but nothing is standing out.

原因?我收到一两个应用程序错误，这些错误通常发生在回收过程中(它们相隔大约 25 小时发生，我将我的应用程序池回收时间设为默认值)，所以我想知道它们是否发生在池中正在关闭的线程，或者正在启动(编辑/运行)的线程.

The reason? I'm getting one or two application errors which are typically occuring during a recycle (they happen about 25 hours apart and I've left my app pool recycle time at the default) and so I want to know if they're happening on a thread that's in the pool that's shutting down, or the one that's start(ed/ing) up.

推荐答案

我最近偶然发现了 这篇关于 Brain.Save() 的文章 从托管 WCF 的角度讨论了这个问题(他是 Steve Maine - 项目经理Redmond 在连接服务部门).

I recently stumbled across this article on Brain.Save() which talks about exactly this issue from the point of view of hosting WCF (he's Steve Maine - A program manager at Redmond on the Connected Servies Division).

当 WCF 服务托管在 Asp.Net 中时，他们需要能够执行此操作，因为他们需要能够关闭任何打开的侦听器，以便新应用程序域中的 WCF 引擎能够将它们全部打开再次.

They need to be able to do this when a WCF service is hosted inside Asp.Net since they need to be able to shutdown any open listeners so that the WCF engine in the new app domain will be able to open them all up again.

如文章所示，答案是实现 IRegisteredObject 接口，调用 ApplicationManager.CreateObject 来创建对象的实例，然后使用 HostingEnvironment.RegisterObject 注册它(所有详细信息都在 MSDN 文档中界面).

As the article demonstrates, the answer is to implement the IRegisteredObject interface, call ApplicationManager.CreateObject to create an instance of your object and then register it with HostingEnvironment.RegisterObject (all detailed in the MSDN documentation for the interface).

当这个对象的 IRegisteredObject.Stop(bool) 实现以 false 作为参数被调用时，这是应用程序域正在关闭并且对象的通知应该通过调用 HostingEnvironment.UnregisterObject 取消注册(有点像全局处理).

When this object's IRegisteredObject.Stop(bool) implementation is called with false as the parameter, this is notification that the app domain is being shut down and that the object should be unregistered (kind of like a global dispose) with a call to HostingEnvironment.UnregisterObject.

当它用 true 调用时，表示您没有及时取消注册，如果您不立即取消注册，它将为您完成.

When it's called with true it means you've not unregistered in good time, and that if you don't Unregister immediately, it'll be done for you.

我当然可以使用这种机制来查明，当发生异常时，AppDomain 是否被杀死.引发异常的对象的性质意味着，如果它不在关闭时，它必须在初始启动期间.

I can certainly use this mechanism to find out, when an exception occurs, if the AppDomain is being killed or not. The nature of the object in question that throws the exception means that if it's not at shutdown, it must be during initial startup.

然而，同样，我很可能会开始研究这种持久性机制，以获取其他一些更复杂的静态信息！

Equally, however, I may well start looking at this persistence mechanism for some of my other more complicated static information!

这篇文章还解释了为什么要使用 IRegisteredObject 而不是 Application_Start 和 Application_End 方法的一些历史和基本原理在 global.asax 中:

The article also explains some of the history, and rationale, of why you would want to use IRegisteredObject rather than Application_Start and Application_End methods in global.asax:

传统的 ASP.NET 应用程序可以通过在 global.asax 中实现 Application_Start 和 Application_Stop 等方法来挂钩应用程序生命周期事件(应用程序启动/关闭).但是， global.asax 用于应用程序代码.基础结构部分(WCF 托管系统就是其中之一)需要一种挂钩 AppDomain 生命周期事件的机制，这些事件不涉及在 global.asax 文件中转储基础结构代码.那个空间是为你保留的，用户，用一堆托管粘液污染它是不礼貌的，我们需要让整个事情正常工作.相反，ASP.NET 人员在 Whidbey 版本期间做了一些很棒的工作，以开放托管 API，让 WCF 等人可以轻松地以应用程序代码不可见的方式钩住这些生命周期事件.

Traditional ASP.NET applications can hook application lifecycle events (application startup/shutdown) by implementing methods like Application_Start and Application_Stop in global.asax. However, global.asax is for application code. Infrastructure pieces (of which the WCF hosting system is one) need a mechanism of hooking AppDomain lifecycle events that do not involve dumping infrastructure code in your global.asax file. That space is reserved for you, the user, and it would be rude of use to pollute that with a bunch of hosting goo we need to make the whole thing work. Instead, the ASP.NET folks did some great work during the Whidbey release to open up the hosting API’s and make it easy for people like WCF to come along and hook these lifecycle events in a way that’s invisible to application code.

这篇关于如何检测当前应用程序池是否在 IIS7.5 和 Asp.Net 3.5+ 中结束的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！