Wednesday, November 28, 2012

Using cfproperty to reduce java class files

I haven't seen much blogged about this, so I thought it would be worth bringing up.

As part of our jump from CF8 to CF10 I've been experimenting with cfproperty and the concept of implicit getters/setters. Due to the way ColdFusion compiles these implicit functions it seems to me you can significantly reduce the number of java class files that ColdFusion creates. Obviously the effect is very noticeable in OO applications with lots of beans and hundreds of getter/setter functions.

To prove this let's take the following CFC with the old school explicit declarations for all of our getters & setters. I'll call it "explicit.cfc"

<cfcomponent output="false">
    <cffunction name="init" output="false" returntype="any" hint="our formal constructor block.">
            <cfset    =1>
            <cfset variables.instance.title="">

    <cffunction name="getID" output="false" returntype="string">
        <cfreturn />
    <cffunction name="setID" output="false">
        <cfargument name="ID" type="string" required="true">

    <cffunction name="getName" output="false" returntype="string">
        <cfreturn />
    <cffunction name="setName" output="false">
        <cfargument name="Name" type="string" required="true">
        <cfset variables.instance.Name=arguments.Name>

    <cffunction name="getTitle" output="false" returntype="string">
        <cfreturn variables.instance.title />
    <cffunction name="setTitle" output="false">
        <cfargument name="Title" type="string" required="true">
        <cfset variables.instance.Title=arguments.Title>


It is a bean-like object with accessors for three variables: id, name, and title.

Now let's write a file that uses our object.

<cfprocessingdirective pageEncoding="utf-8" suppressWhitespace="true">
    ex = new explicit();
    writeOutput("<p>  ID:#ex.getID()#  Name:#ex.getName()#  </p>" );

Finally, go into the CF administrator and check " " in the Caching menu.

Now call up that page we created in your browser, then check in the .class files directory for CF and see what the server compiled. It will look like this:

 As we can see, CF has created a class file for our CFC itself, and every function inside of it. It also created a class file for our calling page.

Now let's take a CFC with the new style implicit cfproperty declarations for our getters & setters. Let's call it "implicit.cfc"

<cfcomponent output="false" accessors="true">

    <cfproperty name="id" />
    <cfproperty name="name" />
    <cfproperty name="title" />
        <cffunction name="init" output="false" returntype="any" hint="our formal constructor block.">
            <cfset setID(1)>
            <cfset setName('Tester')>           


Go back and edit our file. We now create an implicit.cfc object.

<cfprocessingdirective pageEncoding="utf-8" suppressWhitespace="true">
    ex = new implicit();
    writeOutput("<p>  ID:#ex.getID()#  Name:#ex.getName()#  </p>" );

And what gets created now for java class files?

Just three files: one for the CFC itself, one for the Init() function inside of it, and one for the calling page.

Obviously the effect of this in a large application is that you're going to save yourself from creating a lot of 3kb class files for every getter/setter.

You may be asking if all if this matters, and it most cases it probably is not of great concern. In my experience it only really matters if you are seeing java.lang.OutOfMemoryError: PermGen space errors on your server. This is the space in the java heap where your class definitions are stored and it is possible to fill it up if you're running a lot of big applications on the server. Fewer classes should result in a reduced PermGen usage.

I've seen the PermGen error a number of times on a 32 bit machine with CF8. We got around it in the end by increasing the size of our perm-gen space in the JVM to 256mb, but even then we kept bumping up on the limit in some cases. On a 64 bit machine this should be even less of a problem though due to the ability to run with a much larger JVM.

The fact that each ColdFusion function results in a Java class file has always bugged me, and I'm glad this is no longer always the case. In theory fewer classes should also result in a performance gain, although, to be fair, I suspect in most cases the practical effect will be marginal.

Tuesday, November 20, 2012

Using MAT with Coldfusion

I spend a lot of time doing optimization and performance analysis on our sites, and over the years I've developed or used a lot of tools to help with this.

The simplest is probably a simple jstat reporting tool. We take snapshots of our servers with jstat about once a minute, and save the results in the database. With the results I can generate a lot of useful information about our JVM. To do this I use a few basic cfchart commands and get some basic results like the following, detailing heap usage in the server.

This little peak into the JVM is useful, and with it we get some basic statistics as to the health of our runtime environment. The key figures for us have always been how much memory is occupied by our tenured generation objects. If we have  a memory leak somewhere in our application or server scope, then that yellow line in the middle will make a relentless march upward, eventually flatlining when no more memory can be reclaimed through garbage collection.

The chart is useful, but it doesn't tell you exactly WHAT is contributing to instability with the Heap.
This brings us to a fun little tool: the Eclipse Memory Analyzer (MAT).

MAT is a tool for analyzing Heap Dumps. What's a heap dump? It's a snapshop of everything in your heap at the point in time the heap dump was made.

Heap Dumps are made with the jmap utility, which comes in the bin directory of every JDK as of Java 5. To do a heap dump just on a Windows machine with a Coldfusion Server running, do as follows:

  1. Go to the task managerr and find the processID (pid) of the coldfusion server.
  2. Execute "C:\mypathtojdk\bin\jmap" -dump:format=b,file=C:\MyPathToHeapDumps\heap.bin xxxx, replacing the paths where noted and the xxx will need to be replaced with the pid.
That's it. Now let's fire up MAT. You'll want to go to File / Open Heap Dump and pick out that  binary file you've just generated. The very first time you open the heap dump it may take awhile depending on the size of your file -- MAT parses your file and caches the results so future views will proceed more quickly.

The default option is a report that automatically checks for "Leak Suspects". This is sometimes useful, but not always. With Coldfusion you'll find in any case that you need to drill down through all of the java objects that are part of the CF library before you get to the true offenders.

