Just realized that using the IIS 7+ Web Application recycling (defined in the Application Pool) leaves VFP exe (COM instances) running.
Turned off all automatic recycling options (ss below).
Any experience about this?
-- thn (FoxInCloud)
It shouldn't. When the Application Pool shuts down COM instances will be unloaded. Are you sure that you're not hitting the server or there are backed up requests that are restarting the instances immediately? Check the ProcIds and see if they change after the recycle.
It works for me here. In fact, it works even making a change to web.config (in Module mode) which also causes an internal AppDomain restart of the application. With the ISAPI handler recycling works, but not web.config changes.
Make sure your Application Pool account is SYSTEM or some other high rights account otherwise it won't have rights to explicitly kill the instances. Also the .NET Module will do a better and faster job shutting down, than the ISAPI handler which typically has to actually kill the process to remove them (due to ISAPI shutdown timing).
+++ Rick ---
Hi,
Just realized that using the IIS 7+ Web Application recycling (defined in the Application Pool) leaves VFP exe (COM instances) running.
Turned off all automatic recycling options (ss below).
Any experience about this?
West Wind Technologies
Making waves on the Web
from Maui
Thanks for your detailed feedback; please see my responses below.
I inadvertently saw dangling instances on our win 2012 (IIS8.0) server.
As I just moved these apps from a win2k server (without app pool and recycling), I drew the conclusion that the automatic, timed recycling was responsible for that.
I turned off recycling yesterday and no longer see any dangling instance - I'll report in a couple of weeks whether this solves the issue.
By the way, does anyone see a real interest in this recycling mechanism for wConnect applications?
Our previous win2k server always worked fine without this feature ...
I look forward to moving FoxInCloud to WC5
Yes, LocalSystem is, by default, allowed to access to any COM object (execute, activate, etc.).
You could obtain the same result with another account to which you grant the same rights by DCOM config.
In this particular case, Application Pool account is indeed LocalSystem
+++ Rick ---
Hi,
Just realized that using the IIS 7+ Web Application recycling (defined in the Application Pool) leaves VFP exe (COM instances) running.
Turned off all automatic recycling options (ss below).
Any experience about this?
I turned off recycling yesterday and no longer see any dangling instance - I'll report in a couple of weeks whether this solves the issue.
Automatic recycling of IIS Application Pools will shut down will cause a controlled shutdow which should trigger the servers to get unloaded. The behavior of that is no different than doing an application pool stop. Just make sure your App Pool is running high enough rights to be able to kill the instances (if you're running the ISAPI component - the .NET component will exit more cleanly from within the app and that what I highly recommend is used on Windows 2008 and later).
By the way, does anyone see a real interest in this recycling mechanism for wConnect applications?
Our previous win2k server always worked fine without this feature ...
Yes I think it's a useful feature especially if you're running the ISAPI component and COM. The COM system in IIS unfortunately is somewhat flakey and if there are hard COM failures/disconnects over time there are small memory leaks that end up raising memory and can over time make COM loading unstable. Recycling IIS occasionally (like once a day maybe) can drastically help with this.
This is much less important for the .NET Module as it doesn't rely on COM marshalling to manage the thread pool and as such provides a much cleaner architecture. But regardless, it seems that apps tend to grow in memory size and handles eventually and an occasional recycle to 'clean house' is useful. Again infrequent recycles are a good idea if less critical for the .NET module but I have it on all my app pools at once a day in the early morning hours.
I notice in your App Pool config you have the Idle Timeout set - you should turn that off or to a really large value - that will also shut down the appDomain if the application is not accessed. And I suspect with many low volume bus apps this actually hits more frequently than the recycling timeout.
+++ Rick ---
Hi Rick,
Thanks for your detailed feedback; please see my responses below.
I inadvertently saw dangling instances on our win 2012 (IIS8.0) server.
As I just moved these apps from a win2k server (without app pool and recycling), I drew the conclusion that the automatic, timed recycling was responsible for that.
I turned off recycling yesterday and no longer see any dangling instance - I'll report in a couple of weeks whether this solves the issue.
By the way, does anyone see a real interest in this recycling mechanism for wConnect applications?
Our previous win2k server always worked fine without this feature ...
I look forward to moving FoxInCloud to WC5
Yes, LocalSystem is, by default, allowed to access to any COM object (execute, activate, etc.).
You could obtain the same result with another account to which you grant the same rights by DCOM config.
In this particular case, Application Pool account is indeed LocalSystem
+++ Rick ---
Hi,
Just realized that using the IIS 7+ Web Application recycling (defined in the Application Pool) leaves VFP exe (COM instances) running.
Turned off all automatic recycling options (ss below).
Any experience about this?
West Wind Technologies
Making waves on the Web
from Maui
I'll monitor memory usage, test a daily recycling and remove timeout
I turned off recycling yesterday and no longer see any dangling instance - I'll report in a couple of weeks whether this solves the issue.
Automatic recycling of IIS Application Pools will shut down will cause a controlled shutdow which should trigger the servers to get unloaded. The behavior of that is no different than doing an application pool stop. Just make sure your App Pool is running high enough rights to be able to kill the instances (if you're running the ISAPI component - the .NET component will exit more cleanly from within the app and that what I highly recommend is used on Windows 2008 and later).
By the way, does anyone see a real interest in this recycling mechanism for wConnect applications?
Our previous win2k server always worked fine without this feature ...
Yes I think it's a useful feature especially if you're running the ISAPI component and COM. The COM system in IIS unfortunately is somewhat flakey and if there are hard COM failures/disconnects over time there are small memory leaks that end up raising memory and can over time make COM loading unstable. Recycling IIS occasionally (like once a day maybe) can drastically help with this.
This is much less important for the .NET Module as it doesn't rely on COM marshalling to manage the thread pool and as such provides a much cleaner architecture. But regardless, it seems that apps tend to grow in memory size and handles eventually and an occasional recycle to 'clean house' is useful. Again infrequent recycles are a good idea if less critical for the .NET module but I have it on all my app pools at once a day in the early morning hours.
I notice in your App Pool config you have the Idle Timeout set - you should turn that off or to a really large value - that will also shut down the appDomain if the application is not accessed. And I suspect with many low volume bus apps this actually hits more frequently than the recycling timeout.
+++ Rick ---
Hi Rick,
Thanks for your detailed feedback; please see my responses below.
I inadvertently saw dangling instances on our win 2012 (IIS8.0) server.
As I just moved these apps from a win2k server (without app pool and recycling), I drew the conclusion that the automatic, timed recycling was responsible for that.
I turned off recycling yesterday and no longer see any dangling instance - I'll report in a couple of weeks whether this solves the issue.
By the way, does anyone see a real interest in this recycling mechanism for wConnect applications?
Our previous win2k server always worked fine without this feature ...
I look forward to moving FoxInCloud to WC5
Yes, LocalSystem is, by default, allowed to access to any COM object (execute, activate, etc.).
You could obtain the same result with another account to which you grant the same rights by DCOM config.
In this particular case, Application Pool account is indeed LocalSystem
+++ Rick ---
Hi,
Just realized that using the IIS 7+ Web Application recycling (defined in the Application Pool) leaves VFP exe (COM instances) running.
Turned off all automatic recycling options (ss below).
Any experience about this?
-- thn (FoxInCloud)