0

I'm building a web application in Asp.net. I have long-running tasks that may or may not get finished, as IIS tends to kill long running tasks.

Problem? Nope. I use quartz to periodically restart tasks that die (as changes get saved in the DB, so all we need to do is restart the thread).

But now I'm trying to build my web-application to support scaling out. I'd like to run multiple instances.

So, to handle my long running tasks, I'm thinking of adding a column to my database to note which instance has 'checked out' a given task. However, I'll need to know when the thread dies so that I can make sure it's 'checked in'.

So how do I check when a thread dies?

Scuba Steve
  • 1,541
  • 1
  • 19
  • 47
  • What happens if the AppPool recycles while a thread is running? There are multiple issues with this type of approach that are broader and more complicated than your question. – David L Jan 20 '17 at 21:19
  • Since you're already using Quartz I would suggest running your long running tasks there. Web applications aren't supposed to do that kind of work. – David Libido Jan 21 '17 at 00:16
  • I can't really do that because I'm dealing with an external service that sends HTTP callbacks to my web server, which changes our data and how the long running task needs to run. – Scuba Steve Jan 21 '17 at 00:19
  • Did you consider the `QueueBackgroundWorkItem` with `finally` block? I think it will solve your case. – VMAtm Jan 21 '17 at 12:56
  • So I'm already using QueueBackgroundWorkItem, and I had considered a finally block, but if you'll see the conversation below, the other fellow doesn't seem to think finally is guaranteed to run. – Scuba Steve Jan 21 '17 at 21:16
  • David Libido - I ended up taking your approach. I got rid of all the complex threading stuff and just ran some checks every so often that executes tasks that are waiting. All the states are in the database so that should work with multiple instances doing work at the same time. – Scuba Steve Jan 23 '17 at 23:53

1 Answers1

0

IIS does not kill threads, it kills AppDomains. The only way I know would be have it write a entry as a heartbeat signal while it is running. If the heartbeat has stopped the thread died.

Scott Chamberlain
  • 124,994
  • 33
  • 282
  • 431
  • I am using an existing library, called Quartz. http://www.mikesdotnetting.com/article/254/scheduled-tasks-in-asp-net-with-quartz-net – Scuba Steve Jan 20 '17 at 21:25
  • Sorry, overlooked that, the first paragraph is still relevent. – Scott Chamberlain Jan 20 '17 at 21:29
  • I found this one. http://stackoverflow.com/questions/8173570/how-to-know-if-thread-execution-is-terminated What do you think of using finally? Do you think finally will get called if IIS kills the AppDomain? – Scuba Steve Jan 20 '17 at 21:37
  • @ScubaSteve as i mentioned in my comment above, this approach still won't protect you from something like an AppPool recyle that aborts everything in memory including your thread, preventing the finally block from being called. – David L Jan 20 '17 at 21:40
  • Do you think the instance ID will change if the AppPool is recycled? I'm thinking I could have instances be responsible for tasks they have checked out, and use my Quartz implementation to check if the task has been orphaned by the instance. *edit* which is how it kindof works already, minus the instancing – Scuba Steve Jan 20 '17 at 21:42
  • So the Instance ID's will change as the underlying Virtual Machines move around. So we can't be guaranteed an task won't get orphaned. However there's a way to get all the running instances of an azure app. I think between this and with my Quartz task scheduler, I should be able to find any orphaned tasks and make sure they get restarted. – Scuba Steve Jan 20 '17 at 22:03