Take Application off line quickly

  • Thread starter Thread starter Guadala Harry
  • Start date Start date
G

Guadala Harry

Suppose I need to make an ASP.NET Web application inaccessible to anyone
trying to open any of its pages. How can this be done quickly - and in a way
that allows me to bring the whole thing back online quickly?
 
1) Shut down IIS - of course this will give them a page not found type of
error
2) You can configure a virtual directory in IIS to redirect to a given URL.
This URL can then inform the user that the site is down and to try again
later. This would probably be more user friendly.
 
You could just stop the IIS site. You could also hanlde this in the app
itself if needed (especially if it could be interesting to "filter" those
who are allowed to log on when the app is in this particular state).

The overall goal may yield a better suggestion.

Patrice
 
Yes - the overall goal (small detail!): Here it is: I have to periodically
bring a site down for maintenance (anywhere from 2 minutes to 2 hours;
install upgaded assemblies, updated aspx files, modify database etc); during
which period I don't want anyone to come in - and after which I want to
allow everyone back in of course. I don't mind killing existing sessions
(could easily pick a time of day to minimize such occurances in this
low-volume application). It would be great if the user could see some
informative message when they attempt to open any page in the site - rather
than some error that drives them to call tech support.

Thanks!

-GH
 
Ok so you have the options :
- virtual dir as suggested by Marina
- adding this into the app will allow some accounts to connect so that you
can check that it works before bringing things online again.

As a side note, I believe to have read that ASP.NET actually caches the DLLs
(including ASPX code behind) so that you can update DLLs and pages "on the
fly". You could ask this in a separate thread. For the database, you could
prepare a script.

Though I admit we have no high volume (vertical applications) and that users
are generally located in the same country (allowing to update during lunch
or after the day work), IMO you could look also if you can shorten the time
it takes to perform this update and in some cases it could be even almost
useless to "close" the site.

As an additonal note, you may want also to display a "message of the day"
*before* the update so that they know the site *will* be updated while they
work. Bascially I would see :
- Schelded date for the next update and expected duratino (few days before)
- a warning message or blocking the site during the update (tyhat should be
IMO almost "automated" ie blocking or anbeling the warning, copying prepared
files to update DLLs and pages, running a script)
- you do the final check by hand and can correct what unexpectedly goes
wrong
- when all is ok, you manually enable the site again

Patrice

--
 
Thanks!



Patrice said:
Ok so you have the options :
- virtual dir as suggested by Marina
- adding this into the app will allow some accounts to connect so that you
can check that it works before bringing things online again.

As a side note, I believe to have read that ASP.NET actually caches the DLLs
(including ASPX code behind) so that you can update DLLs and pages "on the
fly". You could ask this in a separate thread. For the database, you could
prepare a script.

Though I admit we have no high volume (vertical applications) and that users
are generally located in the same country (allowing to update during lunch
or after the day work), IMO you could look also if you can shorten the time
it takes to perform this update and in some cases it could be even almost
useless to "close" the site.

As an additonal note, you may want also to display a "message of the day"
*before* the update so that they know the site *will* be updated while they
work. Bascially I would see :
- Schelded date for the next update and expected duratino (few days before)
- a warning message or blocking the site during the update (tyhat should be
IMO almost "automated" ie blocking or anbeling the warning, copying prepared
files to update DLLs and pages, running a script)
- you do the final check by hand and can correct what unexpectedly goes
wrong
- when all is ok, you manually enable the site again

Patrice
Click to expand...
 
Back
Top