[FRS-442] Forgotten FusionReactor v7 password / Reset FusionReactor v7 password


This technote will guide you through resetting the password for your FusionReactor 7.x instance, the process is also relevant for FusionReactor versions 5.x and 6.x.

To reset the password for FusionReactor you can follow these steps:

  1. Stop your application server
  2. Locate your reactor.conf file at {FusionReactor Directory}/instance/{instance name}/conf/reactor.conf
  3. Open this file in a text editor
  4. Remove the line beginning with "user.0=Administrator"
  5. Restart your application server.

When you access FusionReactor you will be asked to set a new password for the administrator user.

 

Issue Details

Type: Technote
Issue Number: FRS-442
Components: FusionReactor Settings
Environment:
Resolution: Fixed
Last Updated: Today 1:55 PM
Affects Version:
Fixed Version: 7.0.0
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

FRS-321: Forgotten FusionReactor v5 password / Reset FusionReactor v5 password

[FRS-441] Retaining FusionReactor logs in Docker Environment


When running in a docker based environment it can be difficult to retain the logs for your application and for the monitoring tools that you use. To over come this there are several options that you can use.

  • An external platform to consume the log files.
  • An docker volume to retain the files after the docker container has terminated.

There are pros and cons to each method, in our cloud solution we utilize both, firstly we ship a lot of out logs to an external service to archive and indexing for search and alerts. We additionally produce a dynamically generated docker volume to store the logs for the application and for FusionReactor it self (that's right we use FusionReactor to monitor FusionReactor!).

Background

So firstly what is a docker volume, well to really know the ins and outs of the docker volumes I suggest that you read the official documentation from the docker guys. (https://docs.docker.com/engine/admin/volumes/volumes/).

But in case you do not want to read all of that, a docker volume is effectively a shared file system location that is not deleted when the container is destroyed. This allows you to persist the data in this volume after the docker has terminated, so you can go back and have a loot at crash dumps, log file etc.

Configuration

To configure a docker container to use a volume you only need to add the volume paths for the internal and external folder locations. On the command line that would look like this:

-v /path/on/host:/path/in/container

If you are using docker-compose you can add this to the file like this:

volumes:
  - /path/on/host:/path/in/container

Runtime

So if you run your container with a shared volume, how do you get the FusionReactor logs to appear in this location?

For this there are two options, either you can create the volumes on the location your FusionReactor logs go (and archive if using the default logger), or you can change the log directory of the FusionReactor log instance using a small bash script.

So the first approach is to use two docker volumes, as shown here:

volumes:
  - /opt/docker/share/fusionreactor/tomcat/log:/opt/fusionreactor/instance/tomcat/log
  - /opt/docker/share/fusionreactor/tomcat/archive:/opt/fusionreactor/instance/tomcat/archive

This will put the logs from the FusionReactor inside the docker container, in the directory /opt/docker/share/fusionreactor/tomcat on the host machine. Unfortunately this can have some side effects if you configure this for more than one FusionReactor, as all the FusionReactor instances will try to log to the same files. This can cause errors from the loggers, and more importantly, make it hard to understand the logs (as they will contain 2 instances logs).

To over come this problem you can use a small script when the docker starts to modify the FusionReactor configuration to allow for multi-tenant logging.

Dynamic Runtime

The first step is to create a docker volume where we can place all these log files, for our system we use /opt/docker/share. So in the docker-compose file you can add:

volumes:
  - /opt/docker/share:/opt/docker/share

As you can see we use the same path inside the docker as on the host, now we need to create a new folder inside this path (as part of the docker run script to allow for multiple FusionReactors to log here at the same time. How we do this is to run this small snippet in the EntryPoint of the docker container.

FR_LOG_SHARE_PATH="/opt/docker/share/${HOSTNAME}"
mkdir --parents ${FR_LOG_SHARE_PATH}/log
mkdir --parents ${FR_LOG_SHARE_PATH}/archive
echo "logdir="${FR_LOG_SHARE_PATH}/log >> /opt/fusionreactor/instance/tomcat/conf/reactor.conf
echo "fac.archive.root="${FR_LOG_SHARE_PATH}/archive >> /opt/fusionreactor/instance/tomcat/conf/reactor.conf

... continue with starting your application ...

With this your FusionReactor will now log and archive to this docker volume, allowing you to access these files after the container has been terminated.

Conclusion

By using this approach you can now retain the log files for your FusionReactor instance after the container has been terminated. This approach also allows you to add additional files to these shares. For example we also add the Java options to produce a heap dump and hs_error file to a similar docker volume in the event of a JVM Out Of Memory error or other fatal errors.

Unfortunately this approach does have a side effect of 'leaking' disk space as the host directory /opt/docker/share will not be cleaned up by the docker daemon. This can easily be over come with a small cron job or other process to periodically delete older files.

Issue Details

Type: Technote
Issue Number: FRS-441
Components: Logging
Environment:
Resolution: Fixed
Last Updated: Today 4:15 PM
Affects Version:
Fixed Version: 7.0.0
Server:
Platform: Linux
Related Issues:

[frs-389] Manually uninstalling FusionReactor


Manually uninstalling FusionReactor from your application server is as simple as it is manually installing, but the process is reversed.

Typically uninstalling FusionReactor is a matter of removing 1 or 2 arguments from your JVM startup arguments. The procedure in general is:

  • Stop your application server
  • Remove the -agentpath:<…fusionreactor native library…> if present from your JVM startup arguments
  • Remove the -javaagent:<…fusionreactor.jar> if present from your JVM startup arguments
  • Start your application server.

If you are experiencing startup issues such as your server won't start after installing FusionReactor, they may be due to the -agentpath:<…fusionreactor native library…>. This argument refers to a native library that must exist and must match your Operating System, installed libraries and the 32/64bit nature of the JVM you are using. Removing only the -agentpath and restarting the server will typically allow you to still use FusionReactor, just without the Production debugger capability. The -agentpath argument is not essential for the normal operation of FusionReactor.

Provided below is an overview of how to remove FusionReactor from a number of common application servers:

Server Configuration method How to remove
Tomcat 7
Tomcat 8
Tomcat 9
Linux: setenv.sh configuration file
Windows: Tomcat*w.exe GUI Tool

where * is your tomcat version number
Tomcat FusionReactor Removal
ColdFusion 9
ColdFusion 10
ColdFusion 11
ColdFusion 2016
jvm.config configuration file ColdFusion FusionReactor Removal
ColdFusion 9 Solr Linux: solr.lax configuration file
Windows: cfsolr configuration file
ColdFusion 9 Solr FusionReactor Removal
ColdFusion 10 Solr
ColdFusion 11 Solr
Linux: jetty.lax configuration file
Windows: cfjetty configuration file
ColdFusion 10 Solr & 11 Solr FusionReactor Removal
ColdFusion 9 Multi individual jvm.config configuration files ColdFusion 9 Multi FusionReactor Removal
Glassfish 4 domain.xml configuration file Glassfish 4 FusionReactor Removal
Railo 3 Linux: setenv.sh configuration file
Windows: Railow.exe GUI Tool
Railo 3 FusionReactor Removal
Railo 4 Linux: start configuration file
Windows: Railow.exe GUI Tool
Railo 4 FusionReactor Removal
JBoss 7 Standalone
Wildfly 8
Wildfly 9
Wildfly 10
standalone.conf configuration file JBoss 7 & Wildfly FusionReactor Removal
Jetty 7
Jetty 8
Jetty 9
start.ini configuration file Jetty FusionReactor Removal
Lucee 4
Lucee 5
Linux: setenv.sh configuration file
Windows: Luceew.exe GUI Tool
Lucee FusionReactor Removal
FusionAnalytics FusionAnalytics Server.vmoptions configuration file FusionAnalytics FusionReactor Removal

For a more complete and detailed description with more information on how to remove FusionReactor from your application servers, visit the Manual Uninstallation documentation.

Issue Details

Type: Technote
Issue Number: FRS-389
Components: Installer, Instance Manager
Environment:
Resolution: Fixed
Last Updated: 11/May/16 11:33 AM
Affects Version:
Fixed Version: 6.2.0
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-386] Network IO Graph can show negative values if a server enters sleep mode


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.

Issue Details

Type: Technote
Issue Number: FRS-386
Components: Metrics
Environment:
Resolution: Fixed
Last Updated: 23/Feb/16 3:40 PM
Affects Version: 6.0.0, 6.0.1, 6.0.2, 6.0.5
Fixed Version: 6.x
Server: BlazeDS, ColdFusion 6, ColdFusion 7, ColdFusion 8, ColdFusion 9, ColdFusion 10, Flex Data Services, GlassFish, JBoss, JBoss 7, Jetty, JRun 4, Open BlueDragon, LiveCycle Data Services, Railo, Resin, ServletExec, Tomcat, Tomcat 7, WebSphere, WebLogic
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-355] FusionReactor Production Debugger fails to start due to missing GLIBC_2.14


UPD uses a native library to provide some of its features. UPDs native library requires GLIBC_2.14 to function.

Centos 6.x, Red Hat Enterprise Linux and other linux systems don't provide this version. When it's not available you will see error messages like this during startup :

$ sudo bin/catalina.sh run
Using CATALINA_BASE:   /opt/apache-tomcat-8.0.3
Using CATALINA_HOME:   /opt/apache-tomcat-8.0.3
Using CATALINA_TMPDIR: /opt/apache-tomcat-8.0.3/temp
Using JRE_HOME:        /usr
Using CLASSPATH:       /opt/apache-tomcat-8.0.3/bin/bootstrap.jar:/opt/apache-tomcat-8.0.3/bin/tomcat-juli.jar
Error occurred during initialization of VM
Could not find agent library /opt/fusionreactor/instance/tomcat8/libfrjvmti_x64.so in absolute path, with 
error: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/fusionreactor/instance/tomcat8/libfrjvmti_x64.so)

