Scenario:
Client makes ISAPI call with POST to IIS 7.5 server - the call will generate mission critical output to be distributed to numerous users. (using Delphi XE with Indy 9 HTTP client in this case);
ISAPI process takes a LONG TIME to complete (it's threaded on the client side);
Before the POST call returns, user aborts or client machine goes down, killing client side connection and leaving the ISAPI process chugging away on the IIS 7.5 server.
Questions:
What does IIS 7.5 do with that thread, which is still executing when the client/user aborts and kills the connection?
Will the server side thread complete processing even though the client has disconnected, or will IIS 7.5 kill that thread at some point, perhaps leaving a mess in the aborted process?
Is this time dependent - depending on how long it takes for the server-side process to complete?
Can this be controlled - can I instruct IIS to complete the process even though the client has aborted? If so, how?
IIS will continue to process until completion, or until the timeout for the App Pool is hit.
You should look at using Indy's TIdHTTPServer and then you'll control the server side which will allow you to setup your own rules on how to handle a long and possibly disconnected client session instead of becoming an expert in IIS AppPool management.
Related
I am totally new in web programming... Now I am working on an already implemented ASP.NET MVC application which is deployed in IIS. This app is bound to an application pool which has only one worker process. At this moment, I am trying to understand what happens if the worker process freezes/hangs due to an uncontrolled exception thrown by app code. So may someone explain me it?
What we have observed is that when this happens, application stops working correctly and we need to restart its application pool in order to app begins to work correctly again. After observing this behavior, I have a doubt..... In application pool advanced configuration, under process model, the ping maximum response time (seconds) is set to 90 so as far as I know, when application pool pings the worker process and it does not respond because it is hang, after 90 seconds then worker process should terminate, but it seems it is not terminating because when this happens we need to restart application pool in order to app works again.... so Why in this case worker process does not terminate?
First off, you have "only" one Worker Process and should probably keep it that way. Often times Web Gardening causes more issues than it helps, particularly with .NET Apps. Second, you say it freezes/hangs due to "uncontrolled" (unhandled?) exception thrown by app code. Why do you think this is the case. Do you have an error page or something indicating its an exception? The "ping" process checks if the process is still doing work, but not necessarily finishing requests. So from the perspective of WAS, IIS is still responding.
If you want to troubleshoot, you could investigate getting a memory dump with DebugDiag and perform some automated analysis on it. https://support.microsoft.com/en-us/help/919792/how-to-use-the-debug-diagnostics-tool-to-troubleshoot-a-process-that-h
Our application is DDE enabled. It acts as a server. It has its own file type, and offers an 'Open' command.
When launching application from a right-click on a saved file (ie reading HKEY_CLASSES_ROOT-----\shell etc) we sometimes get "there was a problem sending the command to the program". Especially win10.
On problem PCs we test a VBA script that triggers our exe, waits a second, and then sends DDE commands. This works well.
We conclude we need a pause, or to increase timeout on the DDE conversation.
Can this be done?
Is there a globally effective registry setting?
Any ideas?
No, you cannot pause or increase the DDE timeout.
Instead, you should look at possible problems with your application.
It is likely that your program is starting to pump messages before your DDE server is up and running. As soon as you start handling messages, Windows assumes your DDE server is running. So, it sends you the message, but your server is not up to receive it yet. Make sure that no thread in the program is handling Windows messages before the DDE server is setup.
I have multiple servers (2012 R2 with IIS 8.5) that have shared configuration, shared vanity URL (f5 load balanced), and host several different applications. One of the applications (an ASP.NET MVC web app) is rarely used (maybe once or twice a week) but when it needs to be used, it needs to load quickly.
I've set the AppPool to have a Start Mode of "AlwaysRunning", and a Recycling -> Regular Time Interval to 0, but it seems like every time I hit the app, it takes forever to load (like 10-20 seconds) but subsequent page requests happen instantly.
Is there another setting that I need to set to keep the app warmed up? The app has Kerberos Authentication and access is limited to one security group (that I'm not even a member of), so I can't use external PowerShell scripts to manually keep it warm.
You can check to see if the application pool is running before you hit the app.
If you click on your server name in IIS then click on "Worker Processes" you'll see all the Process ID's of the different application pools and that state.
This way you can confirm the app pool is running, before you access the application. This will help you narrow down where the problem exists.
1) Is the app pool running?
2) Is my app loaded in my app pool?
If 1 checks out, then move on to step 2 and check to see if the libraries of that application is loaded up in that Process ID.
Check your event log for application pool failures.
If you have some asynchronous initialisation/maintenance task which is started in parallel with the request or with some delay and subsequently fails, it can make the request (and some afterward) succeed but kill the application pool shortly after. This would exhibit these exact symptoms.
I have an Umbraco website that I have to restart every morning in order for the users to be able to publish content. Is there any solutions available that will help me get around doing this each morning?
1 - Document why do you "have to" restart IIS every morning
like the web app can't re-establish connection with SQL
or one process gets so huge that it's obvious it's leaking
or one process heats up with huge CPU usage and IIS keeps dropping requests
etc. etc. have to check log files, EventLog, SQL Server has it's own log
2 - Document usage patters of the site
like does it sit idle for 8-10 h or is busy all night
if it's busy then log files (including IIS log) will provide some info on when a problem started
if it's idle for a long time, check that AppPool for the site has automatic recycling of worker process set say after 1h of inactivity - you can also set diferent recycling tactics
if it's SQL connection after along idle period - Kerberos ticket for the account expired.
you do have a domain account under which that AppPool runs I hope
to fix that, look at DB connection string (normally in web.config) and check MSDN for params
or bring up a new web site or app that's going to keep pinging a web method which will just do a little query ( like a count on some table) and return the result as a kind of admin heartbeat -- this helps only if you acsually see SQL connection issue
3 - Check if you have multiple sites / web apps running on the server
that each has it's own AppPool and that they run under a domain account
that each app has it's own, separate folder for logs and any other writable files
that each AppPool has recycling tactics that's good for actual usage pattern
needs different recycling tactics if it's busy all the time
ask sor some mininal kind of heartbeat web service to be developed and pinged for ops needs
running as part of each web app and using the same SQL connection
if you don't have the budget for this raise some hell
makes you feel good :-)
I have a project in asp.net mvc, my hosting is using IIS6, and the first request after the website sit's idle is very slow.
I looked at, http://forums.asp.net/t/1418959.aspx and asked the hosting for this settings.
They say that the actual settings are:
"The pool is set with Idle Timeout disabled, Rapid-fail enabled and with a single worker process."
But still slow at the first request. Do you have any other clues?
Thanks in advance,
Alfredo
You are probably a victim of worker process recycling. Ask your host how often the worker processes are recyled.
When a worker process is recycled, it has to recompile and restart the entire web application, and that's what causes the slowdown.
This is natural.
IIS is often configured to shut down the website if it's a certain age or if there hasn't been a request in awhile. Your website has to be loaded (and possibly compiled) when the first request comes after asp.net has been shut down by IIS.
The common solution is to precompile your website before publishing it to the server.
Just a guess, but perhaps you are caching some data, that needs to be refreshed after the site has been idle for some time ?
If this is not the case, then my guess would be that the worker process has been shut down for some reason (it could be for some other reason than the idle timeout in IIS). If you need to check whether this might be the case, you could add some code to the Application_Start event that logs the startup event to a file or whatever logging you have in place. After some time in operation, you can examine the logs and see, how many Application_Start events has occured.