ColdFusion 9: Page 2

[frs-231] The Hostname in Request URL’s show “null” instead of the server name or IP address in ColdFusion 9

Due to an issue in the JRun version used with ColdFusion 9, the Hostname in Request URL's can sometimes contain the string "null" instead of the actual hostname.

Finished: 18:48:30.774 28-Sep-2009  200  11841  web-0  http://null:8500/test/test.cfm  0  Cur:(13%)67,809 Free:437,086

The problem occurs when a request is made against a port that is not the default port (e.g. 80) and the port number is not included in the HTTP Host header sent to the ColdFusion server by the web client. For example:

Some web clients incorrectly do not include the port number in the Host: header that is sent for the request. For example:

GET /test/test.jdbcfast.cfm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Connection: Close

This problem has been confirmed for Microsoft Web Application Stress (which does not send the port number in the Host header), but other clients may suffer from the same bug.


To work around the issue you should use the default web port (e.g. 80), or use a different client that correctly sends the port number in the Host: header of HTTP requests.

A bug report has been submitted to Adobe for this issue.

Issue Details

Type: Technote
Issue Number: FRS-231
Components: Request Managment

Windows XP (Darren’s laptop)
ColdFusion GM2
Via internal webserver.

Resolution: Won’t Fix
Last Updated: 30/Sep/09 1:55 PM
Affects Version: 1.0, 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1, 3.5
Fixed Version: Pending
Server: ColdFusion 9
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, Windows 7, Windows 2008
Related Issues:

[frs-176] CPU Graph Always Shows Zero


On Linux kernels prior to 2.6, including Red Hat Enterprise Linux 3 (all editions) and Red Hat Linux 9, CPU monitoring always reports a zero load. This is a known issue with kernel 2.4 and earlier.


This issue is a symptom of the way in which Linux manages CPU time data for threads.

For stock Linux kernels prior to 2.5, POSIX standard threading was provided by the operating system by the LinuxThreads package. The implementation offered by this package, while robust and reasonably fast, does not handle Unix signaling correctly, and required some kernel locking which ultimately meant it would never perform to its fullest potential.

For Linux kernel 2.5, Red Hat began a project called the Native POSIX Thread Library (NPTL). This consists of a C library in user-space, and several supporting enhancements to the kernel itself. Since 2.5 was a development kernel, NPTL was released into the stable kernel stream starting with kernel 2.6.

Red Hat back-ported the NPTL to its 2.4 kernel stream, which is present in RHEL 3 and RHL 9. The revision of NPTL reported by these kernels is NPTL 0.60.

NPTL became the standard default threading implementation in kernel 2.6, and is reported as NPTL 2.6.

LinuxThreads is no longer developed.

We have discovered a subtle difference in the way NPTL reports CPU occupancy times between NPTL 0.60 and 2.6. In the earlier version, NPTL charges CPU time consumed by threads only when that thread exists. In 2.6, this time is charged continually.

NPTL 0.60 also charges time consumed by subthreads against the 'subprocess' category (which is strictly incorrect). This behavior was corrected in NPTL 2.6, with this time being charged against the spawning process (of which the subthreads are technically part).

For multi-threaded programs like ColdFusion (Java), this means that FusionReactor cannot detect how busy the individual ColdFusion threads are until they exit (i.e. when the system shuts down). This means the CPU load graph in FusionReactor will show 0 for Linux systems based on NPTL 0.60 (RHL 9, RHEL 3). The CPU graph works correctly against kernel 2.6 systems (NPTL 2.6).

Workaround for ColdFusion on Kernels 2.6 and higher

It is possible that you are running CF using LinuxThreads which is considerable slower and less stable than Native POSIX Threads.

The problem is that the standard CF startup script uses a variable (LD_ASSUME_KERNEL=2.2.9) to tell Linux to startup with an old Kernel that uses LinuxThreads. It's possible to remove this by commenting out the export LD_ASSUME_KERNEL command that follows in the script (#xport LD_ASSUME_KERNEL), which lets CF startup with an NPTL kernel if you have one. As well as fixing the CPU issue, CF will use Native Threads which may result in an increase in both performance and stability.

Take a look at this article from Steve Erat (from Adobe) on how to get CF running on Fedora Core 6 for example:

No Known Workaround for Kernels 2.5 and lower

We have thoroughly investigated this issue, and there is unfortunately no known workaround.

Issue Details

Type: Technote
Issue Number: FRS-176
Components: CPU + Memory
Resolution: Fixed
Last Updated: 10/Sep/09 5:18 PM
Affects Version: 1.0, 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1
Fixed Version: 1.0, 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1
Server: ColdFusion 6, ColdFusion 7, ColdFusion 8, ColdFusion 9, Flex Data Services, JBoss, JRun 4, LiveCycle Data Services, Tomcat, WebSphere, WebLogic
Platform: Linux
Related Issues:

FRS-40: Why doesn’t CPU Monitoring / Stack Traces work?