Fire and Forget with ASP.NET MVC

Question

I'm looking for info on best practices for a fire and forget asp.net mvc action ... essentially I want a mobile client to make a call; the server start an async task; and then return to the mobile client as fast as possible.

But I want to make sure that, assuming no exceptions, the async task will complete successfully. There's obviously a few different options:

• Make a new Thread
• Queue a work item on the ThreadPool
• Begin an async delegate call
• Start a Task

I assume the Task would be the best option here, but wanted to get thoughts from SO.

Edit: to clarify based on a few of the answers already: The client doesn't need a response. I want the HTTP request to complete as fast as possible as soon as the server begins the async task. I know about async patterns on the client, however I want to limit the amount of time the mobile device needs to maintain a connection open. Also, want to avoid having a separate process which polls or is pushed a message (via queue, bus, etc.) because that's overkill. I just want to log something in a database, the client doesn't need to remain connected until that IO is finished.

Answer 1

I would recommend using an AsyncController. You should look at the AsyncController area from the sample code for Brad Wilson's Advanced MVC3 presentation, at http://bradwilson.typepad.com/presentations/advanced-mvc-3.zip

Answer 2

Cleaner fire and forget with TPL and Mvc 4

public async Task<ActionResult> Index() 
{
  // Start all operations.
  var tasks = new[]
  {
    Task.Run(() =>TestOutput.DoWork("1")), 
    Task.Run(() =>TestOutput.DoWork("2")), 
    Task.Run(() =>TestOutput.DoWork("3"))
  };

  // Asynchronously wait for them all to complete.
// Uncomment below line to not forget the results
//  var results = await Task.WhenAll(tasks);

  // Return empty string for fire and forget.
  return View(string.Empty);
} 

Answer 3

You are being contradictory

Your question title explicitly says "Fire and Forget" and then in your question you mention the opposite

essentially I want a mobile client to make a call; the server start an async task; and then return to the mobile client as fast as possible.

So, you want an async call that will send a result back, or a Fire and forget call?

---

If a normal async call, just use the jQuery .ajax() method your the same in your favorite javascript library, and hook up your return in the success property function.

---

If a fire and forget, the best way is to ask the server to insert a row in a TBL_JOBS table in the database, then you can have a recurring script that picks this up and process the information.

Answer 4

I know this is an old question, but here's my take on such things, for what it's worth, since I disagree with the accepted answer.

You don't need an AsyncController because you are not interested in waiting for your async operations to complete. So the answer to your question with respect to the MVC side of things is: it doesn't matter. You can do your work any which way and have just a regular old action that kicks off the process and returns whatever result you want.

The second part of your question is really more relevant. You want to make sure nothing is going to happen to your async tasks given that you've started them from your web process, assuming a task itself does not throw an exception. The answer to this depends on your reliability requirements.

You mentioned that you don't want a separate process, and this limits your options. Your tasks will be running in the same app domain with your web application. If anything brings down the app domain or the process, your tasks will die, potentially in a strange state. This isn't necessarily even from unhandled exceptions. IIS can be set to automatically recycle an application from time to time or in certain conditions. Or if you release new code or touch anything in the bin directory, your app domain will be torn down after all requests are finished, and a new one is started. If these cases are a show-stopper for you, then you have no choice but to move your tasks out of process and communicate with some sort of messaging.

If you are not worried about IIS killing you, you still have to worry about yourself. Unhandled exceptions from other background tasks will bring down the process if you don't last-chance handle them with the AppDomain.UnhandledException event. In the case of using the Task Parallel Library, Tasks with exceptions that you don't observe by Waiting on them or viewing the Result or Exception properties will bring down the process if you don't last-chance observe them in the TaskScheduler.UnobservedTaskException event.

A further note is that any ThreadPool threads used for your background operations will not be able to serve requests for your web application during that time. You could manage the max threads in the pool, or instead start a new Thread. Or if you're using TPL with the default scheduler, schedule the task with the LongRunning hint to effectively gain a new thread.