AppDomain Crash and effect on ASP.net worker process.

[pradeep_TP]

Hi all,

I am using IIS 5.0 and this question is regarding working of ASP.net worker
process. I have only one web application right now on my web server. This
means that only one AppDomain will be created inside a single worker process.

NOw for example, due to some reason, my web application generated a stack
overflow error and crashed my appdoman (this happend in real case). In this
case as far as my knowledge goes, only appdomain should crash and not asp.net
worker process . Often i see remarks in internet that the ASp.net worker
process will recylcle or crash if the web application crashes. If i am
correct, the appdomain concept was created just to make sure that if there
are two app domains (if there are two web applications), then if one
appdomain crashes the other should survive. But if crashing one appdomain is
going to crash the entire asp.net worker process then all the appdomains
inside it will also get killed.

I am really confused about the concept a little bit. Can any expert throw
some light on it.

Thanks and Regards
Pradeep_tp
(Query_0000001)

[shiv_koirala]

LOW (IIS process):- In this main IIS process and ASP.NET application
run in same process.So if any one crashes the other is also affected.
Medium (Pooled):- In Medium pooled scenario the IIS and web application
run in differentprocess.So iis will not affect the webapplication
High (Isolated):-In high isolated scenario every process is running is
there own process. Which probably you will want to implement for
complete safecty

-------
Regards ,
C#, VB.NET , SQL SERVER , UML , DESIGN Patterns Interview question book
http://www.geocities.com/dotnetinterviews/
My Interview Blog
http://spaces.msn.com/members/dotnetinterviews/

[pradeep_TP]

Hi,

I am confused by your answer.

1) wshat are these Low, Medium and High???.
2) What is IIS process. Is this ASP.net worker process?.
3) I am still clueless about where appdomain fits in this scenario.

It would be kind if you could please explain me from the point of view of
appdomain and worker process.

thanks
pradeep_tp

"sh**********@yahoo.com" wrote:

LOW (IIS process):- In this main IIS process and ASP.NET application
run in same process.So if any one crashes the other is also affected.
Medium (Pooled):- In Medium pooled scenario the IIS and web application
run in differentprocess.So iis will not affect the webapplication
High (Isolated):-In high isolated scenario every process is running is
there own process. Which probably you will want to implement for
complete safecty

-------
Regards ,
C#, VB.NET , SQL SERVER , UML , DESIGN Patterns Interview question book
http://www.geocities.com/dotnetinterviews/
My Interview Blog
http://spaces.msn.com/members/dotnetinterviews/

[JIMCO Software]

pradeep_TP wrote:

Hi all,

I am using IIS 5.0 and this question is regarding working of ASP.net
worker process. I have only one web application right now on my web
server. This means that only one AppDomain will be created inside a
single worker process.

I am really confused about the concept a little bit. Can any expert
throw some light on it.

Hi Pradeep,

In IIS 5, all ASP.NET applications run inside of the same process (excluding
the possibility of web gardens) and inside of that process (aspnet_wp),
there are app domains that provide application separation in terms of
configuration, etc. However, if one application leaks memory, hangs,
crashes, etc., it will affect ALL ASP.NET applications. There is no
_process_ isolation.

In your case, a StackOverflowException will raise a second chance AV and
that will crash the process, aspnet_wp. When that happens, every ASP.NET
application on the system will go down because the process hosting them
crashes.

The concept of Low, Medium, and High isolation has absolutely no relevance
in regards to ASP.NET applications. That setting will have no effect on
your ASP.NET apps.

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com

[pradeep_TP]

Hi jim,

You are very close to help me fully understand it. I am quite clear about
what you have said. You have said "if one application leaks memory, hangs,
crashes, etc., it will affect ALL ASP.NET applications". IF this is the
case, then what is the use of Appdomains. From what I have understood from
appdomain is, they provide web application isolation withing asp.net worker
process. If one appdomain crash can affect all asp.net application, then
what is the advantage of having appdomains.

Cheers!
pradeep_tp
I am also imagining a situation where my ASP.net web site is hosted by a
third party hosting service company. If my web app is going to crash then if
say there are 10 other different web app running, then would all these web
applications also crash!.

"JIMCO Software" wrote:

pradeep_TP wrote:

Hi all,