On CF servers this error information is redirected to /dev/null so its never seen but you could be hitting this error.

Check glibc version

To check the version of glibc on a linux system you can run one of the following:

# red hat / centos
rpm -q glibc

# debian / ubuntu
dpkg -l libc6

# via ldd
ldd --version

Workaround

To work around we have build a libc.so6 version 2.14.1 for uses on Centos (64 bit only) which must be explicitly loaded via the LD_PRELOAD variable

E.g. in tomcat you would set the following lines in the 'setenv.sh'

export FR_OPTS="-javaagent:/opt/fusionreactor/instance/tomcat8/fusionreactor.jar=name=tomcat8,address=127.0.0.1:8088 -agentpath:/opt/fusionreactor/instance/tomcat8/libfrjvmti_x64.so"
export JAVA_OPTS="$JAVA_OPTS $FR_OPTS"

export LD_PRELOAD=/opt/fusionreactor/instance/tomcat8/libc.so.6

Disable Debugger

You can disable the debugger completely by removing the

-agentpath:/opt/fusionreactor/instance/tomcat8/libfrjvmti_x64.so

argument from your application server. For tomcat this is in setenv.sh and for CF servers its in the jvm.config.

Files

libc.so.6 – md5 checksum fa05af08d2993c478786a1f5b0335e1a

