When does IIS spin up a new child worker process? - worker-process

Platform: Windows Server 2016
Website: Default website using https
Custom app pools - 4 - one used as the default for our application[
Recycle settings: default
We have an issue with our web servers, where occasionally the existing worker process stops processing requests. But for whatever reason, IIS does not spin up a new worker process. The net effect is that the web server is dead in the water.
Is it possible that the existing process is not terminated until a new child process successfully announces itself?
This problem only occurs in the app pool that our application creates, and uses as the default app pool. (The other worker threads probably don't do enough to run into this situation)
The attached screenshot taken from our monitoring shows the server doing nothing, until we manually intervened and recyled IIS.

Related

IIS .Net Website hangs even after restart IIS/Machine

I have a .Net application hosted in IIS 10 running on Windows Service 2019. Sometimes the website stops responding (usually when running E2E tests). Even after restarting Website/Application Pool/IIS/Machine it doesn't work.
Looking in Event Viewer I see errors like these:
Forms authentication failed for the request. Reason: The ticket supplied has expired
Failed to stop a listening channel for protocol 'http' at allotted time from worker process serving application pool
A process serving application pool exceeded time limits during shut down
In HTTPERR files I see a lot of messages containing Connection_Abandoned_By_ReqQueue and Connection_Dropped
In inetpub log files I can't see any relevant, just the url requests.
To add more information, we have signalr installed and sometimes errors appear in the events, errors with messages like:
The user identity cannot change during an active SignalR connection.
Any idea what might be causing this?

Whether the Default App pool crashes and shut down will affect other App pools running in the same farm / IIS?

We have Windows 2003 Server IIS 6.0 and Windows 2008 Server IIS 7.0
Issue : In IIS 6.0, when Default App pool crashes it shut down other App pools as well.
Whether the Default App pool crashes and shut down will affect other App pools running in the same farm / IIS ?
Other Pools
One pool can affect other in this cases.
Lock some global resource that the rest need to access and all pools gets time outs.
Eat the servers power with bad loops.
Each pool have their space that work aside from the other, so general speaking you need to look for what they have common, like if you use session database and the one locks it for long time, and the other is gets time outs many time together with the first one and fell also on Rapid-fail protection.
Pool it self
The pool is connected with many apps, so when this pool crash, is affect and all apps/web sites that are connected with this.
When this is a problem.
When the pool crash many times and is felt on the "Rapid-Fail Protection" that make the pool to permanently shut down.
When some site is keep the pool inside a loop that eats all resource of it and the power of your server.
here is an example : How do I crash the App Pool?
For the first case you must go to your pool and turn off the "Rapid-Fail Protection". For the second case you need to locate the problem and isolate.
More to read:
Rapid Fail Protection
Configuring Rapid-Fail Protection
IIS app pools, worker processes, app domains

"Application pool 'XXXXXXXXXX' is being automatically disabled due to a series of failures in the process(es) serving that application pool."

We have a ASP.NET/WCF app hosted in Window Server 2012 (IIS 7). We used the basicHttpBinding. This ASP.NET/WCF application exposes two methods; one is to receive messages and the other is to download a text file (1MB) onto the server.
On another server, we have ASP.NET hosted in Window Server 2012 (IIS 7) which is the client that consumes the exposed method mentioned earlier. This client application sends a message and uploads a text file at a high frequency. This communication between this ASP.NET/WCF application and client application works fine for a few hours until we get the following error at the ASP.NET/WCF side.
Application pool 'XXXXXXXXXX' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
So, could you please shine some light regarding this issue that we are facing?
This is due to something called "Rapid Fail Protection." When your underlying application crashes a certain number of times in a certain time period, the application pool is automatically disabled.
The default settings are 5 crashes in 5 minutes, but you can configure this yourself. See this link for details.

Net.Msmq Binding Not Picking Up Messages in Queue as soon as the application pool gets recycled

"when the application pool is "alive" the service picks up the messages correctly, but as soon as the application pool gets recycled (because of timeout or any other reason), the service stops picking up the messages, that just sit
in the queue until the service starts again by browsing to the service webpage"
Have you find a solution, to activate the service without manualy browse the service.
The solution is to configure auto-start. Then IIS will start your service immediately without waiting for the first request.
But first you need to add AppFabric to your ISS, then you need be sure you have the "Start Mode" option in your pool advance settings.
Note: In my windows 7 IIS7 didnt work, but in my windows server 2012 R2 IIS8 Works perfectly
Also you can check this similar question:
MSMQ WCF hosted in IIS

Asp.net "background service" listening to MSMQ not working after IIS site is stopped/started

We've implemented a "background service" in our Asp.Net web app that receives messages from MSMQ at random intervals without requiring an HTTP request to start up the application. We auto start this web app using a serviceAutoStartProvider.
Everyhing works when IIS initially starts up, the server is rebooted and so on, we receive messages just fine. BUT if we just stop the site in IIS (not touching the application or app pool), the application stops receiving MSMQ messages. And when we start the web site again, the serviceAutoStartProvider is not called again, so our app does not start listening to MSMQ messages again!
If we issue a HTTP request against the web app after the IIS site has been stopped and started again, it starts listening to MSMQ messages again.
Shouldn't our "background service" web app continue to listen to MSMQ messages even if the IIS site is stopped? It won't get any requests, but I think it should continue to run.
What exactly happens in an Asp.Net application/app pool when the IIS site is stopped? Any events fired that we can hook up to? The app pool claims to be "started" in IIS manager, but code is not running in it.
Why isn't our serviceAutoStartProvider called when the site is started again? I believe it is "by design", since the application isn't really stopped. But the applications isn't running, either, has to be waken up by an actual HTTP request.
When the IIS Web App shuts down (eg. due to no new HTTP(S) requests for the timeout time) the .NET app domain (within the app pool worker process) completely closes and unloads. This includes all background threads, including those used by the .NET thread pool.
A Web App can be configured with a longer (or no) timeout, then background worker threads could continue to process work.
But better would be to either run such workers in a specialist service process managed completely separately.
Or, even better, use IIS application hosting with WCF to create the MSMQ listener. I understand in this case the integration of Windows Process Activation Services with IIS would restart the Web App if a new message arrived after it had been shutdown.
I would host the MSMQ listenner in a windows service. Why couple it to IIS?
UPDATE
Actually what I mean is why couple the MSMQ and ASPNET in the same app pool?
You can now use "Application Initialization" feature of IIS8 (and IIS7.5), more information including version availability and usage documentation can be found at:
http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization
This replaces "Application Warm-Up Module" which is no longer supported, and provides us with proper control over component/service initialization in an "always running" scenario.

Resources