views:

55

answers:

3

Hey All,

I maintain a ASP.NET web application that causes a user's network connection to reset for several seconds when it executes a procedure. Therefore, the page request times out on the user's end as they never receive the web application's response (the connection dies before it gets the response packet).

To resolve this situation, I was contemplating having the ASP.NET page execute an asynchronous function that incorporates a Thread.Sleep(5000); // sleep for 5 seconds before executing the connection reset This way, the browser has 5 seconds to receive the page's response before their connection resets.

I have concerns with using Thread.Sleep and asynchronous functions in ASP.NET though. I've never attempted to do it before, so I'm unsure of the potential problems it may cause. Does anyone see potential problems with starting an asynchronous thread that contains a Thread.Sleep in an ASP.NET application? If so, can you think of a better solution?

A: 

Though I find your problem statement too vague to address properly, I can say that you should use System.Threading.Timer instead of a Sleep statement. The former is performant, the latter will keep one of your CPU core's in a busy state (very bad!).

Brent Arias
This isn't quite accurate: threads that are sleeping are marked as Blocked and won't consume CPU time. However, you are blocking a thread for no reason, and that *is* bad.
FacticiusVir
It sounds like you will cause your client to timeout no matter which way you perform a connection reset. Why not use a lock (Monitor.Pulse / Monitor.Wait) where your ASP.NET thread does a Wait on two asynchronous events: make the business procedure asynchronous and use System.Threading.Timer. Both the procedure and timer will invoke Pulse. If the timer wins, it sets a "tookTooLong" flag, and your ASP.NET call can return gracefully to the client. If the procedure wins, it clears the "tookTooLong" flag. You get the idea.
Brent Arias
@FacticiusVir: For several "sleep"-filled applications I've seen, it was necessary to eliminate sleep statements to unpeg the CPU usage from 100% down to 2%.
Brent Arias
Sorry if my post was not thorough. I feel like maybe the problem with my post was actually that it listed too much details. Ultimately, what I need to do (regardless of why) is queue some action to happen 4-5 seconds after the Page returns the response packet to the calling browser.
regex
+2  A: 

Placing Thread.Sleep in an asynchronous method can contribute to ThreadPool Starvation, as it blocks one of a limited number of threads for several seconds - that thread could be off servicing client requests.

Instead, why not create a timer that fires after five seconds? Same effect, just register your delayed work in the timer's event.

FacticiusVir
Would the Timer still fire even if the object that referenced it (in this case the Page) is destructed?
regex
If the page that references it is garbage-collected, the Timer will be also and so won't fire; you'll need to keep a static collection of unexpired timers to maintain a strong reference.
FacticiusVir
Good point - though it's not often a concern, the ThreadPool can become starved if all the threads are SLEEPing, and then your application is sitting idle, waiting for the threads to wake up again.
rwmnau
+1  A: 

It is generally not a good idea to put the thread to sleep on a web server, because the threads are limited. In your specific case you need one client, starting ~1-2 requests per second, to block all your threads...

You should use a timer, as others proposed, and ofcource a AsyncPage / AsyncHttpHandler.

Nappy