Issue Details

Type: Technote
Issue Number: FRS-355
Components: UPD
Environment:
Resolution: Fixed
Last Updated: 02/Feb/16 3:05 PM
Affects Version: 6.0.0
Fixed Version: 6.0.0
Server:
Platform: Linux
Related Issues:

[frs-233] FusionReactor Nagios Plugin


FusionReactor Nagios Plugin

What is Nagios?

"Nagios is an enterprise-class monitoring solution for hosts, services, and networks released under an Open Source license."

Source: http://www.nagios.org, March 12th 2009

Many companies use Nagios throughout the enterprise to alert them of operational abnormalities. This plugin allows you leverage the unique monitoring capabilities of FusionReactor from within your existing Nagios environment.

Nagios Exchange

Plugin Details

This is a Perl plugin for the Nagios monitoring system to allow monitoring of your J2EE application through the FusionReactor software.

You can monitor & track high level metrics (instance CPU, heap memory, JDBC calls, average request time, etc) from within Nagios. If/When an issue is alerted from Nagios, you can use FusionReactor to investigate further.

Monitoring ColdFusion with Nagios

FusionReactor can monitor any type of J2EE server. ColdFusion runs on a J2EE server meaning that you can monitor your ColdFusion application with Nagios using FusionReactor and this plugin.

You can also monitor your Railo server with Nagios or OpenBD (Open BlueDragon) using this Nagios plugin.

Requirements

System to be monitored (J2EE server)

  • FusionReactor Enterprise Edition

Monitoring Host (Nagios server)

The following modules can easily be installed via CPAN. Further instructions are available in the documentation:

  • Nagios::Plugin
  • File::Basename
  • LWP::UserAgent
  • Digest::MD5
  • MIME::Base64
  • XML::XPath
  • XML::XPath::XMLParse

