I know that any threads that I've started will forcibly be terminated when the application pool is recycled or stopped, or when the process exits. I also know that IIS is not designed or intended for long running tasks.
Consider the following in Global.asax
protected void Application_Start(object sender, EventArgs e)
{
_worker = new Thread(Run);
_worker.IsBackground = true;
_worker.Start();
}
private void Run()
{
while(true)
{
Thread.Sleep(50000);
WorkWork.BeHappyTo();
}
}
Given that the process and application pool is not in any way shutting down, is there any other mechanism in IIS that could terminate my _worker
thread, yet still continue to serve new request, as though nothing has happened?
I'm looking for any mechanism that monitors for threads not related to requests, CPU time, clock time, etc, and terminates them based on some set of heuristics.
No, your thread is safe for as long as the app domain lives. Terminating random parts of your app would not be a good design for a web framework. In fact there is no .NET API to enumerate all threads (thank god).
You need to handle errors, though, because an error will terminate the thread. Usually, logging them and continuing is the right approach. The logs should be looked at.
I find it to be a safer and easier pattern to have time-based scheduling outside of the application. Make a cron call a secret URL every 5 seconds.