Windows 7

[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-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-337] FusionReactor Desktop AIR App with Roaming Profiles


Roaming Profiles

A roaming user profile is a concept in the Microsoft Windows NT family of operating systems that allows users with a computer joined to a Windows Server domain to log on to any computer on the same network and access their documents and have a consistent desktop experience, such as applications remembering toolbar positions and preferences, or the desktop appearance staying the same.

Unfortunately many applications have problems when the roaming profile is configured to be on a UNC network path.

Some which are documented on the wikipedia page : http://en.wikipedia.org/wiki/Roaming_user_profile#Redirection_limitations_of_UNC_paths

FusionReactor Desktop AIR App with UNC Paths

FusionReactor Desktop AIR App cannot handle UNC paths, we regret to say that the FusionReactor Desktop AIR app isn't supported on Windows systems where the AppData folder is stored in a UNC location.

If the app is running in such an environment, when the user presses login, the "logging in" message will pop up and then disappear again. If the login button is clicked again, the progress pop up will appear and won't disappear again.

This typically occurs on those systems which are connected to a Windows domain using the pre Windows 2000 style domain selection (where the domain is specified separately to the logon name) and where the user profile is a roaming profile (with all the user data actually being stored on the server).

This issue doesn't seem to occur on the computers registered to the domain using the newer system where the domain is appended to the username with an @ between them (available on Server 2008 R2+ and Windows 7+)

Issue Details

Type: Technote
Issue Number: FRS-337
Components: FR Enterprise Dashboard Desktop Application
Environment:
Resolution: Fixed
Last Updated: 01/Dec/14 4:45 PM
Affects Version:
Fixed Version: Pending
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Windows Vista, Windows x64, Windows 7, Windows 2008
Related Issues:

[frs-348] Workaround for IE8 JQuery errors


Customers using FusionReactor 5.2.4 and Internet Explorer 8 will encounter the following error in the IE console:

'jQuery' is undefined

Workaround

As a workaround, create the directory html/libs inside the FusionReactor instance location C:/fusionreactor/instance/<instance_name>/. Then place the jquery.min.gz.js inside this directory.

Once complete, a hard refresh of the page should correct the error. This procedure does not require a server restart.

Issue Details

Type: Technote
Issue Number: FRS-348
Components: Documentation
Environment:
Resolution: Fixed
Last Updated: 28/Nov/14 4:57 PM
Affects Version: 5.2.4
Fixed Version: 5.2.5
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Windows Vista, Windows 7, Windows 2008
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-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

[frs-303] Silent Install for FusionReactor


Silent Install

To perform a silent install of Fusion Reactor use the following steps:

  1. Create a file called response.varfile
  2. Place the following two lines in the varfile :
    password=yourPassword
    passwordValidation=yourPassword
    
  3. From the command line run a similar command to the following:
    "C:InstallersFusionReactor_windows_4_5_2.exe" -q -dir"C:FusionReactor" -varfile response.varfile
  • The first part "C:InstallersFusionReactor_windows_4_5_2.exe" is the location of the installer
  • -q is the switch to install silently
  • -dir"C:FusionReactor" is the location that FusionReactor will be installed to
  • -varfile response.varfile is to specify to use the created varfile

Once all the previous steps are complete you can use FRAM (default port 8087) to install Fusion Reactor into your instances, documented here: http://docs.intergral.com/display/FR40/Install+FusionReactor+Instance

If that is not an option, you can follow the manual installation steps, documented here: http://docs.intergral.com/display/FR451/Manual+Instance+Installation

Issue Details

Type: Technote
Issue Number: FRS-303
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 30/Nov/12 2:53 PM
Affects Version:
Fixed Version: 4.0.0
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Windows Vista, Windows x64, Windows 7, Windows 2008
Related Issues: