[ASP.NET MVC 2] Handling timeouts in asynchronous controllers

An important feature of the ASP.NET MVC framework is the possibility of creating asynchronous controllers. As in Asynchronous Pages in ASP.NET 2.0, the aim is to avoid a “thread starvation” in your web application, preventing web clients to receive a bad 503 status code (Server too busy). In fact, when the Web Server receives a request, a thread is taken from the application threadpool mantained by the .NET Framework. In a synchronous scenario, this thread lives (and can’t be reused) until all the operations complete. Well, asynchronous pipeline is better when the logic creates bottlenecks waiting for network-bound or I/O-bound operations. Considering that an asynchronous request takes the same amount of time to process as a synchronous request, minimizing the number of threads waiting for blocking operations is a good practice, particularly appreciated by your Web server when it’s bombarded by hundreds of concurrent requests. Now, have a look to this simple asynchronous controller:

public class CustomersController : AsyncController

{

   [AsyncTimeout(10000)]

   public void ListAsync()

   {

     AsyncManager.OutstandingOperations.Increment();

     Task.Factory.StartNew(() =>

     {

       try { AsyncManager.Parameters["result"] = new MyServiceClient().GetCustomers(); }

       catch (Exception ex) { … }

       finally { AsyncManager.OutstandingOperations.Decrement(); }

     );

   }

 

   public ActionResult ListCompleted(List<Customer> result)

   {

     return View("List", result);

   }

   …

      

   protected override void OnException(ExceptionContext filterContext)

   {

     if (filterContext.Exception is TimeoutException)

     {

       filterContext.Result = RedirectToAction("TryAgainLater");

       filterContext.ExceptionHandled = true;

     }           

     base.OnException(filterContext);

   }   

}

By default, ASP.NET MVC won’t call the ListCompleted method until the AsyncManager associated with the request says that there is no outstanding asynchronous operations. But it’s possible that one or more asynchronous operations might never complete!!! Moreover, if the callback for one of your asynchronous operations throws an exception before it calls the AsyncManager.OutstandingOperations.Decrement() method, the request will keep waiting a decrement until it times out! So, putting the AsyncManager.OutstandingOperations.Decrement() call inside a finally block would be fine :).
The AsyncManager object has a built-in default timeout set to 45 seconds, so if the count of outstanding operations doesn’t reach zero after this long, the framework will throw a System.TimeOutException to abort the request. If you want to set a different timeout you can use the AsyncTimeout filter for specifying a different duration. If you want to allow asynchronous operations to run for an unlimited period, then use the NoAsyncTimeout filter instead.

Finally, we have to say that most applications will have an ASP.NET global exception handler that will deal with timeout exceptions in the same way as other unhandled exceptions. But if you want to treat timeouts in a custom way, providing a different feedback to the user, you can create your own exception filter or you can override the controller’s OnException() method (e.g. to redirect users to a special “Try again later” page).