web-app restart on file replacement

[John A Grandy]

In ASP.NET 1.1 and/or 2.0 .....

Is it possible to configure a web-app so that replacement of an .xml file
( physically located under the virtual dir root ) with a newer version of
the file causes a web-app restart ... ?

Also, is a stopping and starting a website in IIS the only way to restart a
web-app ?

(Of course, iisreset stops and starts all web-apps on the web-server ... but
I'm asking about other ways to restart the web-app).

Thanks.

 

[Paul Glavich [MVP ASP.NET]]

You can restart only the application pool under IIS6 to achieve the same
effect but only do it for the specific application pool your app belongs to,
and thus not affect all the other sites. You can probably do this via the
cmd line but I am not sure of the syntax or cmd line arguments. Perhaps
someone else can chime in here.

For your XML file, I would be inclined to setup a file dependency in the
cache to detect when its changed, then programmaticaly do what needs to be
done in your application rather than trying to trigger a full app restart.
That seems like a very heavy handed approach.

 

[John A Grandy]

Hi Paul, and thanks for the response.

Yes, web-app restart would seem to be more harmful than just triggerring
reload of all config settings. In some cases, new config settings might
mean some sessions get mulched depending on where they are in the e-commerce
sequence, but web-app restart would knock out all sessions.

What approach is typically used in production web-farm apps to handle
redeployment of various new .aspx pages, and/or .dll libs , and/or
strings.resx files ? Is traffic directed away from server 1, and when all
existing sessions time-out then server 1 is redployed , then go to server 2,
etc ? Or are the files just copied over with sessions in progress and
ASP.NET is left to perform its shadow-copying magic so that various old and
new sessions run against multiple file versions ?

What is your thinking on the security issues involved with locating numerous
app config settings (including various URLs , including web-service URLs) in
an XML file on each web-server (or on a separate machine that all
web-servers in the farm point to) ? How do you rate this versus locating
the config settings in the DB?

I like a XML config settings file because it is a single file that can be
tracked in source code control, and is straightforward to update (ops always
performs the same task - copy over the file). But security issues might
give the nod to the DB ...

 

[Venkat_KL]

Hi Dear John A Grandy,

I was looking out for your answer; but right now i got only why
application will start, not how to start it. Anyway I just wanted to
share with you.
I will come back to you, the moment I got the answer.

here are the reasons

There are many causes to application recycle, the most common are:



1) Unhandle Exception.

2) Any write to application bin directory.

3) Any change to web.config.

4) Anti-virus program that touch files.

5) One of ProcessModel attribute in machine.config that cause
application recycling.

-----------------------------------------------------------------------
This talks about both 1.0 and 1.1

This behaviour has been bugging lots of people. ASP.Net will restart its
application for various reasons. All these reasons are legitimate, but
the side effect is that the application will reset all its cache,
application state, and InProc session states.
You can detect the restart of application and worker process by using
the performance monitor. The counters to monitor are
"ASP.NET\Application Restarts" and "ASP.NET\Worker Process Restarts".

For worker process restart, ASP.NET will write an entry in the eventlog
to explain why (logLevel in controls how often eventlog is written).

For application restart, however, in v1 and v1.1 there is no easy way
for a customer to figure out why a restart happened.

So by listing all reasons for app restart, I hope I can help some
customers to understand and avoid the restart.

For v1
------

Things that causes application restart:

- The max compilation limit is reached (look for
numRecompilesBeforeApprestart in machine.config)

- Physical application path of the web application has changed.

- Change in global.asax or one of the included files

- Change in machine.config

- Change in web.config in the app root

- Change inside bin directory or its subdirs

- A directory is renamed to bin, or bin is created

- Overwhelming change notifications – too many files are changed too
fast in one of content directories – could happen if, for example, files
are generated on the fly per request

- Change in the code-access security policy file

- The settings of various attributes in in machine.config affect the
restart/shutdown of the worker process itself. However, if you use
Windows 2003, and (by default) you are NOT using IIS5 isolation mode, is
ignored. Instead, the settings in "Application Pools" in IIS manager is
used.


For v1.1
--------
The list for v1.1 is the same as v1, with the following new conditions:

- User code called HttpRuntime.UnloadAppDomain

- Any directory under the web application folder is renamed

IIS 6.0
--------
If you're using IIS 6.0, and you're not using IIS 5 compatible mode,
then aspnet_wp.exe will be replaced by w3svc.exe. You may want to go to
IIS Manager, go to Application Pools/DefaultAppPool, and see if any of
the parameters on the Recycling and Performance tabs are causing the IIS
worker process (w3svc.exe) to shutdown.

Bye
Venkat_KL