While deploying changes to WCF Service, the app-pool is stopped. Hosted on IIS8. Messages are queued by MSMQ, however we are concerned that in-process services will fail when the app-pool is stopped. Does anyone know if the app pool is stop is smart enough to allow current processes to finish prior to shutting down?
Related
I m trying to deploy a never ending message pump to process service bus queue messages as a .NET Core console app on Azure AKS Kubernetes.
The app will have auto-scaling based on the number of message in the queue, so more app may be deployed and when started they will connect to the service bus and start RegisterMessageHandler.
The auto-scaler may also teardown the app but without an event to signal the shutdown to the Console app I won't be able to close the queue properly to stop receiving messages or stop processing messages.
How does one handle that in .NET Core on AKS?
There are two signals available on Pod shutdown. The PreStop hook can be configured to trigger a shell command or generate an HTTP request against your container. You should also expect your running process to receive a TERM signal prior to the pod stopping.
Here's a blog post which covers some basics on hooking the TERM signal by implementing IApplicationLifetime within the context of a Kestrel server.
This article has a thorough end-to-end example of a simple implementation of IApplicationLifetime.
For .NET 3.x, IHostApplicationLifetime supersedes IApplicationLifetime.
We have an application pool dedicated to a WCF service that is called infrequently (maybe 15-20 times per day). The calls can take several minutes, however, and the other day we got burned when IIS recycled the app pool while the call was still processing because the shutdown timeout ran out.
We're considering using request limit recycling, instead, but my question is this: When the application pool recycles "after x requests", is that after the xth request completes? Or does it kick off the request, start the overlapped process to handle new requests, then subject the xth request to the same shutdown timeout that currently burns us?
Question in a similar vein:
How to detect if the current application pool is winding up in IIS7.5 and Asp.Net 3.5+
Check your Shutdown Time Limit setting on the app pool.
Regardless of how you do the recycling, this setting is checked to determine how long a request is allowed to carry on for before being forcibly shut down.
When an app pool is recycled, IIS attempts to drain the running requests from the app pool first, and then a in the meantime a new app pool is already started which accepts new requests. By making the setting high enough to accommodate your long running requests, you will allow IIS to safely drain the old app pool.
I recommend you do the following.
1- Create a bool Ping() { return true;} method under your WCF service.
2- Create an IIS web application responsible of polling the Ping() method. This is the only way i found to keep my WCF services alive.
3- WCF long running operations must be called also from another background IIS process (web app) that must read from a message queue and call the WCF operation. So you need to log the WCF long running operation call requests in queues. This way, you will have the possibility of retrying the call if the app pool where your WCF services are hosted shuts down.
I have to implement long running process which is starts via request to the wcf method (not start proces when application start)
I now that this is wrong solution, better will be windows serwis or something else for long running process, but for my situation it is impossible. I have to use wcf servis hosted on IIS.
I read about appdomain recycled and I can't figure out thing about Idle Timeout - appdomain restart if request run over 20 minutes. I know that this issue appears when is started background task in application start.
So will be my appdomain kill when (idle timeout is setup 20 minutes).
it is start one long running request, and after that will be not another request.
When process is started in application start IIS nothing knows about this task and this is for me clear that in this situation appdomain is closed
Does after 20 minutes IIS kill appdomain, besides that eier request still running ? I am confused, because IIS know about still running request and mayby does not do this.
What is true ?
Yes, IIS will kill the process because it works on a rolling horizon of requests, not what is running. A way around this might be to have the web service request itself while it is running to continually ping the server to let it know that it is still running. But on the whole, IIS will kill its processes when no requests are coming in.
Taken directly from MSDN: The worker process shuts down after it finishes processing its existing requests, or after a configured time-out, whichever comes first.
In your case, if your process is longer than the timeout, your process will never finish.
Does recycling the IIS7 application pool kill any currently executing requests? Or does it wait for all requests to complete (like a drain-stop)?
I don't want the recycling rules to cause intermittent errors from my WCF sites.
Thanks
No.
By default, the WWW service
establishes an overlapped recycle, in
which the worker process that is to be
terminated is kept running until after
a new worker process is started.
This is from the Documentation for IIS6 and I am sure it applies for IIS7.
If your web service requests are long-running, you might consider increasing the shutdown timeout.
Yes. Recycling an application pool causes the WWW service to shut down all running worker processes that are serving the application pool, and then start new worker processes.
This is from the Documentation for IIS6 and I am sure it applies for IIS7
I have a WCF Service that I have written, which is hosted within a Windows service. It is operating in PerSession mode. The service permits clients to open files, make changes to files and close files remotely through the service. So far all works very smoothly.
When the Windows service is stopped, I would like to be able have the WCF Service not accept any new sessions and yet allow already connected clients to complete their current sessions and work (within a reasonable period/timeout).
What would be the best way to accomplish this?
Basically, calling ServiceHost.Close() will accomplish this - it will let all currently running request run to completion, but new request are being rejected will the orderly shutdown is in progress.
There's a "CloseTimeout" setting on your binding that you configured for your service - that controls how long the WCF runtime will allow running requests to take until they've properly shut down. If that timeout happens, the still running requests will be killed.
The ServiceHost.Abort() method on the other hand is the digital equivalent of a sledgehammer - all running requests are terminated at once, and the host is shut down.
ON the client side, you have the same .Close() and .Abort() methods on your client proxy which behave the same way.