5

Concerns:

I have read through posts/blogs that describe IIS could recycle the app pool at any time. Does this mean (in terms of IIS recycling app pool) it would not matter if I make a call to a long running process synchronous or asynchronous, as IIS could recycle the app pool and terminate the long-running process? If this is the case, what are common paths to make sure this does not happen?

Example

public Task<ActionResult> LongRunningProcessAsync(SubmitFileModel aModel)

    {
        return Task.Run( () => LongRunningProcess( aModel) );
    }
Luke G
  • 367
  • 1
  • 4
  • 20

2 Answers2

4

HostingEnvironment has a static method, RegisterObject, that allows you to place an object in the list of registered objects for the application.

According to Phil Haack...

When ASP.NET tears down the AppDomain, it will first attempt to call Stop method on all registered objects....When ASP.NET calls into this method, your code needs to prevent this method from returning until your work is done.

Alternatively, you could create a service that is not hosted by IIS.

barry
  • 835
  • 6
  • 14
0

If this is the case, what are common paths to make sure this does not happen?

Your application domain will be unloaded on recycling process, with or without using the RegisterObject method. It only gives your background work some time to complete (30 seconds by default). If you have long-running job that exceeds this "some time", it will be aborted, and no one will care about automatic retry on restart.

If you want to run long-running jobs in your ASP.NET application, want to keep things simple, and forget about ASP.NET/IIS issues, look at HangFire – it uses persistent storages (SQL Server or Redis) and have immunity to the recycling process.

odinserj
  • 954
  • 9
  • 21