Prerelease build of Nginx connector for ColdFusion 2016 now available

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.

Click on this link to download the source for the Ngnix Connector.

Revision (09 Jan 2017): The download link for Ngnix Connector source added.

 

 

Removing Corrupt Connector Dependencies from IIS

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>runtimebin)

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

 

Configuring connectors with Apache Virtual Hosts in ColdFusion (2016 release)

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_rootconfigwsconfig1 folder.
  1. Add the server names to worker list in workers.properties located in cf_rootconfigwsconfig1 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

worker.Instance1.host=localhost

worker.Instance1.port=8017

For server Instance2

worker.Instance2.host=localhost

worker.Instance2.port=8018

For server Instance3

worker.Instance3.host=localhost

worker.Instance3.port=8019

 

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

                          

 

  1. Create the file uriworkermap.properties for each instance of ColdFusion at the location cf_rootconfigwsconfig1. 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_rootconfigwsconfig1 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:

 

Screenshot3:

 

  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.

 

Note:

  • 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.

 

Setting up ColdFusion in distributed envionment

You might want to set up ColdFusion in a distributed environment where ColdFusion is running on one machine and Web server is running on a different machine.

Following are the set of steps that have to be performed to achieve this (less error-prone):

This applies to both ColdFusion 10 and ColdFusion 11.

1) Have ColdFusion server installed in a machine.

2) Next thing is to download and install VC Runtime.

             – The version of VC Runtime that you have to install depends on the version of ColdFusion.

                Say, ColdFusion 11 needs VC Runtime 2012

                 (32-bit VC Runtime for 32-bit Web server and 64-bit VC Runtime for 64-bit Web server.

                  If you are not sure, you can install both)

                 (https://www.microsoft.com/en-in/download/details.aspx?id=30679)

                and ColdFusion 10 needs VC Runtime 2010

 

3) Copy the following contents from the machine where ColdFusion is running to the machine where Web server is running at the same location.

 C:ColdFusion11jre

 C:ColdFusion11runtimelibwsconfig.jar

 C:ColdFusion11runtimeconfserver.xml

C:ColdFusion11configinstances.xml

C:ColdFusion11configcluster.xml

 

4) Open a Command prompt and run wsconfig tool

   C:ColdFusion11>jrebinjava -jar cfusionruntimelibwsconfig.jar

    It will open a configuration window where you have to provide AppServer Host as the ColdFusion Server IP.

    Configure the connector.

Distributed environment is ready for use. Send requests to the Web server's URL with cfm files under web server root and same files under ColdFusion's Web root.

Web server would redirect these to ColdFusion, which is on some other machine.

 

 

Resolving “500 Internal Server Error” with ColdFusion 10 Update 14

We have seen that some of you have not been able to get the web server
connector working after applying update 14.

We did our investigation and following is our finding.

The connector binaries of ColdFusion 10 update 14 are built on top of  VC++
runtime 2012 update 4.

Installation of VC++ runtime requires admin privileges. If the ColdFusion
service runs as administrator or system account, the update itself install the
VC++ runtime as this account would have installation privileges.

If your ColdFusion service account is not running as administrator or system
account, applying the hotfix from administrator can’t install VC++ runtime and
you will get “500 internal server error” after configuring the
connector.

In this case, you need to manually install VC++ runtime 2012 32-bit and/or
64 bit depending on whether Web server is 32-bit or 64-bit.

You can download VC++ runtime here at:

http://www.microsoft.com/en-in/download/details.aspx?id=30679

When you install hotfix manually, administrator privileges are enforced and
so the installation of VC++ runtime is automatically taken care by the updater.

Normal
0

false
false
false

EN-US
JA
X-NONE

 

 

 

 

ColdFusion 11 IIS Connector Tuning

Connector tuning is an essential part of setting up a ColdFusion server. There are various configurations in connector that needs to be tuned. Incorrect values may lead to “Service Unavailable” or “Server too busy”. In this blog, we will discuss how to handle such errors caused by incorrect tuning and how to tune the connectors for the site correctly.

The connector setting may vary from site to site. It is very important to configure the connectors for your application appropriately. This blog will include connector tuning parameters for IIS. During installation, user can choose to configure connector for “Individual Site” or “ALL” sites in IIS connector configuration.

Configure Web Server

