Why not use polling threads with ASP.NET web applications?

Often developers ask how to add polling, scheduled tasks and so on to ASP.NET web applications. There are many ways how to do it and there are even more reasons why not to do it. Let’s see what are the problems and how to build services for your web applications wherever they run.

IIS and web applications

IIS is the host of web applications. It knows how to handle requests and what modules to invoke to turn request to response. There are ASP.NET, PHP, PERL and many more applications available and IIS doesn’t know much about their specifics. In this means IIS is layer up from web applications running under it.

IIS also takes care of application pools, web server security, resource management and performance. Of course, we can configure IIS by our needs but not always – there are shared hosting and corporate environments where we don’t have much control so we have to live under technical limits that environment sets.

Polling threads

The classic example is something like this:

public class MvcApplication : HttpApplication
{
    private static Timer _timer;
 
    protected void Application_Start()
    {
        _timer = new Timer(MyCallback);
    }
 
    private static void MyCallback(object state)
    {
        // do something
    }
}

Now let’s see what happens when we try to add our polling thread to web application.

Application unloading

After deploying our web application to server we can admit that application and specially our polling thread works okay. Even after some hours everything is okay but then in the evening suddenly we get a call because somebody noticed that polling doesn’t work anymore. We take a look at application and see that polling works. Also guy on the phone agrees that yes, it is working. What happened?

Your web application is considered to be active until it serves requests. After some idle time IIS considers your web application to be inactive and it unloads it from memory. The fact that your timer thread was active and something went on is not the problem of IIS because web applications are there to handle requests coming from web.

Of course, you can set IIS not to unload your application but you can do it onlyif you have access to IIS settings. Don’t be sure that administrators of shared hosting services make your application never unload.

Tombstoning aka suspending

Lately support for tombstoning of web applications was announced by Microsoft. What it means? Web application is not classically unloaded from memory but its memory image is saved to disc. When request comes in then this memory images is loaded back to memory and your application continues running.

Tombstoning of applications is way faster than loading and unloading. In near future this feature will probably be in mainstream use as it provides performance raise of web server up to 70% by Microsoft documents. Don’t expect hosting companies to ignore this feature.

As tombstoning also happens on IIS level then again it is possible you don’t have control over it. As tombstoning also means that your application stops working then you can be sure that your polling thread goes down too.

I can still keep my application running!

Yeah, it’s not a problem to write service that makes request to web application after every minute and this way guarantee that web application is never loaded or tombstoned. Your polling timer thread runs until your service is up and has connection to internet.

With solution like this you are far from stable and you have more things to worry about. Is my service running? Does it have network connection? Can it reach web application? Can I be sure that my service is asking resource that is handled by script engine in IIS?

Whatever hacks you do you cannot be sure that these hacks are solution.

What is the solution?

The best solution is to understand that web application is there to handle requests and it is not by nature like Windows service or task scheduler. Instead of mixing conceptually different functionalities to container that is perfect fit for only one context doesn’t end up well and you are far away from stability. Worse yet, mixing contexts may end up performance optimizing trap – if you improve performance of code in one context then code in the other context may lose a lot in performace.

Use Windows services or Windows task scheduler if you need to poll or run tasks regularly. You can add simple web service to your web application if data is needed by service and you don’t have to go and mess with web server settings. If your code is correctly layered then you can later move web services code to another web project and run in independetly of web application that serves your users.

For short, don’t mix contexts together and don’t hack. Use right tools for your job and you get way better and stable systems. Let web applications serve requests and let services do their job in their context.