The long-term goal of ASP.NET. Topic aborted

Question

ASP.NET 3.5 webapp should run several tasks that take several hours to complete. For obvious reasons, the pages that run these tasks cannot wait for them to complete, and no one wants to wait a long time for an answer, so tasks must be asynchronous.

There is a helper class to handle all these long-running tasks. The main method that plans and performs these tasks currently looks like this:

public static bool ScheduleTask(TaskDescriptor task, Action action) { bool notAlreadyRunning = TasksAsync.TryAdd(task); if (notAlreadyRunning) { Thread worker = null; worker = new Thread(() => { try { action(); } catch(Exception e) { Log.LogException(e, "Worker"); } TasksAsync.RemoveTask(task); workers.Remove(worker); }); workers.Add(worker); worker.Start(); } return notAlreadyRunning; } 

In earlier implementations, we used the ThreadPool.QueueUserWorkItem approach, but the result was always the same: after aprox. 20-30 minutes Thread interruption stops.

Does anyone know why this is happening? or how can it be prevented?

Additional Information:

• Standard IIS configuration.
• Tasks can be any, queries to the database and / or I / O, etc.

UPDATE: Solutions

Thank you all for your answers. Now I do not know what question the answer should be noted. All of them are valid and are possible solutions to this problem. Wait today and mark as the answer to the answer with the most votes, in case of a tie I will choose the first answer shown, as a rule, they are ordered by most relevance.

For those who want to know the solution that I choose, again due to time constraints, there was a change in the configuration of IIS utilization, but what I consider to be the ideal solution based on my research and, of course, the answers below, is to create " Worker Service "and using the communication solution between the ASP.NET App and the new" Worker Service "to coordinate long-term work.

Answer 1

You can run a lengthy process in your own application domain.

In the past, when I needed this feature, I create a Windows service for this purpose. If you use WCF to connect to it, you don’t even need to run it on an IIS machine; You can run it on any computer on the network.

Answer 2

Most likely, you can make it work by increasing the timeout using another application pool or many other hacks, but it is best to separate the long-term task from ui and asp.net completely, and use either a service (not recommended) or a scheduled task which is a survey for work; I personally would like to use something like aws sqs / sns to keep track of the work in progress and a scheduled task on a Windows server that checks what needs to be done at any frequency. The only thing ui / asp.net needs to do is to register the fact that something needs to be done, rather than actually doing it.

Another advantage of this message-based approach is that the long process becomes so long that it is too overloaded with work, you will have the opportunity to add additional work tasks or servers to fulfill these requests.

Perhaps more than you can realize for your immediate problem, but something for a better long-term solution.

Answer 3

Phill Haak has a deep understanding of this issue. Dangers of implementing duplicate background jobs in ASP.NET . "Hope this helps.