We have an OWIN application running on IIS and are currently using the AppProperties(IAppBuilder.Properties).OnAppDisposing cancellation token to detect when the application is being shutdown to gracefully shutdown some of the long running tasks that we start when the application starts.
The problem is that when the web.config is modified (even if just doing a "touch web.config") then the OnAppDisposing cancellation token is cancelled and our long running tasks shut themselves down.
But the application pool is not actually recycled in these cases and so our long running tasks do not get restarted until the app pool is actually recycled.
How is one supposed to handle web.config changes in these instances? So that we can still detect OnAppDisposing and shutdown gracefully while also not have to worry about long running tasks shutting down and not getting started again?
Update: I've found that the OWIN app will get initialized again when the first http request comes in. But if there were Hangfire or other Background tasks that you expected to be running they won't be started again until that web request comes in. Even if you have application initialization setup, the appinit url is not hit after the app domain restart.
Related
I'm using a HostedService inside an ASP.NET core web api that will be deployed in an IIS instance on premise (.NET Core 2.2). I need to ensure that the idle timeout is set to zero to ensure the background service will run continuously and I believe this can be done by setting the idle timeout on the application pool to zero. This would, however, require the IIS administrator to perform this action upon setup so I was wondering if there is a way to configure kestrel with a zero idle timeout when its first configured in the CreateWebHostBuilder() method of the program class.
Is this possible?
When you use IIS as a reverse proxy for an ASP.NET Core application, IIS starts the process and that idle timeout on the app pool decides when to shut down the process. IIS knows that there are no active requests, and it will just kill the process without asking the process for permission. So there is no way for your application to stop that. (You have to be aware of that if you run any background jobs in your application - IIS doesn't know about those and could kill your app in the middle of something running)
If you run without IIS, it would never automatically shut down at all, since shutting down means that nothing is listening for new connections anymore. That's the benefit of using IIS: it can restart your application if there is a catastrophic failure.
So if you plan on keeping your application behind IIS, and you want it to never shut down, then you will have to get the settings on the app pool changed.
Is there a timeout for stopping Windows Services when Windows is shutting down? I know there is a registry key "WaitToKillServiceTimeout" but does this timeout effect on services, when Windows is shutting down or is there another timeout?
I want to find out, how long system during shutdown waits for services when it calls the OnStop method of a service.
Can a service prevent Windows from shutting down?
From TechNet:
[WaitToKillServiceTimeout] Determines how long the system waits for services to stop after notifying the service that the system is shutting down.
Then yes, that's value used to wait for services shutdown but also note that it's shared for all services:
If all services stop before this value expires, the system shuts down...
For your question "Can a service prevent Windows from shutting down?" answer is "more or less". You can't prevent Windows to shutdown (it may be really annoying for users if they can't shutdown because a service decided they shouldn't) but:
When the value of this entry expires, the system notifies the user that the service has not stopped. The user can either force the service task to stop or continue to wait. If the user waits, this value specifies the interval between repeated user notices that the service has not stopped.
Note that:
Some services increase the value of this entry to provide more time for cleanup tasks.
In case your service is slow to shutdown you may increase such value (during installation) to give you more time. In theory using a very high value you'll postpone shutdown for a very long time (but this behavior isn't same as cancel it and don't forget it's shared for all services).
AFAIK a service can't cancel shutdown but a GUI application can do it using ShutdownBlockReasonCreate() function.
In my web app on start up I have a number of threads that are currently running and do all sorts of work (such as releasing database locks, monitoring users etc). These threads are started on the application_start() event in my asp.net app.
What concerns me is if the app pool dies for some reason, these threads will not start up again until a request is made to the application (i.e. app domain loaded etc).
I was thinking about scheduling a batch process (via command line and vb-script) every 10 mins to make a web request which will ensure that my application is already loaded and running (threads will be up then).
So far I have not seen any problems with the app pool crashing so it was a precautionary measure.
I noticed my app pool currently has a default setting of 20 mins to recycle.
I was wondering if this approach is correct and I do not introduce any other problems down the road.
We are using IIS 6 so cannot use the Application warm up module which I suppose is not for app pools crashing.
If I start a thread in the Application_Startup event of my web application in ASP .NET and it contains an infinite loop doing some background work using sleep methods too, will it continue running forever, assuming no exceptions occur?
Short answer: Yes
I have the same in my Application to do some cleanup work.
EDIT:
But Jani is also right: If the App is shut down the thread also stops, but if you have requests to keep the App alive (or configure the App under IIS/Mono that way - see HERE) it will run.
.No, because IIS may shutdown your AppDomain if no request comes in for a period of time.
In shared hosting environments you can not change the appdomain settings but you have access to server it can be done by changing the default time.
IIS 7.5 introduces the notion of auto-start providers, that allow you to get WAS to auto-load an application or assemblies when an application pool starts up.
Can a similar thing be achieved with IIS7?
Basically, we have an application that runs under WAS, and has an in-memory cache of data. When an application pool recycle occurs, my WAS deployed app won't actually be activated until the first hit for it is received. This means that the cache is cold when the first hit is received. It would be good to be able to pre-start the application as soon as the app pool is recycled.
Other options we've considered are:
Deploying the application as a Windows service so it doesn't re-cycle (this would work, but the application lifecycle management of IIS/WAS is a useful thing apart from this issue)
Writing a separate service whose job is to ping our application to warm it up.
However, the nicest way would be to get IIS7/WAS to do this for us.
In Windows 2008 you can log events that occur on the application pool, so you can log recycle events.
You can configure the event viewer to start a program when a specified message has been logged. You could call your service or load the assemblies in that program.
Would this be a feasible solution for you?
Regards,
Michel
in the advanced settings of your application pool set your application pool to generate Recycle event log entry every time it is recycled; I think the option is "Specific Time". Then you can use Windows Task Scheduler, create a script or something you want it to run that will hit your site so it can initialize. Set the trigger for the task to an even, set the Event Filter that you want to trigger the task and voila.