I am using IIS 5.0 and this question is regarding working of ASP.net
worker process. I have only one web application right now on my web
server. This means that only one AppDomain will be created inside a
single worker process.

I am really confused about the concept a little bit. Can any expert
throw some light on it.

Hi Pradeep,

In IIS 5, all ASP.NET applications run inside of the same process (excluding
the possibility of web gardens) and inside of that process (aspnet_wp),
there are app domains that provide application separation in terms of
configuration, etc. However, if one application leaks memory, hangs,
crashes, etc., it will affect ALL ASP.NET applications. There is no
_process_ isolation.

In your case, a StackOverflowException will raise a second chance AV and
that will crash the process, aspnet_wp. When that happens, every ASP.NET
application on the system will go down because the process hosting them
crashes.

The concept of Low, Medium, and High isolation has absolutely no relevance
in regards to ASP.NET applications. That setting will have no effect on
your ASP.NET apps.

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com

[JIMCO Software]

pradeep_TP wrote:

Hi jim,

You are very close to help me fully understand it. I am quite clear
about what you have said. You have said "if one application leaks
memory, hangs, crashes, etc., it will affect ALL ASP.NET
applications". IF this is the case, then what is the use of
Appdomains. From what I have understood from appdomain is, they
provide web application isolation withing asp.net worker process. If
one appdomain crash can affect all asp.net application, then what is
the advantage of having appdomains.

Cheers!
pradeep_tp
I am also imagining a situation where my ASP.net web site is hosted
by a third party hosting service company. If my web app is going to
crash then if say there are 10 other different web app running, then
would all these web applications also crash!.

Hi Pradeep,

The Common Language Runtime controls how code is executed in a managed
application. The CLR enforces app domain isolation so that code running in
one app domain cannot access objects in another app domain without copying
the object or using a proxy.

You also have the ability to unload an app domain without restarting the
process and affecting other applications. This is beneficial in cases where
configuration changes have been made (i.e. changes to the web.config) or
where you have created your own app domain and you want to unload it so that
assemblies loaded into it are unloaded as well.

Regarding your question about hosting at a third party, yes, you are right.
If your application that is overflowing the stack were running on a hosting
company's servers, when it crashes, it will bring down all other ASP.NET
applications running in that same process. For IIS 5, that means all other
ASP.NET apps on that box. For IIS 6, it means all ASP.NET apps running in
the same application pool. (Each application pool runs in its own w3wp.exe
process.)

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com

[pradeep_TP]

Thank you very much JIM :).

That was a great information. I didnt knew that crashing on ASP.net web
application can bring down the others too. Now I am quite clear about this
scene. Wondering how the hosting companies manages these kind of crashes!..
Thanks again JIM, your answer indeed has helped me.

Cheers!!!
Pradeep_tp

"JIMCO Software" wrote:

pradeep_TP wrote:

Hi jim,

You are very close to help me fully understand it. I am quite clear
about what you have said. You have said "if one application leaks
memory, hangs, crashes, etc., it will affect ALL ASP.NET
applications". IF this is the case, then what is the use of
Appdomains. From what I have understood from appdomain is, they
provide web application isolation withing asp.net worker process. If
one appdomain crash can affect all asp.net application, then what is
the advantage of having appdomains.

Cheers!
pradeep_tp
I am also imagining a situation where my ASP.net web site is hosted
by a third party hosting service company. If my web app is going to
crash then if say there are 10 other different web app running, then
would all these web applications also crash!.

Hi Pradeep,

The Common Language Runtime controls how code is executed in a managed
application. The CLR enforces app domain isolation so that code running in
one app domain cannot access objects in another app domain without copying
the object or using a proxy.

You also have the ability to unload an app domain without restarting the
process and affecting other applications. This is beneficial in cases where
configuration changes have been made (i.e. changes to the web.config) or
where you have created your own app domain and you want to unload it so that
assemblies loaded into it are unloaded as well.

Regarding your question about hosting at a third party, yes, you are right.
If your application that is overflowing the stack were running on a hosting
company's servers, when it crashes, it will bring down all other ASP.NET
applications running in that same process. For IIS 5, that means all other
ASP.NET apps on that box. For IIS 6, it means all ASP.NET apps running in
the same application pool. (Each application pool runs in its own w3wp.exe
process.)

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com