Latest Version

Latest Stable: Nagios Plugin 1.0

Download
Documentation

Changelog

1.0 – Initial release

Issue Details

Type: DevNet
Issue Number: FRS-233
Components: Compression, Content Filters, CPU + Memory, Crash Protection, Enterprise Dashboard, FR Enterprise Dashboard Desktop Application, FusionReactor Settings, Installer, JDBC, License + Activation, Logging, Metrics, Request Managment, Thread Management
Environment:
Resolution: Fixed
Last Updated: 25/Aug/15 4:32 PM
Affects Version:
Fixed Version: 1.0, 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1, 3.5, Pending
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-324] License activation is unreliable with Glassfish servers


Background

A standard Glassfish 3.x or 4.0 installation is deployed with a keyStore and no keyStorePassword.

This configuration is not supported by Java.

When FusionReactor attempts to acquire a license it makes a connection to the Intergral license servers via HTTPS. The strange glassfish configuration causes the exception "Password cannot be null" and causes the license request to fail.

The user has to then perform a manual activation.

The issue can affect the auto-activation of the license inside Glassfish and make it a little random. This is dependent on what WebApps (if any) are deployed into Glassfish and the FusionReactor and Glassfish startup order.

Workaround

There are multiple workarounds for this problem:

  • Add the following JVM option to the domain.xml file
    • <jvm-options>-Dfrlicenseservice.protocol=http</jvm-options>
  • Comment out the keyStore line to the domain.xml file
    • <!--<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks</jvm-options>-->
  • Add the missing default keyStorePassword line to the domain.xml file
    • <jvm-options>-Djavax.net.ssl.keyStorePassword=changeit</jvm-options>

Any one of these solutions fixes the activation of the license.

Issue Details

Type: Technote
Issue Number: FRS-324
Components: License + Activation
Environment:
Resolution: Fixed
Last Updated: 15/Jan/14 12:08 PM
Affects Version: 5.0.0
Fixed Version: 5.0.0
Server: GlassFish
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-155] I have forgotten the login password for FusionReactor. Is there any way to retrieve or reset the password without reinstalling the software?


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.

Issue Details

Type: Technote
Issue Number: FRS-155
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 10/Oct/13 10:51 AM
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, 4.0.0
Server: ColdFusion 6, ColdFusion 7, ColdFusion 8, Flex Data Services, JBoss, JRun 4, LiveCycle Data Services, Tomcat, WebSphere, WebLogic
Platform: Windows XP, Windows 2000, Windows 2003, Linux, Solaris
Related Issues:

FRS-194: After upgrading a FusionReactor 2.0.4 to FusionReactor 3.0.x, I can no longer log in

FRS-321: Forgotten FusionReactor v5 password / Reset FusionReactor v5 password

[frs-232] Capturing ColdFusion’s Debug Output in FusionReactor


Capturing ColdFusion's Debug Output in FusionReactor

It would be great if you could capture the debug data from every page run but hide it away from the user so that they don't even see it. It's easy to do this with FusionReactor.

ColdFusion's powerful debug data output feature that lets you see lots of useful debugging information about the page run. Unfortunately the data is lost as soon as you run the next page in the browser window/tab and is only visible to the user that ran the page.

Requirements

FusionReactor
FusionDebug

The Article

We're all familiar with ColdFusion's debug output at the end of a CFML page. Many CFML programmers use it as the primary way of debugging CFML code.

There are a few problems with the way that debug data is made available to us however such as the fact that the only user that can see the debug output is the user that ran the page. This is even more of a problem if you want to see the debug data but don't want to scare the user that ran the page. Of course it's possible in CF to restrict the IP addresses that generate debug output but sometimes you want to be able to see the debug output from other users without them seeing it. It's easy to do with FRAPI.

About FRAPI

FRAPI is a powerful and easy to use API that allows you to take control of FusionReactor programatically. Using FRAPI you can change the running configuration of FusionReactor or add extra debugging information to requests using just a few lines of code.

Here's how to instantiate the FRAPI interface in CFML. Once we have FRAPI available we add extra information to a request data recorded in FusionReactor using FRAPI's trace() function:

      	<cftry>
            <cfset frapi = createObject("java", "com.intergral.fusionreactor.api.FRAPI").getInstance()>
            <cfset frapi.trace( "Hello FRAPI!")>
            <cfcatch>
                <!--- FRAPI isn't available so FusionReactor probably isn't installed --->
            </cfcatch>
        </cftry>

