Take the tour ×

I'm wondering if the following code has any gotcha's that I'm not aware of when running on a webserver. Reading through the excellent series http://reedcopsey.com/series/parallelism-in-net4/ I am unable to find anything that relates specifically to my question, same with the msdn, so I thought I'd bring it here.

Example call:

public ActionResult Index() {
    ViewBag.Message = "Welcome to ASP.NET MVC!";

    Task.Factory.StartNew(() => {
        //This is some long completing task that I don't care about
        //Say logging to the database or updating certain information

    return View();
share|improve this question
Related: stackoverflow.com/questions/3994085/… –  Jon Galloway May 2 '11 at 20:16
Thanks for that link Jon. One avenue I hadn't considered but is obvious to me now is the They can die at any time due to the AppPool being recycled comment in the question. Definitely something I have to think about. Though I don't think it would matter that much given I'm not that concerned about them –  BuildStarted May 2 '11 at 20:26
add comment

3 Answers

up vote 3 down vote accepted

ASP.Net supports asynchronous pages, see Asynchronous Pages in ASP.NET, but is a complicated programming model and does not bind at all with MVC. That being said, launching asynchronous tasks from a synchronous requests handler works up to a point:

  • if the rate at which requests add new tasks exceeds the average rate of processing your process will crash eventually. The Tasks take up live memory and eventually they will fill up the in memory queues where they're stored and your will start getting failures to submit.
  • .Net Taks are inherently unreliable as they lack a persistent storage, so all tasks that are submitted async must be threaded as 'abandonware', ie. if they never complete there is no loss to the application nor to the user making the request. If the task is important, then it must be submitted through a reliable mechanism that guarantees execution in the presence of failures, like the one presented in Asynchronous procedure execution.
share|improve this answer
ASP.NET MVC supports Asynchronous Controllers (msdn.microsoft.com/en-us/library/ee728598.aspx) but I don't think they're appropriate for this fire-and-forget type task. –  Jon Galloway May 2 '11 at 20:15
They're intended to be abandon calls. I'm wasn't really concerned with whether or not they complete but wanted to be reasonably sure they would. –  BuildStarted May 2 '11 at 20:30
add comment

One important thing in this case is to ensure that the code contained inside the task is wrapped in a try/catch block or any possible exceptions thrown in this thread will propagate. You also should ensure that in this long running task you are not accessing any of the Http Context members such as Request, Response, Session, ... as they might no longer be available by the time you access them.

share|improve this answer
I was just testing with that by manually throwing an exception and didn't see them bubble up. However, it did bubble when not in asp.net. –  BuildStarted May 2 '11 at 20:27
add comment

Use new Thread instead of Task.Factory.StartNew. Task.Factory.StartNew use thread from Threads Pool and if you will have many background tasks a Threads Pool will run out of threads and will degrade your web application. The requests will be queued and your web app eventually will die :)

You can test is your background work executed on Thread Pool using Thread.CurrentThread.IsThreadPoolThread. If you get True then Thread Pool is used.

share|improve this answer
add comment

Your Answer