After the installation, the user can launch the “Web Server Configuration tool” and has the availability to create the connector for “Individual Site” or “ALL” sites in IIS.

Add Web Server configuration

When connector is configured with individual sites, separate connector for each site will be placed under {CF-Home}/config/wsconfig/{some no}/. Similarly for “ALL” configuration the connector is configured at global level, which means the same connector binary will be used across multiple sites.

The three most important parameters will be discussed here and will help us to understand the role of the same:-

  • Reuse Connections
  • Connection pool size
  • Connection pool timeout

Re-use connections: – This setting determines the count of connections that can be re-used. When Tomcat connector makes a connection with Tomcat server, it does not closes the connection even after it finished serving the request. Instead it keeps the connection active, so that for the next request, the same connection can be re-used. This increases the performance by minimizing the overhead of creating new connection with tomcat server for every request. This settings needs to be tuned for connector configured with multiple sites. The max value for the re-use connection is determined based on the number of sites configured with same CF server and the load on each site.

The default re-use connection is 250.

Connection pool size: – This setting determines the maximum number of connections that can be created in the connection pool. When multiple requests arrive to the connector from IIS, connector creates new connections in the connection pool only if there are no free connections available in the pool. The connector will not create a new connection if connections reach the connection pool size limit. When connector is configured with “ALL” sites, the same connection pool will be used to serve the request for all sites. So the default value of the connection pool size, works well with the single site configuration, but fails to work well with “ALL” site configuration in some scenarios. Hence this value should be increased carefully based on the need and number of sites that are present within IIS.

The default connection pool size is same as, which is 250.

Connection pool timeout: – This setting determines the timeout value (in seconds) for idle connections in connection pool. This value must be in sync with the connectionTimeout attribute of your AJP connector in Tomcat's server.xml.

The default timeout for connection is indefinite, if not set in server.xml explicitly.

