Question about ASP.NET threads: nuts & bolts

[Object01]

I wanted to prove a concept, so wrote a page that does the following:

public void btn_click() {
File.CreateText("file.txt");
Response.BufferOutput = false;
Response.Redirect(this.Request.FilePath, false);
Thread.Sleep(15000);
File.Delete(file.txt);
}

I expected this to cause the user's browser to be redirected to the
same page -immediately- after the user clicked a button. Indeed, this
is the behavior I observed: the browser was redirected to the same
page immediately (via HTTP 302), and another instance of the page
loaded immediately, -while- the original postback continued to run and
then, after 15 seconds, deleted the file. Everything happened
concurrently as intended.

But when I had this pattern implemented on another workstation, the
browser was redirected but a new page instance wouldn't load. In
fact, ASP.NET wouldn't respond to -any- requests for -anything- in the
website until after 15 seconds had elapsed.

Between the two test cases, the only difference seems to be how the
btn_click() handler is bound to the button's click event. In the
former case, I used AutoEventWireup. In the second case, the handler
was attached dynamically on page load.

Why does the second case cause the entire web site to hang? Why won't
ASP.NET service the request by instantiating another instance until -
after- the sleeping thread wakes up? Do handlers behave differently
(i.e. in a different thread) when attached dynamically at run-time vs.
automatically at compile-time?

 

[Patrice]

Could be session contention. AFAIK if the same user tries to run multiple
pages at the same time, the page could be locked while waiting for access to
the session object of this user locked by the previous page ?

 

[bruce barker]

if you call redirect and specify false for end response, only the status
code header is updated, nothing is sent to the browser (unless buffering
is turned off) until page processing is complete. if you pass true,
then a Response.End() is performed, which does a flush (sends all
buffered data) then abort.

-- bruce (sqlwork.com)

 

[Object01]

Indeed, that's what I was counting on, and that's why I turned
buffering off in the example. And sure enough, the browser receives
that redirection code the instant the statement is executed, -
regardless- of the test case. The problem seems to involve one
scenario putting the ASP.NET request processor to sleep, while the
other doesn't.

--
Jeff S.

if you call redirect and specify false for end response, only the status
code header is updated, nothing is sent to the browser (unless buffering
is turned off) until page processing is complete. if you pass true,
then a Response.End() is performed, which does a flush (sends all
buffered data) then abort.

-- bruce (sqlwork.com)

I wanted to prove a concept, so wrote a page that does the following:

public void btn_click() {
File.CreateText("file.txt");
Response.BufferOutput = false;
Response.Redirect(this.Request.FilePath, false);
Thread.Sleep(15000);
File.Delete(file.txt);
}

I expected this to cause the user's browser to be redirected to the
same page -immediately- after the user clicked a button. Indeed, this
is the behavior I observed: the browser was redirected to the same
page immediately (via HTTP 302), and another instance of the page
loaded immediately, -while- the original postback continued to run and
then, after 15 seconds, deleted the file. Everything happened
concurrently as intended.

But when I had this pattern implemented on another workstation, the
browser was redirected but a new page instance wouldn't load. In
fact, ASP.NET wouldn't respond to -any- requests for -anything- in the
website until after 15 seconds had elapsed.

Between the two test cases, the only difference seems to be how the
btn_click() handler is bound to the button's click event. In the
former case, I used AutoEventWireup. In the second case, the handler
was attached dynamically on page load.

Why does the second case cause the entire web site to hang? Why won't
ASP.NET service the request by instantiating another instance until -
after- the sleeping thread wakes up? Do handlers behave differently
(i.e. in a different thread) when attached dynamically at run-time vs.
automatically at compile-time?