I have a WCF Service hosted in IIS 7.5 that is responding to the first soap message posted to it after inactivity with a 404 Error.(It works around 15 seconds after that...it is likely waking up after that initial ping.)
In investigating this issue I have:
-Prevented App Pool Recycling by setting the Idle Time-out to 0 and the recycling time interval to 0
- Attempted to enable the app warmer by installing Microsoft's App Inititializer and
amehrots app initializer ui for iis 7.5. Using this I set the application pool to always running and preloaded/preinitted my service.
- Installed http://keepalive.codeplex.com/ to run through the metabase and hit the service with activity.
While the service is active following an iis restart, it still appears to sleep after a period of inactivity. I am currently looking into reliable sessions and whether tweaks can be made to the web.config. Any further guidance would be appreciated.
There is an idle time setting on the Application pool.
The default is 20 mins, if there is no Activity for 20 mins the app pool is released from memory. The first Call after that will trigger a load and JIT compile of the code.
You can stop the shutdown by setting the idle time to 0.
I decided to give up on my attempts at an elegant solution and ended up adding a windows service to send a web request to each of the urls that I needed to keep alive.
Related
I have ASP .Net core webapi deployed on IIS 7.5 (Windows 2008 R2). I have controllers as well as listener classes (which wait for a message to arrive on a RabbitMQ message) which perform the same functionality.
The problem is whenever webapi is deployed on IIS or has some idle time, the RabbitMQ messages don't get picked up. Only if I make a API call to the control does the application 'wake up' and picks up the message.
Tweaks I have tried:
In the application pool,
set 'Idle timeout' to 0 .
set the 'Disable Overlapped Recycled' to true.
set 'Disable recycling for configuration changes'.
I have no idea what is causing this. I need the application to pick up messages immediately and have no idle time. Could anyone please point me in the right direction?
As a complete workaround, you can keep your app alive by sending requests all the time. In my case, I don't even have access to changing IIS settings.
To send requests I use Availability feature in Application Insights -- it lets you create tests that send GET requests to your app as often as every 5 minutes. You can read more about it here.
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 a new .netcore web app deployed to a windows server 2008R2 IIS instance, and after the app has been idle for a while, it's slow upon first load, and then subsequent requests are super fast.
In previous versions of .net I changed the Idle Time-out property of the app pool in IIS to 0 to fix this issue. Is there a similar setting somewhere with .netcore, perhaps something I've missed I could add to the Startup.cs file?
How about setting up the Application Pool Idle time on IIS?
Also make sure the recycling settings are unchecked
Baring there being a legitimate fix as I am unfamiliar with .netcore; writing a route which returns an HTTP 200 or something as a heartbeat and then calling it from a scheduled task every X minutes(idle - 1) would prevent the application from ever idling and thus keep it from slowing down requests.
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.
I have a WCF Service Deployed on IIS. (BasicHTTPBinding with [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)])
I have built custom in-memory session management and Now I am facing a strange problem that is IIS 7 Restarts Automatically without even throwing any kind of warning or error not even in EventLog. This problem leads to destroy the all available sessions.
I discovered this issue after logging the Application_Start and Application_End methods using log for net and also i put the break point in application_start and it paused there in between test execution.
This happens rarely but i need to know why it happens and if it is normal and acceptable or not. if not then what may be the possible reasons of this.
Regards
Mubashar Ahmad
Could it be the app pool being re-cycled? IIS 6 has this set on by default to 1740 minutes. As for IIS 7 I guess you would have the same kind of setting? I know in IIS 6 this "event" is not logged as 'n error.
IIS recycles worker processes either when it detects an "unhealthy" process, or after certain operator-configurable limits are reached.
Among the limits are:
memory threshold
after a configured number of requests
elapsed time
time of day
more info
The Session timeout (which is separate to the app pool recycling) is set to 90 minutes by default, this is set at the application level. This also means anything being held in Session will be blown away at that time. You can set it via the properties of the virtual directory/application in IIS6, and via SessionState->Open Feature in IIS7 (when you have the application selected).
Also note that session timeout can be set via the web.config of an ASP.Net application, should your web services be hosted in one of those.