Entries Tagged as 'General'

With ColdFusion 11 Update 3, we have introduced a new parameter called "getHeaders", in the "cfExchangeMail" tag. It accepts a boolean value. When set to true, cfExchangeMail returns a query with an additional "InternetHeader" column. This column contains a struct containing key-value pairs of the email-headers associated with each message.

Email message headers provide technical details about the message, such as who sent it, the software used to compose it, the version of the MIME protocol used by the sender etc. 

On Exchange 2010, the fields that are returned are: CC, Content-Transfer-Encoding, Content-Type, Date, From, MIME-Version, Message-ID, Received, Return-Path, Subject, To, X-MS-Exchange-Organization-AuthAs, X-MS-Exchange-Organization-AuthSource, X-Mailer.

You may reference this weblink for the detailed list of the fields and their description.

You can put this new feature to any good use that suites your purpose. I will dwell on one such use case below.

In MS Exchange 2010 and later, the "ToId" column in the retrieved messages query contains the primary email address of the sender. A primary email address can have multiple aliases. If you need to retrieve the email-alias the message was sent to, you can make use of this new attribute.

Here's an example that demonstrates the usage the tag in the context of the use case discussed above:

<cfmail from="#frm_usr_email#" to="#to_usr_alias#" cc="#cc_usr_alias#" subject="#msg_sub#"  server= "#exchangeServerIP#" port = "25">

----------- testing mail to an alias address ------------


<cfset sleep(5000)>

<cfexchangeConnection action="open" username ="#to_usr#" password="#password#" server="#exchangeServerIP#" serverversion="#version#" protocol="#protocol#" connection="excon">

<cfexchangemail action="get" name="usr_msgs" connection="excon" getheaders=true folder="Inbox">

<cfexchangefilter name="fromID" value='#frm_usr#'>

<cfexchangefilter name="subject" value="#msg_sub#">


<cfif usr_msgs.recordcount GTE 1>

info from cfexchangemail fields:<br>

<cfloop query="usr_msgs">







info from cfexchangemail.internetHeaders fields:<br>

<cfloop query="usr_msgs">


#ReplaceList(usr_msgs.internetHeaders["from"][1], ">,<", ",", ",", ",")#<br>

#ReplaceList(usr_msgs.internetHeaders["to"][1], ">,<", ",", ",", ",")#<br>

#ReplaceList(usr_msgs.internetHeaders["cc"][1], ">,<", ",", ",", ",")#<br>





You can reference the bugbase, for the enhancement request originally logged for this feature.

Many times you would want to tweak the performance of the ColdFusion server or want to debug the bottlenecks that make the server unresponsive.

To analyze this, ideally you would want to have Thead dumps and Server memory snapshot(Heap Space, Eden Space, Survivor Space, Old Gen, Perm Gen).

While you can use JDK tools like jstack to get the dumps, it is tedious to install it and schedule the thread dumps.

So, programmatically thread dumps and memory snapshots are are triggered and can be configured as a scheduler task and can be triggered on-demand as well.

Download the following zip file and move it to the server where you want to take thread dumps.



This zip file contains two files. One is threaddump.jar file.

Place this file under: C:\ColdFusion11\cfusion\wwwroot\WEB-INF\lib\ and restart the server for it to load.

And the other file is the cfm file takethreaddump.cfm where the call to ThreadDump class is made and the path where the dump content should be written.

By default it is dumped to the file #GetTempDirectory()#/threaddump<Day>-<Month>-<Year>.log

(Depending on the server location it translates similar to C:\ColdFusion11\cfusion\runtime\work\Catalina\localhost\tmp\threaddump12-8-2015.log)

You can change this to any other convenient path in the cfm file.

You can call this cfm on-demand at point of time or configure a new scheduled task to schedule it at some interval.

More number of Thread dumps are more helpful for problem analysis. So, it is better to take at some interval.

On every new day, dump is rotated automatically to a new file name.


tools.jar contains the utilities to compile java source into class files.

While using ColdFusion Web services stubs have to be generated.

