Quantcast
Channel: Blog- Dedicated Server | Windows Dedicated Server India | Web Hosting | Web Development | Data Center India » Hosting Setup Manual
Viewing all articles
Browse latest Browse all 11

AppDomain Events and HttpModules

0
0

In a previous post we have discussed the cause of an error: A process serving application pool terminated unexpectedly.
I realised that I had a need to catch unhandled 2.0 exceptions and started looking at the AppDomain class.

An Application Domain serves as a boundary so that the runtime can isolate applications from one another and using AppDomain.CurrentDomain, you can retrieve the AppDomain instance that a thread is running under.

One of the events of the AppDomain class is the UnhandledException event and it is this that I could utilise to catch any unhandled exception no matter what thread it runs under.

Therefore if I create a new HttpModule I can provide an event handler for this event and can record these exceptions when that is called.

Pooled HttpApplications

One mistake I didn’t want to make though was one that others had made – simply hooking up an event handler in the Init() method of the HttpModule as usual without taking into account multiple application instances…

The ASP.NET pipeline keeps a pool of HttpApplication objects ready to serve requests and each one of these objects has a collection of HttpModules (and thus each HttpModule provides event handlers for its own HttpApplication).

Therefore because for any one AppDomain you have a number of HttpApplication/HttpModule instances I need to ensure that I only hook up to AppDomain events once.

I can achieve this by making the HttpModule thread/multiple instance aware using static members:
[code]
public class UnhandledModule : IHttpModule
{
#region static members – note, must be thread safe

static int unhandledExceptionCount = 0;
static object lockObject = new object();
static bool initialized = false;

#endregion

public void Init(HttpApplication context)
{
// We only want one instance of a HttpModule to handle event.
if( !initialized)
{
// create a lock so no other instance can affect the static variable
lock (lockObject)
{
if( !initialized)
{

AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

initialized = true;
}
} // now lock is released and the static variable is true..
}}}
[/code]
So with the above code I have ensured that only one HttpModule instance will provide an event handler for the unhandled exception event.
I can be confident that this will not happen multiple times and bloat the memory of the application.

However I have concerns…

The idea for this was obtained from an MSDN article describing the 2.0 unhandled exceptions behaviour change.

What I am concerned about is that because multiple HttpApplication instances are kept in a pool and managed – if any are killed off by the runtime because they are deemed unnecessary (the requests are less frequent for instance), how do I know that the single instance that provided event handler is still alive?

We’ve tested and installed the “UnhandledModule” as described above, yet our application still errors without catching the exception. My current guess is that it is caused by no event handler existing anymore.

I’ve posed this question on the ASP.NET forums and am still figuring out an answer – do the HttpApplication instance all stay alive?
And if not, should I have code in the Dispose() method of the one instance that has the event handler, so it can release the static initialized variable?
Hopefully if I can’t find it, someone out there knows the answer.


Viewing all articles
Browse latest Browse all 11

Latest Images

Trending Articles





Latest Images