Due to a known issue with the Jrun connector shipped with ColdFusion 8 and 9, you can experience Memory leaks if the User Agent tracking is enabled in FusionReactor.

You can enable the User Agent tracking in both the Request Settings > Request Logging > Log User-Agent and Crash Protection Settings > Email Settings > Show 'User Agent' in Email Notifications

We strongly recommend that you leave this option set to disabled for ColdFusion 8 and ColdFusion 9 servers.

When a sever falls into sleep mode the Network IO Graph may show negative values. The Network IO Graph is located in FusionReactor under:

• System Resource > Network Usage

Network IO Graph displaying negative spikes in FusionReactor

Negative values will cause the 1 Hour, 1 Day, and 1 Week graphs to display incorrectly where the negative values occurred.

FusionReactor will be fixed by preventing the negative values in a later release.

Background

Several CFML applications – especially legacy code-bases – make extensive use of the <cflock /> tag but it's very difficult to get metrics on 1) the frequency of <cflock /> usage and 2) the wait times incurred by <cflock />.

FusionReactor v5.0.8 and above can easily track these times.

Enabling

• Create a file fusionreactoragent.properties in your FusionReactor instance folder ( eg FusionReactor/instance/<instance name>/fusionreactoragent.properties )
• Insert the following text into the file:

  com.intergral.fusionreactor.agent.pointcuts.ColdFusionScopedLockPointCut=true
  com.intergral.fusionreactor.agent.pointcuts.ColdFusionNamedLockPointCut=true
  

• Restart your ColdFusion instance

Viewing data

Charts

• Login to FusionReactor and click the Transactions icon from the left-menu
• Choose either Activity Graph or Time Graph
• At the top-right of the graph is a drop-down (typically reading JDBCRequest). Select CFLockWait::Named or CFLockWait::Scope from the drop-down for named or scoped locks respectively.
  • The Activity Graph shows the number of <cflock /> tags encountered.
  • The Time Graph shows the time waiting to acquire a lock.

Tables

• Login to FusionReactor and click the Transactions icon from the left-menu
• Choose either Active or History
• At the top-right of the graph is a drop-down (typically reading JDBCRequest). Select CFLockWait::Named or CFLockWait::Scope from the drop-down for named or scoped locks respectively.
  • The Active list shows currently active locks
  • The History list shows recently encountered locks

Request Details

After enabling, when you drill-down into a request's details, you will also be able to see the wait time, name/scope and other properties of the lock.

If you have access to the computer where FusionReactor is installed you can reset the password without uninstalling and reinstalling FusionReactor as follows:

FusionReactor 1 + 2

1. Find the FusionReactor configuration file (reactor.conf) of the instance for which you want to reset the password.
   For FusionReactor 1.0 this is typically C:FusionReactorconfreactor.conf on Windows or /opt/fusionreactor/conf/reactor.conf on Unix.
   For FusionReactor 2.0 this is typically C:FusionReactorinstance<your instance name>confreactor.conf on Windows or /opt/fusionreactor/instance/<your instance name>/conf/reactor.conf on Unix.
2. Open the configuration file with an editor and replace the value of the property password with D41D8CD98F00B204E9800998ECF8427E. The resulting line must look like this

   password=D41D8CD98F00B204E9800998ECF8427E
   

3. Restart the application server, and then you can log in to FusionReactor by hitting return (leave the password blank).
4. Remeber to set a new password immediately from the FusionReactor menu : Change Password option.

FusionReactor 3, 4 & 5

1. Find the FusionReactor configuration file (reactor.conf) of the instance for which you want to reset the password. This is typically C:FusionReactorinstance<your instance name>confreactor.conf on Windows or /opt/fusionreactor/instance/<your instance name>/conf/reactor.conf on Unix.
2. Open the configuration file with an editor and edit the value of the property user.0 with Administrator,Administrator,21232F297A57A5A743894A0E4A801FC3. The resulting line must look like this

   user.0=Administrator,Administrator,21232F297A57A5A743894A0E4A801FC3 
   

3. Restart the application server, and then you can log in to FusionReactor using the password: admin
4. Remeber to set a new password immediately from the FusionReactor menu : Change Password option.

Note: If you are resetting the password for the FRAM instance then it's the framd (*nix) / FusionReactor AM Service (Windows) you should be restarting in step 3 above.

Background

FusionReactor v5 is installed through a JVM argument change. By default, multi-instance ColdFusion installs (on JRun) use the same jvm.config configuration file.

It is necessary to configure separate configuration files per instance before installing FusionReactor v5.

How to configure separate jvm.config files (Windows)

• Stop all instances
• If you already have FRv5 installed, use the Instance Manager in FRAM to remove FR from the instance(s) you currently have FR "installed" to
• Open a command prompt and cd c:JRun4bin
• For each instance, run jrunsvc -remove "Adobe Coldfusion 9 AS <instance name>"
  • e.g. jrunsvc -remove "Adobe Coldfusion 9 AS cf9-a"
• For each instance, run copy jvm.config jvm_<instance name>.config
  • e.g. copy jvm.config jvm_cf9-a.config
• For each instance, run jrunsvc -install <instance name> "Adobe ColdFusion 9 AS <instance name>" "Adobe ColdFusion 9 AS <instance name>" -config jvm_<instance name>.config
  • e.g. jrunsvc -install cf9-a "Adobe ColdFusion 9 AS cf9-a" "Adobe ColdFusion 9 AS cf9-a" -config jvm_cf9-a.config
• When starting CF from the services panel, it should now use separate configuration files for each instance
• Use the Instance Manager in FRAM to add FR into each of the instances you want to monitor. As part of the process, make sure you specify the correct service name & configuration file path on each instance
• Start all instances

This technote is about using the JDBC Driver Wrapper with the Apache Derby database (either in client-server mode, or embedded mode) on Adobe ColdFusion.

Wrapping the datasource

The simplest way to wrap an existing Apache Derby datasource is to use the FusionReactor wrapper tool. This can be downloaded from here.

Use this tool to create a wrapped version of the embedded datasource.

N.b. because the wrapper doesn't initially know about the driver itself, the wrapper tool may raise a Verification Exception:

Even if this does not occur, you will need to edit the datasource. Go to the ColdFusion Administrator -> Data Sources and edit the new _WRAPPED driver.

Add the following two options to the JDBC URL:

• cp=C:ColdFusion9libderby.jar – this tells the wrapper where the Derby driver is located.
• autocommit=false – this tells the wrapper not to enable autocommit for the driver. This option is required by ColdFusion.

You may have to adjust the path to the jar, depending on the install location of your ColdFusion instance. Once you've added these options, you should have a complete JDBC URl which looks something like this:

jdbc:fusionreactor:wrapper:{jdbc:derby:C:ColdFusion9dbbookclub;create=false;MaxPooledStatements=300};driver=org.apache.derby.jdbc.EmbeddedDriver;name=cfbookclub;cp=C:ColdFusion9libderby.jar;autoCommit=false

Save the data source definition in the ColdFusion Administrator.

CF may have problems 'starting' the database (for embedded derby). This is because only one driver at once can start and use an embedded apache database, and if the unwrapped driver is still present, it may have opened the database first. In this case, derby will raise an EmbedSQLException

Connection verification failed for data source: cfbookclub_WRAPPED
org.apache.derby.impl.jdbc.EmbedSQLException: Failed to start database 'C:ColdFusion9dbbookclub'.

To avoid this error:

• Ensure your application does not use the unwrapped driver prior to it using the wrapped driver. The easiest way to do this is to only use the wrapped driver.

You may wish to simply delete the unwrapped version of the driver, in order to ensure that nothing is using it.

To reset the status of the drivers, restart ColdFusion. The Wrapped datasource can then be verified and used.

Symptoms

You may encounter a situation where ColdFusion locks up and appears not to be servicing requests. When you inspect the request queue with FusionReactor, you notice a lot of requests are executing. A thread dump indicates many threads stuck in the method java.net.SocketOutputStream.socketWrite0.

The following is a sample stack trace in which the situation exhibits:

at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at jrun.servlet.jrpp.JrppOutputStream$SpillStream.write(JrppOutputStream.java:182)
at jrun.servlet.io.MetricsOutputStream.write(MetricsOutputStream.java:75)
...

Analysis

This method, which is native C code, handles the actual transmission of page data from the J2EE container onto the network, either for direct transmission to a client, or for subsequent marshalling by an intermediate web server (e.g. IIS). Some clients (in particular, some older versions of Internet Explorer) exhibit a bug whereby they consume the transferred data, but fail to shut down the socket.