There are other parameters which CF connector inherits from Tomcat AJP connector. Please find the details of those settings from AJP documentation (http://tomcat.apache.org/connectors-doc/reference/workers.html)

The worker.properties is available at {CF-Home}/config/wsconfig/{some no}/ and the server.xml can be found at {CF-Home}/cfusion/runtime/conf/. Below are the changes required to tune the Site:-

  • Open the worker.properties file, add below line as new entry worker.cfusion.connection_pool_size=500 (This is connection pool size inside connector which are available to handle request)
  • Tune the entry for max_reuse_connections to appropriate value based on number of site. Optimal value is connection_pool_size / {no of site}
  •  Add another entry in new line worker.cfusion.connection_pool_timeout=60 (This value is idle connection timeout (in seconds), when sites are not under load connections will be recycled back to IIS)
  • Now open the server.xml from {cf-home/cfusion/runtime/conf}, add/update the maxThreads=500 and connectionTimeout="60000" to connection node containing the AJP entry.
    <Connector port="8012" protocol="AJP/1.3" redirectPort="8445" tomcatAuthentication="false"/>

  • Now the AJP entry in server.xml should look like 
    <Connector port="8012" protocol="AJP/1.3" redirectPort="8445" tomcatAuthentication="false" maxThreads="500" connectionTimeout ="60000"> </Connector>

 

 

 

There can be multiple use cases. Let us consider three most widely used scenarios:-

  •  Connector created with “ALL” OR with “Individual” Site and single site in IIS
  • Connector created with “ALL” and multiple sites in IIS
  • Connector created with “Individual” site and multiple sites site in IIS

 

 

Use Case# 1: Connector created with “ALL” OR with “Individual” Site and single site in IIS

In an idle scenario, where the user has only one site (configured with ALL or individual connector) and not running under high load, the worker.properties, can look like this

worker.list=cfusion

worker.cfusion.type=ajp13

worker.cfusion.host=localhost

worker.cfusion.port=8012

worker.cfusion.max_reuse_connections=250

worker.cfusion.connection_pool_size=500

worker.cfusion.connection_pool_timeout=60

And server.xml should look like

<Connector port="8012" protocol="AJP/1.3" redirectPort="8445" tomcatAuthentication="false" maxThreads="500" connectionTimeout ="60000"> </Connector>

So, we added the connection_pool_size and connection_pool_timeout (in seconds) in the worker.properties. The corresponding connectionTimeout (in milliseconds) is added to server.xml along with maxThreads whose value is equivalent to the connection_pool_size in the worker.properties.

Use Case# 2: Connector created with “ALL” and multiple sites in IIS

Consider a scenario that the connector is created with “ALL” and there is only one site which is running under load. The default 250 re-use connections are utilized by site 1. Later on, the user adds another site in IIS.

Site 1 will make all 250 re-usable connections with ColdFusion and any request for new connection from site 2 will be ignored by ColdFusion. Hence it is required, to increase the re-use connection count to optimal value, so that site 2 does not starve for new connections. This can be achieved by configuring optimal value of max_reuse_connections count. Considering that the site 2 is not running under high load, 100 re-use connection will work. So the max_reuse_connections becomes 350 {250 (for site 1) + 100 (for site 2)}. But, it is a good practice, to start tuning the connection_pool_size first, and then the max_reuse_connections appropriately.

This case would require connection_pool_size=700, as max_reuse_connections= connection_pool_size / {no of site}. So, the worker.properties will look like this

worker.list=cfusion

worker.cfusion.type=ajp13

worker.cfusion.host=localhost

worker.cfusion.port=8012

worker.cfusion.max_reuse_connections=350

worker.cfusion.connection_pool_size=600

worker.cfusion.connection_pool_timeout=60

And server.xml should look like

<Connector port="8012" protocol="AJP/1.3" redirectPort="8445" tomcatAuthentication="false" maxThreads="700" connectionTimeout ="60000"> </Connector>

Note: The connectionTimeout is in milliseconds

Use Case# 3: Connector created with “Individual” site and multiple sites site in IIS

Consider a scenario that the individual connectors are created for each site. There are three sites – Site 1 is running under high load, site 2 and site 3 running are under low load. For all the sites, there are individual connectors. Now, ideally in this scenario, we should start tuning with the site running under high load first. We can disable the timeout for high traffic sites, if we are not sure for timeout. If not defined, the default timeout for connection is indefinite. To start with, don’t specify the re-use parameter. Set the connection_pool_size=500 and monitor the site. Gradually increase the value by 100 and likewise, till the site is stable. Say, at connection_pool_size=800, the site is stable. Now, set the max_reuse_connections=270 (connection_pool_size / {no of site} i.e. 800/3=270 approx)

Site 1

worker.list=cfusion

worker.cfusion.type=ajp13

worker.cfusion.host=localhost

worker.cfusion.port=8012

worker.cfusion.max_reuse_connections=270

worker.cfusion.connection_pool_size=800

worker.cfusion.connection_pool_timeout=60

Site 2 and site 3 are running under low traffic, but are bind to same ColdFusion instance (cfusion in this case). The below settings should be optimal:-

Site 2

worker.list=cfusion

worker.cfusion.type=ajp13

worker.cfusion.host=localhost

worker.cfusion.port=8012

worker.cfusion.max_reuse_connections=100

worker.cfusion.connection_pool_size=250

worker.cfusion.connection_pool_timeout=60

Site 3

worker.list=cfusion

worker.cfusion.type=ajp13

worker.cfusion.host=localhost

worker.cfusion.port=8012

worker.cfusion.max_reuse_connections=100

worker.cfusion.connection_pool_size=250

worker.cfusion.connection_pool_timeout=60

And server.xml should look like

<Connector port="8012" protocol="AJP/1.3" redirectPort="8445" tomcatAuthentication="false" maxThreads="1300" connectionTimeout ="60000"> </Connector>

Note: The connectionTimeout is in milliseconds and the maxThreads is the value equivalent to summation of all the connection_pool_size(s). So, in this case maxThreads=1300 {800 (for site 1) + 250 (for site 2) + 250 (for site 3)}.

Some key points to remember:-

  • The connector tool should always run with “Run as Administrator” feature, even if the user is from the Administrator group i.e.

    Using the command line:-

    Connector Tool cmd

    Using the GUI

    Connector Tool gui
     

  • Any changes made to {CF-Home}/config/wsconfig/{some no}/, including isapi_redirect.dll or worker.properties, would require an IIS restart.
  • Any changes made to {CF-Home}/cfusion/runtime/conf/server.xml requires “ColdFusion 11 Application Server” service restart.
  • max_reuse_connections should always be less than or equivalent to connection_pool_size. It can’t be larger than the connection_pool_size.
  • The above use cases are scenario based and may vary from site to site, depending upon the load, architecture and traffic on the site.