CODEWITHSUNDEEP
c#c#-4.0iisiis-7appdomain
ohmusama
ohmusama

Reputation: 4215

Creating custom AppDomains in IIS prevents their release, and deadlocks the website

First off, We have written a library, that is used by a Windows Service, and a ASP Webpage that is running in IIS 7.

The library needed to load other libraries as plugins, but some of the external libraries had the same name (but different internal versions). To resolve this binary namespace conflict, we created an AppDomain for each plugin. The Library has a Manager object which references a pool of static connections. Inside the pool of static SharedConnections, the AppDomains live and are destroyed. When the last Manager objects is removed, the Manager object invokes the cleanup of the SharedConnections. This cleanup releases the AppDomains we created.

The Service that relies on our library handles this beautifully. At the beginning of its lifetime it creates the AppDomains and at the conclusion it removes them during cleanup.

The Website that relies on our library handles this poorly. At the beginning of its lifetime it creates the AppDomains, however when IIS decides to unload us after a period of inactivity, the Manger objects are deleted, which invokes the cleanup of the SharedConnection objects as expected. Which in turn kills off the AppDomains.

There are two problems

a) We use lock() around the connection and AppDomain releases, so they don't release twice and subsequently throw errors. Except for some reason, on rare instances, the thread that enters the lock and kills the AppDomain ceases to exist, and never leaves the lock, causing a dead lock scenario. The only way we can resolve this is to stop the AppPool in IIS and restart it 30-60 seconds later. This does not happen with the Windows Service.

b) When we don't observe the above scenario (which is rarely happens), instead occasionally we have AppDomain release issues, this throws Exceptions that crash and restart the webpage, which is okay-ish.

Other things I have discovered via debug. IIS places the website in its own AppDomain, which means we are a child AppDomain making more child AppDomains.

What are we doing wrong? Is there an IIS configuration that might help?

Upvotes: 1

Views: 607

Answers (2)

Akash Kava
Akash Kava

Reputation: 39916

Use Application Request Routing

To solve exact same problem, IIS created ARR to route request to specific version of application based on URL, Cookie or Header parameter which is configurable easily. ARR works as a HTTP Proxy server, which does simple routing.

Here is the example,

http://blogs.msdn.com/b/carlosag/archive/2010/04/02/setting-up-a-reverse-proxy-using-iis-url-rewrite-and-arr.aspx

IIS will do its job of recycling and managing application pools and managing domains for you, you don't have to do any of that.

Upvotes: 1

Steve Ruble
Steve Ruble

Reputation: 3895

You might be able to avoid problem a) by putting your SharedConnection and AppDomain clean up code in the destructor of your Manager object. The destructor will be invoked exactly once by the garbage collector after the manager is disposed and no longer referenced, or when the AppDomain containing the Manager is unloaded. That should eliminate the risk of having your clean up thread aborted by IIS. (This may count as an abuse of the destructor functionality, but I'm not sure what the negative consequences, if any, might be.)

Upvotes: 1

Related Questions