The issue stems from the fact that internally, ColdFusion's web server connectors appear to have an internal buffer of 64KB, regardless of how big the ColdFusion page buffer is set. This buffer is filled by ColdFusion on a <cfflush> command (or when the page is complete, or the CF page buffer is full). The flush operation causes the buffer to be written to the network, and for the client to reply that it has received it all correctly. If the client does not properly close the connection, or another network issue occurs, the next flush of page data by ColdFusion down to this buffer will cause the thread to hang.

The connection on the server therefore remains active in the socketWrite0 method, and eventually all worker threads are consumed, ending up locked in this state.

ColdFusion is unable to perform operations on these threads since they are executing a native method. Any operation on these threads is flagged for execution when the native method returns – which it never does. Because TCP/IP handshake data is still being serviced by the client, the server believes the connection is alive, and it is never timed out.

Turning on CP Socket Buffering

The Socket Buffering crash protection attempts to alleviate this problem by:

• Increasing the size of the Java (ColdFusion) page buffer to a larger value than default, to increase the likelihood that the entire page can be buffered and sent in one operation;
• Discarding ColdFusion flush commands after the first 64KB of data is buffered, preventing a flush from locking the thread.

How to Turn On CP Socket Buffering

• Shut down the ColdFusion instance you're monitoring with FusionReactor
• Locate the reactor.conf file for your instance.
  • This will be in /FusionReactor/instances/INSTANCE_NAME/conf
• Back up this file somewhere safe.
• Edit this file, adding the following line to the end:

• Restart the instance.

Caveats

• Because of the complexity of the buffering mechanism, and the large variety of ways it is employed, we still consider this feature experimental, and it is therefore not exposed in the user interface.
• If you rely on cfflush for page building, be aware that flushes subsequent to the 64KB mark may not be honoured. The remaining data will be flushed to the network when the page completes.

Availability

This feature is available in FusionReactor 3.0.1 and later.

FusionReactor Enterprise Dashboard Rev. 1.5

RELEASE NOTES

Status: 9-Aug-2011

Welcome to the FusionReactor Enterprise Dashboard!

We appreciate your feedback. Please use the web form or send mail to:

support@fusion-reactor.com

These Release Notes describe what is contained in this release, provide
late-breaking news, and list additional documentation for the software.

For additional information on FusionReactor, please visit our website at:

https://www.fusion-reactor.com

For known issues and further support, please see the following web pages:

https://www.fusion-reactor.com/fr/faq.cfm
https://www.fusion-reactor.com/fr/support.cfm

To Check for FusionReactor AIR Enterprise Dashboard updates, open the application and select the "Updates" tab from the login dialogue and click the "Check for updates" button. The status text will be updated showing the applications current update status: "Up to date" or "Update Available".
If an update is available, the "Update" button will be enabled. Clicking the update button will download and install the latest update, restarting the application with the new and installed update.

Note: The new AIR Application is built / compiled using a different version of both Flex and AIR. The installer / updater is not compatible between the two, therefore any old version of the AIR client should be manually removed / uninstalled before the new (latest version – 1.5) version is installed.

RESOLVED ISSUES

FusionReactor Rev. 3.5.x

RELEASE NOTES

Status: 17-Feburary-2011

Welcome to FusionReactor!

We appreciate your feedback. Please use the web form or send mail to:

support@fusion-reactor.com

These Release Notes describe what is contained in this release, provide
late-breaking news, and list additional documentation for the software.

For additional information on FusionReactor, please visit our website at:

https://www.fusion-reactor.com

For known issues and further support, please see the following web pages:

https://www.fusion-reactor.com/fr/faq.cfm
https://www.fusion-reactor.com/fr/support.cfm

To check for FusionReactor updates use the update page

RESOLVED ISSUES 3.5.5

RESOLVED ISSUES 3.5.4

RESOLVED ISSUES 3.5.3

RESOLVED ISSUES 3.5.2

RESOLVED ISSUES 3.5.1

RESOLVED ISSUES 3.5.0

FusionReactor License and Activation Issues

Version Check

We recommend that you first make sure that you have the most current version of FusionReactor installed as recent updates include license and activation fixes. You can download the most current version from the FusionReactor download page.

Problems and how to fix them

Typical problems

In the following section, we list the most often reported problems with the FusionReactor license and activation process as seen from the user's perspective. The typical causes of these problems are discussed subsequently, along with the steps necessary to solve them.

