More than one instance of HttpApplication present. Why?

[miha.valencic]

Hi!

A while ago, I noticed that there are usually two instances of
HttpApplication created within IIS (observed on WinXPPro). Why is that?
Especially, since Application_Start handler is called on only one
instance (the one that was created first).

Anyone has an idea?

How to test:
I created my own class, which extended HttpApplication. In
Application_Start/End handlers I added some logging code and observed
the situation. The code is below (sorry for the messy code. Can one
format it somehow?).

Regards,
Miha

using System;
using System.Web;

[assembly:log4net.Config.XmlConfigurator()]


public class MyHttpApp : HttpApplication {
private static readonly log4net.ILog log =
log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

public MyHttpApp() {
log.InfoFormat("MyHttpApp constructor called! - Hashcode = {0}",
this.GetHashCode());
}


protected void Application_Start(Object sender, EventArgs e)
{
log.InfoFormat("MyHttpApp->Application_Start called! - Hashcode =
{0}", this.GetHashCode());
}

protected void Application_End(Object sender, EventArgs e)
{
log.Info("Application ending...");
}
}

 

[Scott Allen]

Hi!

A while ago, I noticed that there are usually two instances of
HttpApplication created within IIS (observed on WinXPPro). Why is that?
Especially, since Application_Start handler is called on only one
instance (the one that was created first).

I think the class name is misleading, personally.
http://odetocode.com/Articles/89.aspx

 

[Bruce Barker]

requests are handled by a HttpApplication instance. there is a pool of
these, so if you have simultaneous requests there will be more than one.
this is done so that there is a place to hold instance data during a
request.

the start/end handlers are only called once as that's the design. the
constructor/destructor is called on every instance create/destory.

-- bruce (sqlwork.com)

 

[miha.valencic]

Scott,

thanks for the pointers. Very helpful for better understanding,
although not in-depth. What is missing still is how many objects there
are (how this object pooling works), (because there are not as many as
there are threads -- which are configured in macihne.config) but it is
not important. What is important is knowing that there is not just one.

I am basically storing some state in this App object and since it is
stored in the private static variable which is read only, it does not
matter if there are many instances of this object.

Thanks,
Miha.

 

[Scott Allen]

There should be an application object for each request thread. An
application object is associated with each request thread as it works
it's way through the pipeline. Have you done any experiments that
indicate anything to the contrary?

Note that the objects may be lazily created, so it might not ramp up
to the number of threads configured in web.config unless it is
required.

 

[miha.valencic]

I have observed the contrary. Not too radically, though. What I have
found through testing is, that, as you say, this pool gets lazily
created. Meaning, that it has some sort of algorithm and it starts with
fewer threads in the begining and if the contention happens, the
threadpool grows. In my case, there were 9 HttpApplication instances,
although the threads configured were at 10. Even though I got more than
half 403.9 ERRORs back from the application (too many requests). I
wonder why, since there is supposed to be a default value of 500 for
the queue size.

But, from experience (and web resources) WinXP/2000 is limited in that
way to max 10 connections, but obviously 0 length queue. But this is
another discussion...

rgds,
Miha.