Note that we always wrap FRAPI calls in a TRY/CATCH block. The reason for this is that FusionReactor may not be installed on every computer that you run the code on. The TRY/CATCH blocks will make sure that FRAPI calls will have no influence on your code even if FusionReactor isn't installed.

To try FRAPI, create a "frapitest.cfm" file with the CFML code above and run the page on a system that has FusionReactor installed. After the page has completed go into FusionReactor's Request History, select the Request Details for the request and click on the Markers tab to see the "Hello FRAPI!" message. Cool no? FRAPI tracks messages on the request as soon as trace() is called so it's possible to see the trace() statements in the Markers tab updating as a page is being run!

So how would we capture CF's debug output? We don't want to add FRAPI code to every page that we write that's for sure. We need to understand how ColdFusion's debug output is done to know how to capture it.

When enabled, CF Debug output is appended at the end of the page output by rCF running a "Debug Output Formatting" template. This is simply a piece of CFML code to that formats the debugging information into HTML. What's even better is the fact that the you can write your own and tell ColdFusion to use your template instead of the default one. So what if we wrote a CF Debug Template that simply calls FRAPI and adds that debug data to the FusionReactor Request using trace() calls? This means that the information would be available in FusionReactor but the user wouldn't even know that debug output was enabled because the FRAPI trace() calls don't output anything. It's that easy! Ok, there is always a but…

…but I don't know how to access all of this CF Debug Data and for sure it's complex, right?

The CF Debug data structures are fairly complex and very powerful but this is reason that few people ever write there own CF Debug Formatting template. The good news is we don't need to know anything about it due to a powerful CFML tag called <CFSAVECONTENT>. I know that the advanced CFML programmers out there just went… "OK, I get it…", but for the rest of us let's go into a little more detail on how we can do this.

<CFSAVECONTENT> is a tag that allows the programmer to capture output into a variable instead of sending it back to the user. Using <CFSAVECONTENT> we can capture the output from the classic CF debugging template into a variable and then simply call FRAPI's trace() function passing that variable as the information to record! Easy!

FRAPI.CFM

        <cftry>
            <cfset frapi = createObject("java", "com.intergral.fusionreactor.api.FRAPI").getInstance()>
            <cfsavecontent variable="debugData"><cfinclude template="classic.cfm"></cfsavecontent>
            <cfset frapi.trace( debugData )>
            <cfcatch>
                <!--- FRAPI isn't available so FusionReactor probably isn't installed --->
            </cfcatch>
        </cftry>

All we have to do now is add our FRAPI Debug Template (frapi.cfm) to the CF debug templates by simply copying it folder where debug templates are placed, typically <coldfusion folder>/wwwroot/WEB-INF/debug.

Finally we have to Enable Request Debugging Output and select our new ("frapi.cfm") template as the Debugging Output Format in the ColdFusion Administrator -> Debug Output Settings page.

The next time you (or anyone) runs a CF page FusionReactor will capture the Debug data for the page. To see the data simple go to the FusionReactor->Request History, select the Request Detail for the request and then click on the Markers tab to see the CF Debugging Data for the page.

Notes

  1. Performance
    ColdFusion pages run slower when debugging is enabled and on some applications enabling CF Debug Output can seriously impact the performance of the server. You should test this on your applications before enabling debugging a production server.
  2. Memory
    FusionReactor will record the debug output on each request that it keeps in it's request history. This will use some memory; for example, if you have a Request History size of 100 requests and the average debug output data size is 20Kbytes then FusionReactor will use 2Mbytes of memory to
    record the debug data.
  3. Data
    The amount of debug data recorded is controlled via the settings on the Debug Output Settings page and the classic.cfm debug formatting output template. The data will not be added to FusionReactor until the page completes because this is when CF calls the Debug Output Formatting page. The
    debug data captured will honor any Debugging IP Address restrictions that you configure in the CF Administrator.

Fast Track

  1. Copy the frapi.cfm file linked to this article to your ColdFusion Debug Formatting Template folder (typically): <coldfusion folder>/wwwroot/WEB-INF/debug
  2. Select Debugging Output Format: "frapi.cfm" in the ColdFusion Administrator -> Debug Output.
  3. Enable Request Debugging Output in the ColdFusion Administrator->Debug Output Settings Settings
  4. Run a CF page.
  5. In FusionReactor->Request History select the Request Detail for the request and then click on the Markers tab to see the CF Debugging Data from the page.

