Entries Tagged as 'Connector'

Nginx is a high-performance and open-source web server that is widely used in the web communityIt can now be configured with ColdFusion 2016. With this post we are making available the prerelease build of the web-server connector for testing purposes. 

The prerelese build is in the form of an Linux 64-bit installer that packages the following 2 components:

- The Nginx web server installer. This installer is a variant of the standard Nginx installer that packages the AJP modules that enbable the communication between the webserver and ColdFusion.

- WSconfig.jar. This is a modified version of the library present in ColdFusion's <cf_root>/cfusion/lib directory, that is required by the WSConfig tool when configuring a web server connector. 

For detailed instructions on installing the webserver and configuring the connector, refer this document.  

We will look forward to your suggestions and feedback.


This blog post talks about a few scenarios related to connector misconfiguration and ways to handle them. The most common scenarios discussed in this article are

  • Connectors that are created for ALL and individual websites at the same time.
  • Multiple attempts to add/remove the connectors during configuration.

As a best practice, remove the connector using the WSCONFIG utility. Once the connectors are removed, verify that there are no residual files/settings/configuration remains, using the steps mentioned below. (WSCONFIG Utility location: \ColdFusion\<instance>\runtime\bin)

Consider a scenario where, upon launching the WSCONFIG utility, you see the following dialog box:

In this scenario, configuration conflict might occur, since the same connector is created for both ALL and individual website (for this case).

Follow the below steps to fix the connector misconfiguration:

  1. Remove both the connectors one by one, as shown in the below image. Select the connector and click “Remove”.

  1. In the dialog below, click “Yes” to continue.

  1. You can see that the first connector is now removed.

  1. Repeat the process for the other connectors. In this scenario, there are only two connectors.
  2. Launch IIS Manager.
  3. Click on any website (in this case, CF11) and double-click Handler Mappings.



  1. Manually remove all the ColdFusion handlers as shown below (if present):


  1. Navigate to “CF11” website and double-click ISAPI Filters.



  1. Remove “tomcat” entries (if any), as shown below:


  1. Repeat steps “-6-” to “-9-”, for all the sites with duplicate or corrupted connector settings.
  1. Navigate to the IIS Server home and double-click Handler Mappings.



  1. Remove all ColdFusion handler entries (if any), as shown below:


  1. Navigate to IIS Server and double-click on ISAPI Filters



  1. Remove entries for tomcat if any as shown below:



  1. Navigate to IIS Server and double-click ISAPI & CGI Restrictions.


  1. Remove all entries of tomcat as shown below:


  1. Once all the above entries have been verified and removed, launch the command prompt as Administrator (or with elevated privileges) and run IISRESET.

  1. Run the WSCONFIG utility to recreate the connector and test your website


ColdFusion (2016 release) has a webserver configuration tool for creating connectors with external web servers. These connectors work with Apache and IIS webservers. You can create one single connector (ALL) to run with all your websites or create individual connectors (ALL-Individually) for each website. We have seen scenarios, where users use “Virtual Host” to run multiple websites on a single server, in Apache.

In this blog, we will see, how to configure ColdFusion connector to work with multiple Virtual hosts in Apache and map the virtual hosts with individual instance of ColdFusion.

Note: - This blog is written, in context of Apache being installed in an RHEL environment.


Scenario 1:  Configuring connector to run with multiple Virtual hosts

Unlike IIS, we don’t have the option to select multiple websites, when we run the Web Server Configuration tool or WSCONFIG tool. To achieve this, we will have to create a connector with Apache, which will have multiple websites (Virtual hosts).  Assuming that we have already installed ColdFusion (2016 release) and Apache, we shall go ahead and create the connectors with Apache.

To create a connector in ColdFusion (2016 release) with Apache in RHEL, please follow the below:

  1. Navigate to cf_root/cfusion/runtime/bin
  2. Enter the command

sudo ./wsconfig -ws Apache  -bin /usr/sbin/httpd -script /usr/sbin/apachectl -dir /etc/httpd/conf/ -v

Note: The above command assumes pre-configured Apache in RHEL environment, command line switches and path for binaries may change across different flavors of Unix (Reference article).

Once you have created the connector successfully, ColdFusion creates a file mod_jk.conf in the location /Apache_root/conf/ (/etc/httpd/conf/ in this example).

To configure the connector and run multiple Virtual hosts, copy the JKMountFile path entry from mod_jk.conf file and add it to each of the Virtual Host blocks. For example, refer to the screenshot below:


Add the entry JkMountFile "/opt/coldfusion2016/config/wsconfig/1/uriworkermap.properties" and add it to each Virtual Hosts in /etc/httpd/conf/httpd.conf, as highlighted below:


Scenario 2: Configure Apache virtual host for each ColdFusion instance

Consider the scenario where you have three virtual hosts that need to be run independently, and are not to be served by a single instance of ColdFusion.

To achieve this, you require three instances of ColdFusion server. Each server instance has separate settings. For example, let there be three instances of ColdFusion servers Instance1, Instance2, and Instance3 to be configured with three virtual hosts Website1, Website2, and Website3 respectively.

  1. Create the connector with Instance1 using the command (mentioned in Scenario 1). This step creates the connector-related files in the cf_root\config\wsconfig\1 folder.
  1. Add the server names to worker list in workers.properties located in cf_root\config\wsconfig\1 folder. Add Instance1, Instance2, and Instance3 to the parameter worker.list.

  1. Add the configurations below for each instance of server in workers.properties file:

