Question

Situation: A high-scale Azure IIS7 application, which must do this:

1. Receive request
2. Place request payload onto a queue for decoupled asynchronous processing
3. Maintain connection to client
4. Wait for a notification that the asynchronous process has completed
5. Respond to client

Note that these will be long-running processes (30 seconds to 5 minutes).

If we employ Monitor.Wait(…) here, waiting for a callback to the same web application, from the asynchronous process, to invoke Monitor.Pulse(…) on the object we invoked Monitor.Wait() on, will this effectively create thread starvation in a hurry?

If so, how can this be mitigated? Is there a better pattern to employ here for awaiting the callback? For example, could we place the Response object into a thread-safe dictionary, and then somehow yield, and let the callback code lock the Response and proceed to respond to the client? If so, how?

Also, what if the asynchronous process dies, and never invokes the callback, thus never causing Monitor.Pulse() to fire? Is our thread hung now?

Answer 1

Given the requirement you have, I would suggest to have a look at AsyncPage/AsyncController (depends on whether you use ASP.NET WebForms or ASP.NET MVC). These give you the possibility to execute long running tasks in IIS without blocking I/O threads.