Re: How to create an immortal web app?

Tech-Archive recommends: Speed Up your PC by fixing your registry

An ASP.Net application times out, just as the Session times out. The
difference is that Session times out (default) 20 minutes after the last
request from a given client. The Application times out (default) 20 minutes
after the last request from *any* client.

It is important to understand that no in-memory data is safe from
application re-starts, as even if the Application did not time out, there
would be times when the server would need to be re-started for any number of
reasons (such as a power failure). You need to handle these situations
gracefully in any application.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.

<daykirby@xxxxxxxxxxxx> wrote in message
news:1141778209.310743.210470@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Sorry if this is a crosspost - I think I put this in the wrong group
before.

I have an asp.net app that takes a few minutes to start on the server
site (unavoidable) but once running it processes requests and serves
data to the client quickly.

Once started, I hold the app in memory using Application variables.
This is working great, and after the first session starts, subsequent
sessions have access to the (already started) app and the requests get
processed quickly.

My problem is that the Application variables seem to have dissapeared
when I get to work in the morning (I actually don't know what time the
app stops, but during my workday it doesn't happen so I think the
Application variables are persisting for a few hours anyway).

I'm having trouble finding documentation on the lifecycle of
Application variables, the Application_End event, etc.

Can (and should) I keep my app alive indefinitely? Is this something I
set in global.asax (like I do with Session variables), should I look
for some IIS settings? Should I take a different strategy maybe and
restart the app on a schedule?

Thanks!



.

Relevant Pages

  • Re: User control remember state across pages without session
    ... Its a shame Microsoft don't extend viewstate beyond a single page because it ... An HTTP Request is received by the web server. ... It sends a Response to the client. ... > Request for a Page comes from any client, the Session Collection has a new ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Catching NPEs
    ... I have developed an app along these lines. ... Unexpected exceptions are caught and rethrown. ... Request servicing continues, and doesn't even diminish in capacity since the thread that dies is recreated immediately unless it's no longer needed anyway. ... Since it's a network using app, most exceptions are I/O exceptions that get handled closer to the source, usually by sending the client an error message and moving on to the next request; they tend to indicate a problem with connectivity or the client having sent a bad or malformed request that includes a bogus URL, parse error, or similarly. ...
    (comp.lang.java.programmer)
  • Re: User control remember state across pages without session
    ... You should have seen what things were like before Session. ... An HTTP Request is received by the web server. ... It sends a Response to the client. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: User control remember state across pages without session
    ... I appreciate that the session is a very useful feature. ... An HTTP Request is received by the web server. ... It sends a Response to the client. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Session_End
    ... Once a request for a page is received by the server, ... between the server and the client. ... Session is memory on the server. ...
    (microsoft.public.dotnet.framework.aspnet)