So, this utility is required for this feature to be functional.

The tools.jar is shipped by default with ColdFusion along with full installation of ColdFusion which would be same version of the jre that ColdFusion is shipped with.

If you are just using this default installation and the built-in jre, your ColdFusion web services do work fine.

However, due to security bugs or platform support you would want to update the jre version that ColdFusion runs on.

Once you do that, please make sure to copy the tools.jar file manually from {JDK_Home}/lib to {cf_install_home}/cfusion/lib/

Only JDK contains the tools.jar file not the jre installation. You don't have to install JDK on the machine where ColdFusion is installed. You can just have jre on this machine and get tools.jar from any other machine's JDK installation.

And also make sure that the earlier stubs are cleared from {cf_install_home}/cfusion/stubs/ to get the newly compiled classes.

It is necessary to update tools.jar ONLY if you are upgrading the jre to a a higher major version.

Say, if you are upgrading from 1.8 U5 to 1.8 U51 you don't have to update tools.jar file.

But, say   if you are upgrading from 1.7 U55 to 1.8 U51, you have to update tools.jar file.


Another case where you would want to update the tools.jar is JEE deployments.

Say, if you are using Websphere application server with IBM JDK, you have to place the corresponding JDK's tools.jar under  {cf_install_home}/cfusion/lib/.

The same applies to any other application server as well.

The simple rule is that tools.jar has to be from the same major version of Java (minor version doesn’t matter) that ColdFusion runs on.


This applies to any version of ColdFusion and the same applies to all platforms.

You can copy tools.jar from Windows machine to Solaris macine as well as long as the version is correct.



Would like to explain the some of the factors that decide how much maximum memory that an application needs.

Here are two examples. One is with cffile upload action and the other is with cfpdf thumbnail action.

Sometimes, while uploading large files using cffile with upload action (<CFFILE ACTION= "UPLOAD") you would have run into the following error

"500 - Internal server error.

There is a problem with the resource you are looking for, and it cannot be displayed."


File upload is dependent on “Maximum size of post data” value that you can set in ColdFusion Administrator.

However, it can’t exceed the total available free memory.

Say, if 512 MB is the Xmx memory value (jvm.config) and 350 MB is already occupied by the application, even if “Maximum size of post data” value is set to 200 MB, it can upload files of up to ~150 MB (512 MB- 350 MB).

It can’t upload files of size 200 MB.

To fix it, Xmx should be increased which is again subjected to the available memory in that machine.


Here is other example:-

Say, you are using CFPDF's Thumbnail Action and the thumbnails background is not generated properly.
Here the issue would be insufficient memory.

        Just to hold the decoded image data, java application needs large memory (say 1.2 GB depending on the image pixels).

It is because of the format and high pixel nature of the image that is being converted. Number objects created are equal to the total number of pixels in that image.

So, high pixel imge would consume more memory.

To fix this, Xmx value in jvm.config should be at least -> Applications memory Size + 1.2 GB (from the above example) i.e. a minimum of 1.5 GB and can be more depending on your application.

Changing the value and restarting the server would fix this.

For configuring JNDI data sources, it should firstly be supported by the application server.

Tomcat server, which is built-into ColdFusion server, has the support for this by default.

While there is a blog Here on this how to configure, I want to explain few mistakes that are tend to be done while configuring. 

  One common mistake generally done is:-
  When the data source is configured from the ColdFusion administrator by providing irrelevant    username/password.
  You may tend to provide Database's username/password. This is NOT Database's username/password.
  It is the application server's username and password on which data source is configured.
  It should be left blank when the credentials are not required by the server.

Prepending java:comp/env/ is required for the actual JNDI name that is registered in xml while registering the name in administrator.

It is not mandatory that you register the JNDI data source in ColdFusion administrator.

As long as the app server supports JNDI, you can invoke the data source that is configured in the application server in cfm source code directly either in case of standalone installation or EAR/WAR deployment.
But for consistency and preferred names that can used in ColdFusion should be registered in ColdFusion.

This is applicable to both ColdFusion 10 and ColdFusion 11.