Multithreading with ASP.NET and IIS

We have a web application that needs to process a large amount of data and push messages to a series of MSMQueues. This operation is like开发者_Go百科ly to take upwards of 10 minutes but we want a response back (consisting of an ID) quickly. Therefore, we have implemented a system that generates the ID and starts the push process on a separate thread, then returns the ID.

This works fine, but our only concern is when IIS is restarted. We've done some testing and IISRESET kills the worker thread even if our thread hasn't finished queueing messages. Ideally, we'd like to resart IIS in a way where our thread would continue to run until it's finished.

Passing the /NOFORCE switch to IISRESET seems to have no effect.

Does anyone know a way we could ensure that IISRESET waits for our worker thread to complete its processing before restarting IIS.

Thanks,

Steve

---

IIS isn't really the place you should be executing long running tasks such as this. We have very similar requirements where we need to initiate long running maintenance tasks on our web servers. These jobs are started via a web service and then handed off to a Windows Service. As long as the Windows service is still alive we can query the tasks for their progress. This means our long running tasks can survive an IISRESET.

IISRESET is pretty much all or nothing and is insensitive to .NET threads you have running in your ASP.NET application.

The /NOFORCE switch is there to tell IISRESET not to forcefully reset IIS if the service doesn't respond within one minute. IISRESET has no knowledge of your .NET applications and will kill your application dead.

Update:

To answer the question in Steve's comment: "How do you recommend passing data to the Windows Service from IIS?". What to do is host a .NET Remoting or WCF application in the windows service and pass data/messages using Named Pipes (only if intra-machine calls are required).

---

I would suggest that if you do not require a response from the thread which I take it you don't, that you queue it in your db and then create a service to handle the queue. When the re request is made create your unique key and pass it off to the DB to then be picked up by the service. the service can then process the data without you having to worry about your threads being killed and then you can also monitor the traffic/load better with the service as well.

We have a transfer mechanism that works on a similar principle and it make this sort of stuff much simpler in the long run.

If you do need to report back the data then you just have to wait on to the finished report or data is saved to the DB and then the asp.net app can take over the rest.