1

So I have inside MVC controller method the following code :

public ActionResult ProcessFile () 
{
    ThreadStart threadStart = new ThreadStart ( ()=>{

        // Doing some long processing that takes 20 minute 
    } );

    Thread thread = new Thread(threadStart); 
    thread.Start();
}

The problem here is that when more than one request sent to this controller method the thread get killed. I need to Thread to stay working untill the processing ends , and it seem it is a matter of resources the much resources get taken the less threads can stay working . If I run the process from windows application or service it works perfectly , it is only having problem when it get started from web application .

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
sino
  • 754
  • 1
  • 7
  • 22
  • if an object... say `thread` goes out of scope it can be garbage collected. I would highly suggest using `Task` for things like this as you don't need to hold onto a reference to it. – Mgetz Jul 18 '13 at 14:19
  • I used Task , and for some reason Tasks get canceled frequently more than Thread,even when I was attributing the Task as (long running ). – sino Jul 18 '13 at 14:22
  • Are you trying to access any of the ASP.net context on that thread? – Mgetz Jul 18 '13 at 14:23
  • nop , all the process do is analyzing the data and storing them in csv file . – sino Jul 18 '13 at 14:26
  • is an exception being thrown in that thread? – Mgetz Jul 18 '13 at 14:27
  • the server clock go to 50-70% sisnce it is all calcualtions and few IO (to the csv file ). – sino Jul 18 '13 at 14:27
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/33707/discussion-between-mgetz-and-sino) – Mgetz Jul 18 '13 at 14:28

2 Answers2

6

Ideally you should not create threads (for long running background jobs) off web requests in IIS 7.

The threads will be stopped should the app pool/AppDomain restart, which could happen for a number of reasons such as changes to the contents of the bin folder, changes to web.config, a period of inactivity, a resource threshold is reached (e.g. memory usage). In fact the AppDomain will restart periodically by default for no other reason than it has been alive for x amount of time.

For this reason long running tasks should be implemented using a job queue and background job runner, e.g. console app or windows service (importantly, not running in the context of IIS), processing those jobs.

The web request should simply add the job to the queue allowing the background job runner to pick up the jobs as they appear.

A similar question has been answered here Can I use threads to carry out long-running jobs on IIS?

Edit: A seriously not recommended alternative

If you insist or have no alternative but to run the background job in the IIS process, you need to look at allowing the background job to be spontaneously stopped, and allowing it to restart from where it left off when it was stopped.

You can have a URL which can be polled to trigger the restart of unfinished jobs.

I have seen this work in the past, the implementation will vary in complexity based on what the background job entails.

You will find the server may begin to have performance issues as background jobs are started and killed repeatedly.

Community
  • 1
  • 1
danielfishr
  • 879
  • 6
  • 9
  • when the process is running CPU go up to 70% due to calculations . on my local IIS it never fail I can process a lot of requests , the process just go slower but never fail. In Cloud server the threads get killed after the 2nd or 3rd one . – sino Jul 18 '13 at 14:45
  • What is most likely happening is the cloud server (azure/appharbor?), will be configured to restart the AppDomain when you are using too many CPU cycles or memory. This will be to ensure quality of service to other apps running on the hardware. – danielfishr Jul 18 '13 at 14:48
  • Good point , another reason to mark this question as answered – sino Jul 18 '13 at 14:54
0

While the answer above is acceptable, there is some merit to having long running service like tasks hosted in your web app.

Rick Strahl has a blog post about it here: Use-IIS-Application-Initialization-for-keeping-ASPNET-Apps-alive

Community
  • 1
  • 1