Here's the leak report; and yeah I know there's not much in that JVM right now.  :)

There are a number of reports, and you'll just have to play around to see which one tells you the most. It varies, and depends to some extent on preference. I generally go into the Histogram, sort my objects by retained Heap, look for possible suspects, and begin following the paths to garbage collection.

One tip: at least as of CF 8 you will find that Coldfusion Applications are represented as FastHashTables in the JVM.  In the following screenshot I've opened one of these FastHashTables. Inside of it is an object of coldfusion.runtime.ApplicationScope, and we can see which application it is by looking at the attributes on the left.

Obviously if one of these is consuming a lot of memory in your "retained Heap" column, then you know where the culprit lies.

Friday, September 21, 2012

Undefined elements in structs returned from web service

I was accessing some functions remotely today in CF10 when I came across some weird behavior. Namely, the values returned by StructkeyList, StructkeyExists, and a Dump of a Struct are consistent with each other.

Take the following code and place it somewhere in a CFC to be accessed remotely.

    <cffunction name="getTest" output="no" returntype="struct" access="remote">

        <cfset result=structnew()>
                <cfset result.testvar = "some var">
                <cfset result.fuseactions = ArrayNew(1)>
        <cfreturn result>

Now access it from a calling page. You'll need to put in your own server and CFC name.

    returnvariable = "response"
    refreshWSDL = "true"

This is where it gets interesting. Let's do a dump of our return variable.

Notice that the "FUSEACTIONS" key in our struct seems interesting. Here we see "undefined" where we would have expected an empty array. I'm guessing the empty array goes missing during the serialization.

Ok, but let's go further. Let's do #structKeyList(response)# on the struct. We see, as expected, our two elements.

Now it gets strange. Try to do a StructKeyExists on the FUSEACTIONS key.


It delivers "NO". Trying to dump the struct element results in an error.

Now I know that the concept of NULL values was introduced in CF9. (Something I missed, still toddling along with CF8). So let's try:


Sure enough, it delivers YES.

Still, this seems a little weird to me. Intuitively I would expect to see an empty array inside the Struct, since that was how the variable was declared. In any case, the inconsistency between StructKeyExists and StructKeyList is a change from CF8 and it broke some old code of ours.

 I've filed this as bug 3334756 by Adobe. Let's see what they say.

Wednesday, September 12, 2012

filexists() with a url equals a hung request

I had a bug in one spot where a url was being given to the fileexists() function instead of an absolute path.
According to the documentation this should not work. Sure enough it really doesn't, but instead of returning NO the thread seems to hang. (CF 10 , version 10,282462). Not exactly sure why, more investigation is needed here.

I've never worked on version 9 before, but according to this thread, it was actually possible to do a fileexists on a url as of 9.0.1

Friday, September 7, 2012

getApplicationSettings() Part 2

In the last post I talked about the getApplicationSettings() method, and how we previously used it to look inside the application scopes of other applications in Coldfusion 8.  Well one of the first things I noticed when working with our application administration tool in CF10 is that this function changed in version 10, which was leading to errors.

That's the danger of relying too much on undocumented features!

Most specifically, in CF8 the getApplicationSettings returned us a struct, now it returns a class of  type coldfusion.runtime.ApplicationSettings.

This was rather bad for me, because in the old CF8 version the struct contained, among other things, a further struct with all the custom mappings for the application. A quick glance at the new object showed  that my mappings were nowhere to be found.

So now what? I created an object of type applicationScope and sniffed around.

 <cfset app = createObject("java","coldfusion.runtime.ApplicationScope") /> 
 <cfdump var="#app#">

The answer was pretty easy to find. The new getApplicationSettingsMap() function returns the struct that I used to use in CF8. One quick fix and my tool was back up and running.

Of course it is worth pointing out that this whole change probably happened because of the new getApplicationMetaData function, which gives me a "documented" way to get at some of the things I could only see through sneaky means in the past.

If you just need to see the meta data of the application of the calling template, use that instead.


Years ago we built an administration tool for our servers that allows us to view and administer all of the CF applications currently running. With it we reach into the application scope of each app and can do a number of things,  like refreshing objects cached in the application scope, clearing cached files, and so on.

Anyway, the key behind this magic is the ApplicationScopeTracker object, which lives in the coldfusion runtime.

<cfset apptracker = createObject("java","coldfusion.runtime.ApplicationScopeTracker") />

Above, I have created the variable "apptracker". Let's make a dump of this.

The only method I've ever really played around here with is getApplicationScope(). This function takes the name of an application as argument, and returns the entire application scope of that app.

<cfset appscope = apptracker.getApplicationScope('someappname') />
<cfdump var="#appscope#">

That will give you a dump of your entire application scope. I'll spare you a picture of that since my application scopes tend to be pretty big. :)

What you may not realize at first when looking at the dump though, is that actually we are dealing with an object of type coldfusion.runtime.ApplicationScope, and not a struct. To prove this we can execute a method on it.

<cfdump var="#appscope.getApplicationSettings()#">

And we see this:

Now these functions have been around a pretty long time, and they're  pretty well documented on a lot of other blogs around the web. They can be pretty useful too, although it's important to remember that when working with these  underlying java functions  we are using unofficial and  thus unsupported parts of the Coldfusion engine.

These functions are subject to change and sometimes do. In fact such a change gave me my first CF10 "ouch", which I'll get to in the next post.

The Upgrade

Where I work in Frankfurt there is a lot of Coldfusion. In fact we're probably one of the biggest Coldfusion users in Germany. For the last few years we've been using CF8, but that will be changing during our upcoming upgrade to CF10.

I'm creating this blog to track our experiences for this big leap!