tags:

views:

89

answers:

2

I have a question that I can't quite find the answer to...

If you have an ASP.Net page that takes longer than the request time-out to render what happens to that process? Does the web service abort it?

Lets say I'm writing XML to the response stream in an ASP.Net page and it times-out calling my GenerateXML method. What happens to my method call? Does it complete but the web server reports the time out? or is it aborted?

I could probably write a test to see my own results but I figure there might be more to it.

A: 

Since the rendering process does not know anything about session timeouts per se, my assumption is that the rendering completes without any problem. It's just when the user performs an action on the rendered page that is sent back to the server, that the tiemout is realized.

I can't back this up by any proof right now, but to me this is the most logical behaviour. Anything else would require additional timeout checks in the rendering process, which costs cpu time (= money), but would not improve session security in any way.

Treb
+1  A: 

Let's clarify: There are at least two timeouts in your question (1) session timeout (2) request timeout. The most common scenario is request timeout - since client doesn't want to wait minutes until server alive. And as usual request lifetime is less than session. In this case server terminates request in usual way - by raising ThreadAbortException. This exception is raised even if everything okay, just to terminate request processing.

When session is over - client even should not know about it. Only if you have autorization client would be redirected to login page. But server code can lost data stored in session.

Dewfy
So the thread my page request (and therefore GenerateXML method) are executing on gets taken down with a ThreadAbort then? What is the best way to handle this situation? I'm generating then caching the XML but if it always times out on first generate then it won't ever get cached.
Jeff Alexander
@Jeff: I always hate getting answers like this, but if your page renderer takes *that* long, the problem lies in the page rendering, not in the way IIS handles session management, so that is where you should improve...
Treb
I figured as much. It just means more work to solve this problem. I just needed to think the page request process through to prove it to myself.
Jeff Alexander