For server Instance1



For server Instance2



For server Instance3




Note: Instance* is the AJP/1.3 port number associated with individual server instance that can be found in server.xml at cf_root\instance_name\runtime\conf\.



  1. Create the file uriworkermap.properties for each instance of ColdFusion at the location cf_root\config\wsconfig\1. In this example, you require three copies of uriworkermap.properties file (name it as - uriworkermap1.properties, uriworkermap2.properties, and uriworkermap3.properties).

4.1 Copy the content of uriworkermap.properties in cf_root\config\wsconfig\1 to uriworkermap1.properties, uriworkermap2.properties, and uriworkermap3.properties.

4.2 Replace the instances with the corresponding servers: –

  • In uriworkermap1.properties, all the entries for server name will become “Instance1” (Screenshot 1),
  • uriworkermap2.properties will have “Instance2” as server name (Screenshot 2)
  • uriworkermap3.properties will have “Instance3” as server name (Screenshot 3).


Screenshot 1:


Screenshot 2:




  1. Define the URI mappings associated with each server instance in virtual host configuration to run the websites independently.

To run Website1 on server instance "Instance1", add the JKMountFile path as mentioned below in virtual host configuration (/etc/httpd/conf/httpd.conf):

JkMountFile "/opt/coldfusion2016/config/wsconfig/1/uriworkermap1.properties"

Notice that uriworkermap1.properties file contains URI mappings for Instance1.

Similarly, add the JKMountFile path for Website2 and Website3 that contain URI mappings for server instances "Instance2" and "Instance3".

Add the path in Website2:

JkMountFile "/opt/coldfusion2016/config/wsconfig/1/uriworkermap2.properties"

Add this path in Website3:

JkMountFile "/opt/coldfusion2016/config/wsconfig/1/uriworkermap3.properties"


Now, go ahead and verify your setup and website.



  • Any changes made to connector files requires an Apache restart for the changes to take effect.
  • Any changes made to httpd.conf file within Apache, requires an Apache restart for the changes to take effect.



Important update: Note that ColdFusion 10 and 11 have been updated to support Windows 10, a couple months after this blog post was first written. Consider applying that update rather than this manual configuration.


With Windows 10 out, there is a problem that most of the ColdFusion customers will face, configuring connectors for IIS 10. Wsconfig, the connector configuration tool, only supports till IIS 8.x. While the ColdFusion team is working on this issue and will try to provide the fix for it as soon as possible, there is already a KB article which can be referred for configuring the connectors manually. Although the article was originally written for CF10, it can be used for CF11 also. After following all the steps in the article, you need to do one more thing. Add index.cfm as default document for your website in IIS.

This solution is only recommended for development environments as thorough testing of the connectors with IIS 10 is still going on. So for production machines, you should wait for the actual release from Adobe.

Sometimes there is a requirement to know the realtime load on a ColdFusion Server. One way to get this information is through cfstat which displays the relevant information at CF server/Tomcat level. One more way to get this information is through Status worker which displays the information at Webserver/Connector level. 

A status worker is a special type of worker which does not communicate with Tomcat. Instead it gathers configuration and load details from other workers and displays it. It can also be used to change some details dynamically. Configuring a status worker is pretty straightforward. After the connectors are successfully configured with wsconfig tool, we need to change worker.properties and uriworkermap.properties to enable status worker. In worker.properties, add a new worker:



In uriworkermap.properties, add a uri mapping to this worker:

/cf/status = cfstatus

Restart the webserver.

Now whenever a request comes at http://WebserverIP:Port/cf/status, it will be redirected to this status worker which will display the relevant information based on the query parameters in the request. Some of the common parameters are:


  • mime: Specifies the output format. If someone is running a script to get status information and parse it, the value should be xml. If its only used for display purpose, then it should be html.
  • cmd: Specifies what action you want to perform. list displays details of all the configured workers. show displays information of a specific worker.
  • w: Specifies name of the worker. It should be used along with cmd=show.
  • sw: Specifies name of subworker if w referred to a lbworker.
  • opt: Specifies which information should not be displayed. It is bitmask of desirable options. The allowed values are:

0x0001: hide members of lb workers

0x0002: hide URL maps

0x0004: hide the legend (Works only with html)

0x0008: hide load balancer workers

0x0010: hide ajp workers

0x0020: only allow read_only actions for a read/write status worker.

0x0040: hide load balancer configuration  (Works only with html)

0x0080: hide load balancer status summary (Works only with html)

0x0100: hide configuration for ajp and load balancer member workers (Works only with html)


So to get details of cfusion worker, an example url will be:
http://IP:Port/cf/status?mime=html&cmd=show&w=cfusion&opt=262 (0x0002 | 0x0004 | 0x0100)

Status worker can also be used to modify some config parameters dynamically. If someone doesnot want that functionality, it can be configured in read-only mode also. Just add the following line in worker.properties:

For all the configuration parameters and query parameters refer to the following document: