tracker issue : CF-3811806

select a category, or use search below
(searches all categories and all time range)
Title:

ColdFusion 11 IIS Connector Fails to Respond when Application Pool Returns from Idle

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Jake Hand / Jake Hand (Jake Hand)

Created: 08/25/2014

Components: Installation/Config, Connector

Versions: 11.0

Failure Type: Performance Issue

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Major / Most users will encounter

Locale/System: ALL / Win 2012 Server x64

Vote Count: 0

Problem Description: 
When there are multiple sites in IIS that use a single CF-to-IIS connector (using the 'All Sites' option within wsconfig) apps that go into idle mode do not always come back online properly upon receiving activity. Requests to the site will just load indefinitely and never pass the request on to CF.

When checking one of the affected w3wp.exe processes in Process Explorer, it shows two mutexes for the connector - the first has the path to the connector's DLL in the mutex name, and the second has the name of the site in the mutex name. The mutex that has the path to the connector DLL in its name shows that it has multiple handles open, yet the other mutex only has one open handle. 

On a CF 10 server, however, Process Explorer shows the w3wp.exe process only has one mutex for the connector and it is named after the site. That mutex only shows one handle to the file. A screenshot is attached showing these results.

It appears that the 1st mutex that exists for each site is causing syncronization problems for the w3wp.exe processes. 

Steps to Reproduce: 
1) On a Windows Server with ColdFusion, create multiple sites in IIS -- each with their own application pool. (For the sake of testing, try decreasing the idle timeout to 1 or 5 minutes.)
2) Add a simple CFM file to each test site, then access the file in each site. 
3) Wait until the idle timeout passes, then try to access the sites again. When we've done this test in our environment the site fails to respond properly and requests just load indefinitely. Other sites on the server that have not gone idle will continue functioning though. 

Actual Result: Site will not respond; the request is not forwarded to CF.

Expected Result: Site should respond and the connector should forward the request to CF.

Any Workarounds:
Killing the w3wp.exe process for the site will allow the application pool to come back online, and the site will start responding again. 
Restarting IIS will also allow the site to begin responding. 
Disabling the idle timeout would also help, but this is not a viable option in our environment.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3811806

External Customer Info:
External Company:  
External Customer Name: jakefusion
External Customer Email:  
External Test Config: My Hardware and Environment details:

- ColdFusion 11 64-bit

- Windows Server 2012 (64-bit)

- IIS 8 running on same server as CF 11

Attachments:

  1. August 26, 2014 00:00:00: 1_cf-connector-mutexes.png

Comments:

We were unable to repro this bug with the provided information, on Windows 2012 R2 As per our observations, sites do get served after the application pool returns from idle, but with a certain delay. The delay itself is in the scope of an other bug. A duplicate iis worker process entry (with the DLL path) in Process Explorer was also not to be found. Could you please provide more information on the settings / configuration changes on the machine, 1) The OS where this issue is seen 2) Number of sites configured with the All Sites option 3) Within the WSConfig tool, were setting such as, Maximum number of connections to reuse / timeout for idle connections modified?
Comment by Immanuel N.
11228 | August 27, 2014 01:48:58 AM GMT
Here is the info you requested: 1) This has been observed on Windows Server 2012 Standard. 2) There are 160 sites configured with the "All Sites" option. Most of these sites are not very active. 3) Here are the worker.properties settings for the "All Sites" connector: worker.list=cfusion worker.cfusion.type=ajp13 worker.cfusion.host=localhost worker.cfusion.port=8014 worker.cfusion.connection_pool_timeout=60 worker.cfusion.connection_pool_size=150 worker.cfusion.max_reuse_connections=15 What's interesting is if we configure a site with its own connector, it tends to prevent the problem on that site. However, we'd prefer to use one connector for ease of management.
Comment by External U.
11229 | August 28, 2014 12:58:14 PM GMT
One more thing...I've been able to easily reproduce the issue with duplicate worker processes by manually recycling an application pool.
Comment by External U.
11230 | October 07, 2014 04:44:59 PM GMT
Immanuel, updating to CF 11 Update 2 and upgrading the connector fixed this issue in our environment. Thanks!
Comment by External U.
11231 | October 30, 2014 11:40:44 AM GMT
Thanks for the update, jakefusion! This bug was fixed in the CF 11 Update 1. Closing the bug as Fixed.
Comment by Immanuel N.
11232 | October 31, 2014 02:03:40 AM GMT