1. Restarting the server expires a trial license or activation period immediately
2. Attempting to activate a license with an expired activation period redirects to the login page (but the license was not activated)
3. Installing a license shows an error page saying Can not upload license: null
4. Installing a license silently fails (you get redirected to the login page but the license was not installed)
5. Loss of license activation after reboot on some multi-server installations of FusionReactor 3.5.1

Typical causes

1. Insufficient privileges of the server account when trying to write to the Java System Preferences Backing Store.
2. A Java6 VM on Linux or Solaris that has no fix for SUN JVM bug 6519088
3. Firefox browsers occasionally corrupting the license during the upload
4. Trying to activate a license without a connection to the Internet (bug FR1409).

How to fix it

Insufficient privileges

The runtime user of the server on which FusionReactor is installed requires read/write access to the Java System Preferences Backing Store. Depending on the operating system, the location of this data store is different. On Windows the data is stored in the registry hive HKEY_LOCAL_MACHINESOFTWAREJavaSoftPrefs, the data belonging to FusionReactor is in HKEY_LOCAL_MACHINESOFTWAREJavaSoftPrefscomintergralfusionreactor.
Page 14 of the FusionReactor Installation Guide provides you with instructions how to adjust the permissions of this store.
On Linux and Solaris the data is typically stored in the directory /etc/.java/.systemPrefs as a hierarchy of directories containing XML files. The data belonging to FusionReactor is in the directory /etc/.java/.systemPrefs/com/intergral/fusionreactor. To set the necessary permissions execute the following command as user root:

chmod -R 777 /etc/.java/.systemPrefs

Alternative locations of the System Preferences Backing Store

Some JVMs try to create the System Preferences Backing Store in the directory $JAVA_HOME/.systemPrefs as a fallback solution if the directory /etc/.java/.systemPrefs cannot be created where $JAVA_HOME denotes the directory where the JVM itself is located (e.g. /opt/coldfusionmx/runtime/jre ).

We strongly recommend you to use /etc/.java/.systemPrefs as the one and only location of the System Preferences Backing Store. In case there is already data from other applications in $JAVA_HOME/.systemPrefs you should move it to /etc/.java/.systemPrefs and delete $JAVA_HOME/.systemPrefs afterwards (after you have adjusted the permissions of /etc/.java/.systemPrefs properly).

Clear the System Preferences Backing Store

If you attempt to install a license and you get the error message mentioned before:

Can not upload license: null

or simply

null

then you should stop the application server, clear the content of the Java System Preferences Backingstore and restart the application server.

On a Windows machine run the registry editor (regedit.exe or regedt32.exe) and then delete the key

HKEY_LOCAL_MACHINESOFTWAREJavaSoftPrefscomintergralfusionreactor

On a UNIX machine as user root delete the directory

/etc/.java/.systemPrefs/com/intergral/fusionreactor

If the permissions are configured correctly uploading a license and activating it will work properly afterwards.

On MacOS the System Preferences are stored as a set of *.plist files under the /Library/Preferences folder. Once the application server has stopped delete the file /Library/Preferences/com.intergral.fusionreactor.plist to clear all Preferences belonging to FusionReactor.

SUN Java 6 VM bug 6519088

This bug has been introduced with version 6 of the Linux and Solaris SUN Java VM and unfortunately has not been fixed even in the recently released version 6.0_05. We have a technote available at https://www.fusion-reactor.com/support/kb/FRS-168.cfm which provides you with detailed instruction how to apply a fix for this bug.

Bypassing problems with Firefox

If you upload a license with Firefox and nothing seems to happen (except that you have to login again) check the reactor-0.log file for the typical error message (see also https://www.fusion-reactor.com/support/kb/FRS-45.cfm) shown below

...
javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when
decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_ae.b(DashoA12275)
at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(DashoA12275)
at javax.crypto.Cipher.doFinal(DashoA12275)
...

If multiple retries of uploading the license file again do not change this try to upload the license from a different browser and/or computer. If this does not help neither manually copy the license file to FusionReactor/license/license.lic and restart the server.

Making the manual activation process work

As mentioned in the overview of this document there is a hotfix available that fixes the bug FR1409 in the previous FusionReactor version 3.0.0 where a license can only be activated if the computer has a connection to the Internet. Download: fusionreactor-hotfix1409.zip. It comes as a ZIP file containing a new version of the FusionReactor Java library (fusionreactor.jar) together with instructions how to apply the fix. However, we recommend to upgrade to a newer version, which does not require this hotfix.