[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-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-298] Instance Manager picks up the Tomcat based version of Railo twice


This technote is about installing an instance of FusionReactor on Railo Server.

Description

Version 4.5.0 of FusionReactor Instance Manager picks up the Tomcat based version of Railo twice. As a result the list of suitable target servers will contain the following target servers

  • Apache Tomcat
  • Railo

which actually represent the same server. This can be seen in the Server Scan dialog shown below

(note the directory paths) which typically is displayed when FusionReactor does its initial scan for target servers and later on the Instance Manager page:

Resolution

An instance of FusionReactor should be installed in only one of the two candidates, preferable the Railo server. Future versions of FusionReactor will only display Railo and omit the Apache Tomcat if it represents a Railo Server.
If you have done so the Instance Manager page will look like the one shown below.

Issue Details

Type: Technote
Issue Number: FRS-298
Components: Instance Manager
Environment:
Resolution: Fixed
Last Updated: 22/May/12 5:28 PM
Affects Version: 4.0.10
Fixed Version: 4.5.1
Server: Railo
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

FRS-299: Railo instances are not updated to the correct server type

[frs-299] Railo instances are not updated to the correct server type


This technote is about updating an instance of FusionReactor on Railo Express or Railo Server.

Description

Version 4.5.0 of FusionReactor Instance Manager will prompt you to update any existing instances when you have completed the Setup.

Previous versions of FusionReactor allowed you to add Railo as Jetty (Railo Express) or Tomcat (Railo Server) server. When FusionReactor Instance Manager scans for new target servers it will list these existing servers as Railo server in addition to the already existing Jetty and Tomcat servers.

This does allow the user to accidentally install a new FusionReactor instance to a server that already has FusionReactor installed. As a result the previous server will report itself as not connected. However, the new instance will work as expected.

Resolution

Do not install a new instance on a target server that has FusionReactor already installed (identify the belonging server by the directory listed behind the server).
Alternatively uninstall the FusionReactor instance from the Apache Tomcat resp. Jetty Server and re-install it on the appropriate Railo Server. Afterwards delete the Tomcat resp. Jetty server from the Instance Manager.

Whether your instance is installed on the Tomcat resp. Jetty server or the Railo server has no effect on functionality. Just make sure that you do not install it on the same server twice. Future versions of FusionReactor will display Railo server only and omit the Tomcat and Jetty servers if these represent a Railo server.

Issue Details

Type: Technote
Issue Number: FRS-299
Components: Installer, Instance Manager
Environment:
Resolution: Fixed
Last Updated: 22/May/12 5:27 PM
Affects Version: 4.5.0
Fixed Version: 4.5.1
Server: Railo
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

FRS-298: Instance Manager picks up the Tomcat based version of Railo twice

[frs-284] FRAM doesn’t start with message “This account is currently not available.”


Symptoms

FRAM will not start and throws the message below.

This account is currently not available.

Background

On *nix, it's common to have users whose shells are restrictive, i.e. inhibit login. A common way of doing this is to have /usr/sbin/nologin as their shell.
Our FRAM service requires a shell in order to start correctly.

Default behaviour (v4.0.4 and earlier)

Our startup script /etc/init.d/framd does the following:

su -c "/opt/fusionreactor/tomcat/bin/framd-real start" nobody
  • Uses the "su" command to run a command as another user (init.d scripts are run by init as root), in this case nobody
  • The framd-real script is the real script that starts FRAM

In the fault case, framd does not start because of the restricted shell for nobody.

Resolution

Add an additional parameter to su which allows us to specify a shell:

su -s "/bin/sh" -c "/opt/fusionreactor/tomcat/bin/framd-real start" nobody

This effectively bypasses /usr/sbin/nologin for the startup of FRAMd.

Important Notes

  • In this technote, we have assumed your JEE engine (eg JRun/ColdFusion) is running as the user "nobody". If this is not the case then you should replace the "nobody" references as appropriate. Please refer to http://www.fusion-reactor.com/support/kb/FRS-270.cfm for further details
  • In some cases where a user has run the installer twice on the same server, it's possible the /etc/init.d/framd script has been corrupted. If you do not see the command
    su -c "/opt/fusionreactor/tomcat/bin/framd-real start" nobody
    

    on line 27 in the file then please contact support.

Issue Details

Type: Technote
Issue Number: FRS-284
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 10/Jan/12 3:11 PM
Affects Version: 4.0.4
Fixed Version: Pending
Server:
Platform: Linux, MacOS, Solaris, AIX
Related Issues: