Multithreading with ASP.NET and IIS

Question

We have a web application that needs to process a large amount of data and display messages on a number of MSMQueues. This operation will probably take more than 10 minutes, but we want to get a response back (consisting of an identifier) ​​quickly. Therefore, we implemented a system that generates an identifier and starts the push process in a separate thread, and then returns the identifier.

This works fine, but our only problem is restarting IIS. We did some testing, and IISRESET kills the worker thread, even if our thread has not completed the message queue. Ideally, we would like to translate IIS so that our thread continues to run until it is complete.

Passing the / NOFORCE switch to IISRESET does not seem to be affected.

Does anyone know how we can guarantee that IISRESET waits for our workflow to complete its processing before restarting IIS.

Thanks,

Steve

Answer 1

IIS is not the place where you have to perform long-term tasks like this. We have very similar requirements when we need to start long-term maintenance tasks on our web servers. These jobs are launched through the web service and then transferred to the Windows service. While the Windows service is still alive, we can request tasks for their progress. This means that our long-term tasks can withstand IISRESET .

IISRESET almost all or nothing and insensitive to the .NET threads that you use in your ASP.NET application.

The /NOFORCE should tell IISRESET not to force reset IIS if the service does not respond within one minute. IISRESET does not know your .NET applications and will kill your application.

Update:

To answer the question in Steve's comment: "How do you recommend transferring data to the Windows service from IIS?" What you need to do is run the .NET Remoting application or WCF in the Windows service and transfer the data / messages using Named Pipes (only if intra-automatic calls are required).

Answer 2

I would suggest that if you do not require a response from the stream that I accept, you do not, you put it in the queue on your db, and then create a service to process the queue. When the re request is created, create your unique key and transfer it to the database, and then get this service. the service can then process the data without worrying that your threads are dead, and then you can also control traffic and load using the service.

We have a transfer mechanism that works on a similar principle, and ultimately it makes this material a lot easier.

If you need to report the data back, you just need to wait until the finished report or the data will be saved in the database, and then the asp.net application can take care of the rest.