Summary

FRAPI is a powerful way to capture extra debugging information on requests and makes FusionReactor a powerful platform for debugging on both development and production servers.

Issue Details

Type: DevNet
Issue Number: FRS-232
Components: Compression, Content Filters, CPU + Memory, Crash Protection, Enterprise Dashboard, FR Enterprise Dashboard Desktop Application, FusionReactor Settings, Installer, JDBC, License + Activation, Logging, Metrics, Request Managment, Thread Management
Environment:
Resolution: Fixed
Last Updated: 03/Nov/11 3:36 PM
Affects Version: 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1, 3.5
Fixed Version: 2.0.3, 2.0.4, 3.0, 3.0.1, 3.5
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

FRS-237: Creating Daily FusionReactor Log Files

FRS-280: Setting VM Options via FRAPI

[frs-280] Setting VM Options via FRAPI


Setting VM Options via FRAPI

The Sun Java VM (JVM) offers many options to allow the user to control how the VM behaves. The HeapDumpOnOutOfMemoryError option for example is very useful if your server is suffering from heap memory problems and crashing.

By turning on HeapDumpOnOutOfMemoryError the JVM will create a dump file when java.lang.OutOfMemoryError is thrown that can be used in Memory Analysis tools such as MAT to track down memory problems.

A list of VM manageable runtime options includes:

Option Description
-XX:-HeapDumpOnOutOfMemoryError Dump heap to file when java.lang.OutOfMemoryError is thrown
-XX:-PrintClassHistogram Print a histogram of class instances on Ctrl-Break
-XX:-PrintConcurrentLocks Print java.util.concurrent locks in Ctrl-Break thread dump
-XX:-PrintGC Print messages at garbage collection
-XX:-PrintGCDetails Print more details at garbage collection
-XX:-PrintGCTimeStamps Print timestamps at garbage collection

Typically these options are added to the command line that starts the VM in the form of -XX:<optionname>.

There are however major problems with this:

  • Typically you have to edit the file that sets the command line options (e.g. jvm.conf) to change the settings.
  • If the -XX command line option wasn't added to the command line options at start-up then you can't set the option without restarting the server

Using FRAPI

It would be great if you control these VM options using code instead of the command line. FRAPI is a powerful and easy to use API that allows you to take control of FusionReactor programatically. Using FRAPI you can change the running configuration of FusionReactor or add extra debugging information to requests using just a few lines of code. We can also use FRAPI to set any "Managable" VM Option on the Sun JVM. (take a look at the following VM Options for details of all of the VM Options and look for "Manageable").

CFML
<cfset frapi = createObject("java", "com.intergral.fusionreactor.api.FRAPI").getInstance()>
<cfset frapi.setVMOption("HeapDumpOnOutOfMemoryError","true")>
<cfset frapi.setVMOption("PrintConcurrentLocks","true")>
<cfset frapi.setVMOption("PrintGCDetails","true")>   
JSP
<%@ page import="com.intergral.fusionreactor.api.*" %>
<%
    FRAPI frapi = FRAPI.getInstance();
    frapi.setVMOption("HeapDumpOnOutOfMemoryError","true");
    frapi.setVMOption("PrintConcurrentLocks","true");
    frapi.setVMOption("PrintGCDetails","true");   
%>

Requirements

You must be using a version of FRAPI that includes the setVMOption method (introduced in FRAPI 4.0) and a Sun JVM 1.5 or higher.

Notes

  • Due to a Bug in Java the HeapDumpPath VM Option may throw a NullPointerException and typically cannot be used.
  • Only VM Options that are known as "Manageble" can be set/changed at runtime. Manageable means that the option is dynamically writeable through the JDK management interface.

Summary

FRAPI is a easy way to set powerful VM Options while the server is running, without having to restart the server or edit configuration files.

Issue Details

Type: DevNet
Issue Number: FRS-280
Components: FRAPI
Environment:
Resolution: Fixed
Last Updated: 03/Nov/11 5:35 PM
Affects Version: 4.0.0
Fixed Version: 4.0.0
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

FRS-232: Capturing ColdFusion’s Debug Output in FusionReactor